TMS320F280025: Uniflash can not run Target After Program Load/Flash Operation

Strong ZHANG said:

F280025, Uniflash can not reset device and run after programming hex file, it is ok to reset the device with out file, 

After you have programmed with hex file, does the program run after disconnecting then reconnecting the debugger (USB) cable?

Strong ZHANG said:

can be reproduced by Ti c2000ware example,

Which example please?

Strong ZHANG said:

could you help check if anything wrong?

Perhaps the debug probe remains connected in which case the program will not run. Try deselecting the following:

Hi Kier,

you can reproduce this issue with below example code with  F280025_launchpad, the led is blinking after downloading out file,

but never change after download hex file. 

 launchxl_ex1_f280025c_demo.7z

I could not find a difference between your .out file and your .hex file.

I could not replicate the problem with 'launchxl_ex1_f280039c_demo'.

Do you use the same .uniflash session file for both .out and .hex?

Yes, same uniflash for both.out and .hex

There should be ok for F280039, you need to reproduce this issue with F280025

I mean do you use the same session file? So you either select and program Image 1 or Image 2:

I don't have the F280025. I only have the F280039 launchpad. Anyway, I doubt the difference is relevant.

I always use image 1 only, I always use F280039 to do the test, seem also have the same issue, 

is anything wrong for the hex generation? 

6648.led_ex1_blinky.7z

I also post the F28003x file here

Strong ZHANG said:

is anything wrong for the hex generation? 

No, I don't think so. I checked it is the same contents as your .out file.

Please post your UniFlash session file (.uniflash)

uniflash_8.3.0, i am sure below are what you want. 

Ah. Now I can replicate your problem. Let me invite TI to comment.....

Hello Ki. Ki

I believe this is another instance of the issue I reported in my post from a few weeks ago but didn't quite get to the bottom of:

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1229558/uniflash-run-target-after-program-load-ineffective-cpu-status-incorrect/4657666?tisearch=e2e-sitesearch&keymatch=%20user%3A479799#4657666

Both in the demo project from Strong Zhang (launchxl_ex1_f280025c_demo) and the equivalent example I tried today (launchxl_ex1_f280039c_demo) there is indeed a difference in UniFlash behaviour between a .out and .hex file when all other things are equal.

 'Run Target' is successful for .out only but not for .hex. The latter is my use case in my original post above.

I checked with dis2000 that there weren't additional sections present in the .out file that are missing in the .hex file and, in any case, cycling the power of the launchpad after flashing the .hex does indeed run the program. Furthermore there is no difference in the verbose logs of flashing .out and .hex.

So please can you try to replicate the problem and therefore explain why the .hex load image does not 'Run Target'?

I tried this out on UniFlash. I noticed that if you set the Reset Action to CPU reset after load, this will allow the program to run as expected. Note that you need to have disabled the “Remain Connect after operations” option

Ki said:

Reset Action to CPU reset after loa

Many thanks. That workaround works for me.

Ki said:

When loading the *.hex file, the PC is set to 0x0

You finally got to the root cause, thank you very much. This has bugged me for years!

One possible explanation for the difference is that the label 'code_start' flash entry point (0x80000) only exists in the .out file. Having said that, the flash entry point can be assumed 90% of the time to be 0x80000 (in the case of F28003x and others) since it is a characteristic of the silicon:

Perhaps a UniFlash enhancement to type in the Flash Entry Point address in the UniFlash GUI (saved with the session file) next to 'Run target' might make this behaviour transparent and controllable for hex file users? In the case of a .out file, this box could be greyed out and the contents replaced with the 'code_start' address.

Mock-up:

Bump. Can UniFlash be improved to set a non-zero PC when using hex files please?

I will respond to your other thread of the same topic. We can close this thread for now.

I have been playing around with this a bit today and noticed that if I enable the option to perform a CPU reset after program load, the program will run as expected as long as I disabled the option to remain connected after operations. Maybe this is a viable workaround.