UniFlash : 'Run Target After Program Load' Ineffective / CPU Status Incorrect

Hi 

I will get back to you on this in couple of days.

Regards,

Rajeshwary

Hey Kier,

Thanks for your question. Will get more information and reply from the Uniflash experts.

Regards,

Charles

Keir - I recall a similar issue reported in the past but I believe that should be fixed now. I will need to try this out to see if I can reproduce this.

I tried this out with UniFlash 8.3.0 on my F280049C LaunchPad. I used the LED blink example that comes with C2000Ware. If I configure UniFlash to run the program after flashing, it does seem to indeed run the program since the LED starts blinking after flashing.

If you disconnect and reconnect the launchpad, does the code run as expected?

Thanks for trying it out.

I also tried the example in \C2000Ware_4_02_00_00\driverlib\f28003x\examples\led and selected the 'CPU1_LAUNCHXL_FLASH' build config.

I started a new UniFlash session but, side issue #1, I noticed that LAUNCHXL-F280039C is not in the list of devices. Is that deliberate or an oversight?

Anyway, I created the session instead from the TMS320F280039C_LaunchPad.ccxml in the example targetConfigs folder of the blinky project.

I loaded the 'led_ex1_blinky.out'. The program does indeed run after 'Load Image' but, Side issue #2, regardless of the 'Run Target After Program Load' setting. LED blinks whether the check box is selected or not.

I next loaded my project.out file. Again the program runs regardless of 'Run Target' setting.

Next I loaded my original session file. The problem has gone so now I'm completely baffled. I don't know why it works now unless something outside of my program area on my LAUNCHPAD has been changed in the process of debugging this problem.

'Run Target' is still ineffective but in the reverse sense now. Is the 'Run Target' effective for your blinky project in the sense that it doesn't run if you deselect it? 

Ki said:

If you disconnect and reconnect the launchpad, does the code run as expected?

Yes, that always worked when I experienced the problem. Also pressing the reset button was always effective.

Side issue #3. I tried to compare two UniFlash session files. They are text files but not comparable in their raw form.

Please can you consider raising an enhancement to "pretty print" .uniflash files by inserting a new line at appropriate points? This would make identifying session file differences much, much easier at the cost of a few kb of white space. For example:

Thanks for your help.

Kier said:

I started a new UniFlash session but, side issue #1, I noticed that LAUNCHXL-F280039C is not in the list of devices. Is that deliberate or an oversight?

Yes, I see that there is no specific entry for the LaunchPad, only for the F280039C CPU. It may be an oversight, I'll have to investigate.

Kier said:

'Run Target' is still ineffective but in the reverse sense now. Is the 'Run Target' effective for your blinky project in the sense that it doesn't run if you deselect it? 

Yes. I disabled that and then re-flashed. Now the LED does not blink and I can see the target status saying the CPU is suspended:

Kier said:

Please can you consider raising an enhancement to "pretty print" .uniflash files by inserting a new line at appropriate points? This would make identifying session file differences much, much easier at the cost of a few kb of white space.

I can give this feedback to the UniFlash engineer.

Thanks

ki

Hi Ki,

Many thanks for raising these.

I think I found the reason for the different behaviour between your blinky and my blinky.

I bet your UniFlash has this setting:

While debugging this issue I must have switched this off. That means disconnection causes running of the program by default irrespective of the setting of 'Run Target'. There's two problem with this:

1) The 'Remain Connected' setting is not stored with the .uniflash file. This means I cannot give a .uniflash file to another team, for example, and necessarily expect them to see the same behaviour. Please can you raise a high priority enhancement to embed 'Remain Connected' in the session file since it has such a dramatic effect on behaviour.

2) If deselecting 'Remain Connected' effectively nullifies 'Run Target', then 'Run Target' should be also be disabled in the GUI (grayed out?) or the user alerted that it is ineffective. Another enhancement maybe?

Kier said:

That means disconnection causes running of the program by default irrespective of the setting of 'Run Target'.

This is correct and expected behavior. When the target is disconnected, it is expected that the CPU will resume execution. This is typically desired.

Kier said:

1) The 'Remain Connected' setting is not stored with the .uniflash file. This means I cannot give a .uniflash file to another team, for example, and necessarily expect them to see the same behaviour. Please can you raise a high priority enhancement to embed 'Remain Connected' in the session file since it has such a dramatic effect on behaviour.

I believe this behavior is set at the tool level and not the session level, hence why this option would not be preserved in a session file. I will discuss with engineering about how to handle this.

Thank you Ki.

Hello Ki

Please can you take a look at this thread since it's highly relevant::

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1234615/tms320f280025-uniflash-can-not-run-target-after-program-load-flash-operation

Thank you.