TMS320F28388D: Branching back and forth between particular Flash Sectors

Hi Pranay,

Thanks for your question. I'll have to get back to you within the next day or two.

Regards,

Charles

Pranay, 

Q1) Boot command comes into the picture as the M4 has not had a boot mode set yet for it, so it resides to wait boot mode. 

Q2) Before jumping from one app to another, you may want to store the temporary values of what was being used by the previous application. But as each application is in flash memory, I would look to see what RAM usage is for each sectored application.

Q3) Yes, as long as the sectors are not being programmed and erased at the same time, as the sectors are on the same bank.

Q4) Take care to make sure that when returning from a previous function what entry address you will be starting at and what variables will lose their values.

Q5/6) For firmware jump example, I would look to the Live Firmware Update (F280039C) as an example. I know this is mentioned as the F28388D device, but I'll have to look into the repo to see if an example exists for this application switching. 

Will refine these answers more tomorrow.

Thanks and regards,

Charles

Charles,

Let me first comment on your answers.

Q2) Storing temporary values may not be needed, since the compiler will manage these using the Stack.

If you are in specific function in APP2, and you branch to APP1, then the Stack for APP2 will contain the necessary temporary variables.

However, the RAM usage of APP1, APP2, APP3 is a good point, and any overlaps must be checked for. Specifically, ensure overlaps are avoided, including with Stack.

Pranay,

"APP1 will be booted first whenever we perform a POR and from APP1, APP2 will be called.

We've implementations that shall program APP3/APP1 from APP2 and JUMP to APP3/APP1 when needed to."

If I understand correctly, APP2 and APP3 are Application FW, and APP1 is the Bootloader (or SSBL as you call it). So why would the Application FW (APP2) overwrite/program the Bootloader (APP1)?

Since there is only 1 Flash bank, having APP2 program APP1 (if you actually wanted to do that) is possible, but since you cannot Read from and Write to the Flash bank at the same time, you would need to run the portion of APP2 that performs the Flash programming + the Flash API libraries from RAM.

We don't have an existing example of this for F2838x. The LFU example we have is for the C28x side (not the CM side) and can be found in the reference design TIDM-02011.

Thanks,

Sira

Hi Sira and charles,

Thanks for the reply.,

Yes, We ensured that RAM and FLASH sectors didn't get overlapped between Bootloader and APPlication FW.

Sira Rao80 said:

you would need to run the portion of APP2 that performs the Flash programming + the Flash API libraries from RAM

In APP1 and SSBL linker files we ensured that their respective  flash API library reside in RAM. Please find the attached linker files for your reference and correct me if anything needs to be tweaked in linkers.

Charles Roberson said:

Q3) Yes, as long as the sectors are not being programmed and erased at the same time, as the sectors are on the same bank

We've been working with SSBL so long now and we know this already, we've ensured that Flash reside in RAM section and wont be erased and read /write at the same time.

Q7: From below links I see that there is something called startup code or initialization code that will  be usually performed in FSBL, I think that we do need some sort of similar startup code before we jump from Bootloader to APP1 FW or vice versa to ensure that proper branching is happening .

https://www.iotality.com/arm-cortex-m4-startup-code/

https://stackoverflow.com/questions/59458156/why-stack-pointer-need-to-be-updated-before-jumping-to-application-from-bootload

https://www.ti.com/lit/ug/spru430f/spru430f.pdf  - 514 page no.

Else if we don't do any initializations before we jump from ssbl to APP1 then does it not mean that APP1 still runs in SSBL context ??

Q8: Do I need to execute or write anything as startup code after flashing bootloader through APP1 FW, because I see that when same bootloader has been programmed through JTAG, it will jump properly from FSBL to bootloader after POR, but when same .txt is programmed through APP1 FW and then perform a POR that jump from FSBl to SSBL is not happening and execution is stuck at 0x1818 as per target configuration.

For reference I have already shared .xtx files written via APP1 FW and JTAG, I see that there are no differences when read FLASH thru JTAG  in both cases. So we can eliminate Flash data writing miss match issue from list.

So what am I missing here ? can you please confirm and also provde information regarding what does JTAG performs extra other than writing flash to make controller jump from FSBL to bootloader ?

For debugging the code stuck at 0x1818 location and TRM says that this error will be seen if the execution is stuck at WAITBOOT MODE and is waiting for boot command from CPU1, so I tried sending Device boot CM command from CPU1 but that didnt help us either.

--pranay.

Hi Pranay,

I will need some time to confirm these things, will get back to you by Tuesday.

Thanks,

Charles

Pranay,

Can you clarify the terminology you are using - FSBL and SSBL?

When you boot up the device, I am assuming APP1 runs first, then transfers control to APP2. If that is the case, then yes, in each case, prior to running APP1 or APP2, a "C initialization routine" should be run prior to running the corresponding main() (of either APP1 or APP2).

I know this to be true for the C28x CPU, and am sure it applies to the CM core as well. This is what allows it to setup the C environment, perform all the variable initialization, etc. and run the corresponding software correctly.

In C28x, this is provided by the TI compiler as c_int00. So this is the function called, and this automatically calls main(). When branching from a bootloader to the application, I will branch to a location in the application where c_int00 is called. Typically, this is in a file called <devicename>_codestartbranch.asm.

I don't know what the corresponding file names etc. are on the CM side, but the approach should be the same.

Thanks,

Sira

Also, you did not answer my previous question. Please confirm whether there is a Typo below in the statement in Bold.

APP1 will be booted first whenever we perform a POR and from APP1, APP2 will be called.

We've implementations that shall program APP3/APP1 from APP2 and JUMP to APP3/APP1 when needed to.

Is the correct statement as follows?

We've implementations that shall program APP2/APP3 from APP1 and JUMP to APP2/APP3 when needed to.

Hi sira,

Let me re-iterate the problem statement to avoid the confusion.

In CM Controller we have two custom applications.
1. App1 (We refer as SSBL- Second stage boot loader).
    Since this application will be used to perform the field firmware update.
    Upon POR first App1 will be loaded, And based on the flash sector data. Whether Program mode/Boot mode.
    It will jump to the actual application firmware App2.
    In Program mode. It will receive the data from UART and load the firmware to the App2 location.
    All these activities are working as expected.
2. App2 (Actual custom user application)
    Based on requirement, If any new implemetations are don. We will update using App1. As explained above.
    
My requirement, Now at present is I need to update the App1 firmware from App2.
So. To perform that I used the App2 and loaded the App1() and written to the specified location.
And If I perform POR, Neither App1 is running nor App2.

Note : In default case App1 will be loaded from JTAG. In my current requirement I loaded the App1 by using App2.

Verified for the Data By using JTAG Memory browser, App1 data when loaded from JTAG and as well wehen loaded from App2.
is remained same. That is already attached in my initial comment "program_flsh_read_data.zip".

So could you please let me know. How I can proceed further. Let us know if any further input needed.

Thanks,

Pranay

Pranay,

Updating the SSBL using the Application FW sounds like a strange use-case to me, but that's what you're trying to do, so be it.

You say that the Flash contents are identical (for the APP1 Flash sectors) between when you loaded using JTAG vs when APP2 updated APP1. So that must mean it is being programmed correctly.

1. I presume you are using Flash boot mode? When you reset the device after updating APP1, where does control go to? It should go to the Flash entry point.

2. On the C28 side, when you load the program using JTAG, it will use Emulation boot mode since the debugger is connected, and then eventually branch to the Flash entry point. Once you program APP1 using JTAG and then reset the device, does it behave as expected?

Thanks,

Sira

Sira,

Sira Rao80 said:

1. I presume you are using Flash boot mode? When you reset the device after updating APP1, where does control go to? It should go to the Flash entry point.

1.we are using flash boot mode,when we are doing rest it is not jumping into the Flash entry point, Through jtag we came to know it got struck in

For debugging the code stuck at 0x1818 location and TRM says that this error will be seen if the execution is stuck at WAITBOOT MODE and is waiting for boot command from CPU1, so I tried sending Device boot CM command from CPU1 but that didnt help us either.it is getting stuck in the other two location we mentioned above.

can you help us understand and debug where does the execution goes when POR happens, and necessary steps need to be followed before and after writing data into flash sectors helps controller to boot .

Sira Rao80 said:

2. On the C28 side, when you load the program using JTAG, it will use Emulation boot mode since the debugger is connected, and then eventually branch to the Flash entry point. Once you program APP1 using JTAG and then reset the device, does it behave as expected?

2.when APP1 programmed through JTAG  upon reset it is booting and behaving as expected

Thanks

Pranay

Pranay, let me talk to a team member on this and get back to you.

Thanks,

Sira

Hi Sira,

 I am waiting for this from past 10 day, any update on this please let me know  .

thanks,

Pranay

Pranay,

Apologies, I was on vacation for over a week. I have reached out again to my colleague for suggestions on this.

Thanks,

Sira

Does the ECC also match for the APP1 between the two cases (JTAG load and APP2 load)? ECC space is documented in the datasheet.

Hi Sira,

Checked CM_FLASH_ECC_REGS Registers status for both the case , they are identical please find .txt file of both cases below.

In case of flash writing we are supposed to disable ecc , then only flash write is possible. were we expected to do anything else other than this ?
Please let us know if anything need to be specifically written on to the ecc registers in case flash writing .

Thanks and regards

Pranay

@400FA600
0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
q

@400FA600
0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
q

Hi Pranay,

Why are you disabling ECC to do the flash write?  What are the problems that you encountered during the flash write with ECC enable? Please let us know.

Thanks and regards,

Vamsi

Hi Vamsi,

if we do not disable ECC (Flash_disableECC) , we were unable to write entire data on to the flash sector ,in between flash write execution is breaking leaving half written data on to the flash sector.

If we disable the ECC we were able to write entire data on to the flash sector.

so by default we were using Flash_disableECC in order to successfully write all the data.

for reference i have provided txt where Flash_disableECC executed case and not executed case.

In debug mode it is showing that execution going to the outside of debug code. please refer to the screen shot attached.

Flashwrite_With_ECC_Disable.txt

Flashwrite_Without_ECC_disable.txt

Thanks

pranay

Hi Pranay,

Ok, the programming has to be fixed first - Enabling ECC should not cause any issue.  You confirmed that the image is same between the two cases.  And is working when loaded through JTAG, but not when programming with your APP.

1) For programming using the flash API in your APP, are you using Fapi_DataOnly mode? or the Fapi_AutoEccGeneration mode for the program command?  Use AutoEccGeneration method to avoid ECC errors.

2) When programming, the start address should always be aligned on either 64-bit or 128-bit (prefer 128-bit).  

3) When programming using Fapi_AutoEccGeneration, please ensure to provide all the 64-bits/128-bits (depending on whether you are programming 64-bits or 128-bits).  If you give partial data, you won't be able to reprogram the remaining data later since ECC gets programmed when you give the partial data itself.

4) Do you check the FMSTAT value after program?  Do you see any error in it?

5) Also, can you attach the ECC space data between the two cases?

Thanks and regards,
Vamsi

Hi Vamsi ,

Vamsi Gudivada said:

1) For programming using the flash API in your APP, are you using Fapi_DataOnly mode? or the Fapi_AutoEccGeneration mode for the program command?  Use AutoEccGeneration method to avoid ECC errors.

1.We are using Fapi_DataOnly mode , tried using AutoEccGeneration method without ecc disbaling, facing issue where we were able to write half of the txt file data only on to the flash. for reference i have shared the text files

FlashWrite_Fapi_dataonly.txtFlashWrite_Fpi_AutoEccGen.txt

Vamsi Gudivada said:

2) When programming, the start address should always be aligned on either 64-bit or 128-bit (prefer 128-bit). 

2. Entry point is 0x210000 , which will align with both 128 bit and 64bit

Vamsi Gudivada said:

3) When programming using Fapi_AutoEccGeneration, please ensure to provide all the 64-bits/128-bits (depending on whether you are programming 64-bits or 128-bits).  If you give partial data, you won't be able to reprogram the remaining data later since ECC gets programmed when you give the partial data itself.

3.As you can see in above text files we were unable to write, but txt file we are using is generated from ccs application based on linker file. As you mentioned  address should be aligned with 64 ot 128 bit can you give me any alternate solution if it is not aligned, like any changes need to be made in linker file to align data.

Vamsi Gudivada said:

4) Do you check the FMSTAT value after program?  Do you see any error in it?

4. yes i checked entire CM flash cntrl register after write in both cases they are same i have given you ref reg data txt files

@400FA000
00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 0F 00 00 00
03 00 00 00 01 80 00 00 01 00 1A 06 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FC 00 00 00 AA 55 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0B 00 00 00 55 00 EB 00 00 00 DB 00 00 00 0F 00
16 07 00 00 00 A0 00 00 04 00 00 00 0A 01 00 07
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
04 01 00 00 03 01 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 0A 00 00 00 00 00 00 00
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF 01 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
q

@400FA000
00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 0F 00 00 00
03 00 00 00 01 80 00 00 01 00 1A 06 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FC 00 00 00 AA 55 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0B 00 00 00 55 00 EB 00 00 00 DB 00 00 00 0F 00
16 07 00 00 00 A0 00 00 04 00 00 00 0A 01 00 07
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
04 01 00 00 03 01 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 0A 00 00 00 00 00 00 00
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF 01 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
q

Vamsi Gudivada said:

5) Also, can you attach the ECC space data between the two cases?

5. what does ECC space data mean ? is it a register or flash address, how to access it ?

thanks and regards

pranay. 

Hi Pranay,

I am out of office today; I will be able to review this and get back to you in a day or two.

Thanks and regards,
Vamsi

Hi Pranay,

Thank you for the information.

1) Reason you are ending up in NMI handler should be from the ECC errors - since you are not programming the ECC (you are using Fapi_DataOnly) mode.

2) I am not talking about only the application entry point - I meant that each address that you provide for program command should be aligned (you may have seen this in the flash API guide and the example).

3) Could you check in your linker command file to ensure that all the sections mapped to flash are aligned using ALIGN(8)?

4) Sorry, I can't review the entire register dump.  After the program command, as you may have noticed in the flash API usage example/guide, you need to check the status of the command (please look for FMSTAT register in the flash API guide).  Please let me know if there is any error indicated in it.

5) It is a memory region provided in the data sheet's memory map.  However, there is no need to provide this info now since you confirmed that you did not program ECC. 

Below FAQ pages might help you:  

A. [FAQ] FAQ on Flash API usage for C2000 devices: 

     https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/951668 

B. [FAQ] FAQ for Flash ECC usage in C2000 devices - Includes ECC test mode, Linker ECC options: 

     https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/951658 

Thanks and regards,
Vamsi

Hi Vamsi,

Vamsi Gudivada said:

1) Reason you are ending up in NMI handler should be from the ECC errors - since you are not programming the ECC (you are using Fapi_DataOnly) mode.

1. We are ending up in nmi not while flash write execution but after power cycle , where at that point all data that we want to write onto flash is already written.

2. We are seeing it got struck in nmi some time after a power cycle  when CPU1 trying boot cm.

Vamsi Gudivada said:

3) Could you check in your linker command file to ensure that all the sections mapped to flash are aligned using ALIGN(8)?

3. checked linker file all sections mapped to flash are aligned using ALIGN(8), please file SSBL and application linker below

//Application Firmware Linker file
MEMORY
{
   /* Flash sectors */
   CMBANK0_RESETISR : origin = 0x00210000, length = 0x00000008 /* Boot to Flash Entry Point */
   CMBANK0_SECTOR13 : origin = 0x00200000, length = 0x00000008
   CMBANK0_SECTOR0  : origin = 0x00200008, length = 0x00003FF7
   CMBANK0_SECTOR1  : origin = 0x00204000, length = 0x00004000
   CMBANK0_SECTOR2  : origin = 0x00208000, length = 0x00004000
   CMBANK0_SECTOR3  : origin = 0x0020C000, length = 0x00004000
   CMBANK0_SECTOR4  : origin = 0x00210008, length = 0x00003FF7
   CMBANK0_SECTOR5  : origin = 0x00220000, length = 0x00010000
   CMBANK0_SECTOR6  : origin = 0x00230000, length = 0x00010000
   CMBANK0_SECTOR7  : origin = 0x00240000, length = 0x00010000
   CMBANK0_SECTOR8  : origin = 0x00250000, length = 0x00010000
   CMBANK0_SECTOR9  : origin = 0x00260000, length = 0x00010000
   CMBANK0_SECTOR10 : origin = 0x00270000, length = 0x00004000
   CMBANK0_SECTOR11 : origin = 0x00274000, length = 0x00004000
   CMBANK0_SECTOR12 : origin = 0x00278000, length = 0x00004000
   GRLBOOTPGMMODE 	: origin = 0x0027C000, length = 0x00004000

   C1RAM            : origin = 0x1FFFC000, length = 0x00001FFF
   C0RAM            : origin = 0x1FFFE000, length = 0x00001FFF

   BOOT_RSVD        : origin = 0x20000000, length = 0x00000800 /* Part of S0, BOOT rom will use this for stack */
   SRAM             : origin = 0x20000800, length = 0x0000F7FF
   E0RAM            : origin = 0x20010000, length = 0x00003FFF

   CPU1TOCMMSGRAM0  : origin = 0x20080000, length = 0x00000800
   CPU1TOCMMSGRAM1  : origin = 0x20080800, length = 0x00000800
   CMTOCPU1MSGRAM0  : origin = 0x20082000, length = 0x00000800
   CMTOCPU1MSGRAM1  : origin = 0x20082800, length = 0x00000800
   CPU2TOCMMSGRAM0  : origin = 0x20084000, length = 0x00000800
   CPU2TOCMMSGRAM1  : origin = 0x20084800, length = 0x00000800
   CMTOCPU2MSGRAM0  : origin = 0x20086000, length = 0x00000800
   CMTOCPU2MSGRAM1  : origin = 0x20086800, length = 0x00000800
}

SECTIONS
{
   .resetisr        : > CMBANK0_RESETISR,FILL=0
   .vftable         : > CMBANK0_SECTOR8,ALIGN(8) /* Pranay, 07July'22,Application placed vector table in Flash, This shall not be collided with any other flash sectors*/
   .vtable          : > SRAM /* Application placed vector table in RAM*/
   .text            : >> CMBANK0_SECTOR5 | CMBANK0_SECTOR6, ALIGN(8)
   .cinit           : > CMBANK0_SECTOR5 | CMBANK0_SECTOR6, ALIGN(8)
   .pinit           : >> CMBANK0_SECTOR5 | CMBANK0_SECTOR4,ALIGN(8)
   .switch          : >> CMBANK0_SECTOR5 | CMBANK0_SECTOR4,ALIGN(8)
   .sysmem          : > SRAM
   .binit 			: > CMBANK0_SECTOR4

   .stack           : > C0RAM | C1RAM
   .ebss            : > C1RAM
   .econst          : >> CMBANK0_SECTOR5 | CMBANK0_SECTOR6| CMBANK0_SECTOR4,ALIGN(8)
   .esysmem         : >> C1RAM | C0RAM //heap
   .data            : > SRAM
   .bss             : >> SRAM | E0RAM |C1RAM
   .const           : {} LOAD = CMBANK0_SECTOR5 | CMBANK0_SECTOR6| CMBANK0_SECTOR7,ALIGN(8)
   							RUN = SRAM,
   							LOAD_START(constLoadStart),
   							LOAD_SIZE(constLoadSize),
   							LOAD_END(constLoadEnd),
   							RUN_START(constRunStart),
   							RUN_SIZE(constRunSize),
   							RUN_END(constRunEnd)

    MSGRAM_CM_TO_CPU1 : > CMTOCPU1MSGRAM0, type=NOINIT
    MSGRAM_CM_TO_CPU2 : > CMTOCPU2MSGRAM0, type=NOINIT
    MSGRAM_CPU1_TO_CM : > CPU1TOCMMSGRAM0, type=NOINIT
    MSGRAM_CPU2_TO_CM : > CPU2TOCMMSGRAM0, type=NOINIT

    .TI.ramfunc : {-l F2838x_CM_FlashAPI.lib} LOAD = CMBANK0_SECTOR5 | CMBANK0_SECTOR6 | CMBANK0_SECTOR7,
						                           RUN = SRAM,
						                           LOAD_START(RamfuncsLoadStart),
						                           LOAD_SIZE(RamfuncsLoadSize),
						                           LOAD_END(RamfuncsLoadEnd),
						                           RUN_START(RamfuncsRunStart),
						                           RUN_SIZE(RamfuncsRunSize),
						                           RUN_END(RamfuncsRunEnd),
						                           ALIGN(8)
}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

//SSBL Linker File
MEMORY
{
   /* Flash sectors */
   CMBANK0_RESETISR : origin = 0x00200000, length = 0x00000008 /* Boot to Flash Entry Point */
   CMBANK0_SECTOR0  : origin = 0x00200008, length = 0x00003FF7
   CMBANK0_SECTOR1  : origin = 0x00204000, length = 0x00004000
   CMBANK0_SECTOR2  : origin = 0x00208000, length = 0x00004000
   CMBANK0_SECTOR3  : origin = 0x0020C000, length = 0x00004000
   CMBANK0_SECTOR4  : origin = 0x00210000, length = 0x00010000
   CMBANK0_SECTOR5  : origin = 0x00220000, length = 0x00010000
   CMBANK0_SECTOR6  : origin = 0x00230000, length = 0x00010000
   CMBANK0_SECTOR7  : origin = 0x00240000, length = 0x00010000
   CMBANK0_SECTOR8  : origin = 0x00250000, length = 0x00010000
   CMBANK0_SECTOR9  : origin = 0x00260000, length = 0x00010000
   CMBANK0_SECTOR10 : origin = 0x00270000, length = 0x00004000
   CMBANK0_SECTOR11 : origin = 0x00274000, length = 0x00004000
   CMBANK0_SECTOR12 : origin = 0x00278000, length = 0x00004000
   CMBANK0_SECTOR13 : origin = 0x0027C000, length = 0x00004000

   C1RAM            : origin = 0x1FFFC000, length = 0x00001FFF
   C0RAM            : origin = 0x1FFFE000, length = 0x00001FFF

   BOOT_RSVD        : origin = 0x20000000, length = 0x00000800 /* Part of S0, BOOT rom will use this for stack */
   SRAM             : origin = 0x20000800, length = 0x0000F7FF
   E0RAM            : origin = 0x20010000, length = 0x00003FFF

   CPU1TOCMMSGRAM0  : origin = 0x20080000, length = 0x00000800
   CPU1TOCMMSGRAM1  : origin = 0x20080800, length = 0x00000800
   CMTOCPU1MSGRAM0  : origin = 0x20082000, length = 0x00000800
   CMTOCPU1MSGRAM1  : origin = 0x20082800, length = 0x00000800
   CPU2TOCMMSGRAM0  : origin = 0x20084000, length = 0x00000800
   CPU2TOCMMSGRAM1  : origin = 0x20084800, length = 0x00000800
   CMTOCPU2MSGRAM0  : origin = 0x20086000, length = 0x00000800
   CMTOCPU2MSGRAM1  : origin = 0x20086800, length = 0x00000800
}

SECTIONS
{
	_start         : > CMBANK0_RESETISR,FILL=0
  .resetisr        : > CMBANK0_RESETISR,FILL=0
   .vftable         : > CMBANK0_SECTOR3,ALIGN(8) /* Application placed vector table in Flash, this shall not be collided with any other flash sectors*/
  .vtable          : > E0RAM             /* Application placed vector table in RAM*/


   .text            : >> CMBANK0_SECTOR2,ALIGN(8)
   .cinit           : > CMBANK0_SECTOR1,ALIGN(8)
   .pinit           : >> CMBANK0_SECTOR0 | CMBANK0_SECTOR1,ALIGN(8)
   .switch          : >> CMBANK0_SECTOR0 | CMBANK0_SECTOR1,ALIGN(8)
   .text            : > CMBANK0_SECTOR3, PAGE= 0, ALIGN(8) /* Here ALIGN(8) makes sure that .text section starts on a 128-bit aligned memory address*/
   //.text            : > CMBANK0_SECTOR3, PAGE= 0, ALIGN(8)
   .sysmem          : > E0RAM
   .binit 			: > CMBANK0_SECTOR1

   .stack           : > C0RAM
   .ebss            : > C0RAM
   .econst          : >> CMBANK0_SECTOR0 | CMBANK0_SECTOR1 ,ALIGN(8)
   .esysmem         : > C0RAM
   .data            : > E0RAM
   .bss             : > E0RAM
   .const           : {} LOAD = CMBANK0_SECTOR0 | CMBANK0_SECTOR1 |CMBANK0_SECTOR2 ,ALIGN(8)
   							RUN = E0RAM,
   							LOAD_START(constLoadStart),
   							LOAD_SIZE(constLoadSize),
   							LOAD_END(constLoadEnd),
   							RUN_START(constRunStart),
   							RUN_SIZE(constRunSize),
   							RUN_END(constRunEnd)

    MSGRAM_CM_TO_CPU1 : > CMTOCPU1MSGRAM0, type=NOINIT
    MSGRAM_CM_TO_CPU2 : > CMTOCPU2MSGRAM0, type=NOINIT
    MSGRAM_CPU1_TO_CM : > CPU1TOCMMSGRAM0, type=NOINIT
    MSGRAM_CPU2_TO_CM : > CPU2TOCMMSGRAM0, type=NOINIT

    .TI.ramfunc : {} LOAD = CMBANK0_SECTOR0 | CMBANK0_SECTOR1 | CMBANK0_SECTOR2 ,
                           RUN = E0RAM,
                           LOAD_START(RamfuncsLoadStart),
                           LOAD_SIZE(RamfuncsLoadSize),
                           LOAD_END(RamfuncsLoadEnd),
                           RUN_START(RamfuncsRunStart),
                           RUN_SIZE(RamfuncsRunSize),
                           RUN_END(RamfuncsRunEnd),
                           ALIGN(8)
}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

4. From above FAQ we can be able to program flash even with ECC disable, and coming to our case we are following same method by disabling ECC and writing ,we are not facing issue while writing , issue we are facing is while booting. Is there any way to disable ECC default while flashing through JTAG , so that ECC setting does not effect CM boot?

5. As our issue is regarding the CM Boot ,any additional setting that need to be done during the flash write or after for successful CM boot ?

thanks and regards

Pranay

Pranay,

I am aware that you are not getting any ECC error while programming.  ECC errors occur when a flash fetch(execution)/read happens if the ECC is not programmed (or incorrect).  This is the issue in your context. 

Regarding the alignment:  Can you try ALIGN(16) instead of ALIGN(8)?  Maybe your custom programmer is programming 128-bits at-a-time (but not streaming all the 128-bits) - hence is the suggestion to try ALIGN(16).

Thanks and regards,

Vamsi  

hi vamsi,

Vamsi Gudivada said:

Regarding the alignment:  Can you try ALIGN(16) instead of ALIGN(8)?  Maybe your custom programmer is programming 128-bits at-a-time (but not streaming all the 128-bits) - hence is the suggestion to try ALIGN(16).

1. we are programing 8 bytes at-a-time.

2.Tried using ALIGN(16) ended up in same situation as write is successful but Boot did not happened code execution did not come to ssbl from fsbl after       power cycle.

Vamsi Gudivada said:

I am aware that you are not getting any ECC error while programming.  ECC errors occur when a flash fetch(execution)/read happens if the ECC is not programmed (or incorrect).  This is the issue in your context. 

3. So you mean to say even though write is successful ,ECC error is occurring while flash fetch/read operation ,

At which stage flash read happens ?

For comparison i am reading data in flash through Uniflash via Jtag is it same as this read?

Is there any way to disable ECC default so that we will not face this error ?

Thanks

Pranay

Pranay,

Do you have any further questions in this context?  Or Can I close this post?

Thanks and regards,
Vamsi

Hi Pranay,

I am closing this post since I did not hear from you in the last 3 weeks.  If you have further questions, please open a new post as needed.

Thanks and regards,

Vamsi