• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 82 subscribers
  • Views 486 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28379D: Launchpad issue with booting from FLASH after Flash programming

Saul Perez
Prodigy 30 points
Part Number: TMS320F28379D


Hello.

I am facing an issue with this board.

I am programming the device in FLASH. Everything runs fine, even after Resetting the board the device resets and executes code. 

My program allows to write on FLASH (one user parameter) I used memory address 0x0BC000 for storing one parameter in the FLASH memory, for this I am using the Flash API and examples provided. 

When I save the parameter in FLASH, the board is not able to restart again. I power cycle the board or reset the board, but code is not executed. It seems the board is not booting correctly. 

If I do not use the function to write in Flash the parameter (in address 0x0BC000) The board is able to boot and restart correctly after Reset / Power cycle and program runs perfectly.

If I launch Debug session the program works well and even I can store in flash the user parameter and restart the code in the debugging session, it continues to work. 

I checked in Debug the parameter is correctly written in the address 0x0BC000, and no other code is modified. Code in 0x080000 is not modified after setting this parameter. 

Also, in Debug session in disassembly mode I can see the first instruction is not starting at 0x080000 but at 0x080567. Is it possible debug restart sends the PC pointer to this address and BOOT to 0x080000. How can I send the reset or boot instruction to PC counter to point the first main address instruction? 

Why do I face this issue? How can I solve it? 

Regards.

  • 0
    TI__Guru* 81970 points

    Saul,

    I agree with your last point on getting the emulation session to mimic the standalone boot to debug this properly.  As you said there is a default option for CCS to go to main after a program/load and this could be bypassing the normal boot flow.

    After you connect to the device(that is already flashed, and with the offending code), in CCS go to Run->Reset.  Then Go to Scripts->EMU_BOOT->FLash Boot.  This will program the EMU boot field in RAM and the BROM will intercept this and mimic the boot from flash that would happen in standalone.  You should be able to follow along with the code to see what is/is not happening or if it is what you expect.

    If you look at your .map file(should be in the same dir as your .out file) you can also verify what is getting loaded to 0x80000, this will typically just have a function call into codestartbranch.asm, which is a file we include that sets up the core/registers for proper execution.  You could also attach your .map file this post and we can look at the contents as well.

    Best,

    Matthew