LAUNCHXL-F280049C: Application performance difference when loading from flash with and without debugger connected

Hi Wallace,

emulation boot mode when debugger is connected is explained next flow char Fig 4.2. You can also refer to workshop

https://dev.ti.com/tirex/explore/content/c2000_academy_0_09_00_00_eng__all/c2000Academy/archieves/F28004x/resources/F28004x_Microcontroller_1-0.pdf

Hi Santosh:

I have followed both the emulation boot mode in Fig 4.2 and the standalone boot in Fig 4.3 but I did not find any differences that actually happen to the device in those flows. They seem to just have different ways of getting to the same flash entry point by checking the boot keys and pins. So I don't see a reason for the difference in performance.

We also don't do any custom or alternate boot modes, we just use the standard GPIO24/32 = 1/1, so boot mode from the LP switches.

Any other ideas?

Hi Wallace,

What do you mean by robustness performance is consistently not as good? You said code runs from the Flash as expected, so not sure what parameters you are looking as comparison point for both boot options.

Yes, when you connect the debugger, it goes through Emulation boot flow Vs Standalone when not connected. Also you can always load through CCS without gel file by removing the gel from the target connect. There are differences in both boot mode options, but it really boils down to what issues you are seeing when you do standalone boot, that will help narrow down the problem.

Best Regards,

Nirav

Hi Nirav:

The project is motor control. By robustness performance, I mean:

In emulation boot, our IPD works properly and commutates follows properly like 20+ times in a row without issue.

In standalone boot, our IPD seems to fail every couple times and commutation does not follow properly (it works sometimes).

As you know, this is not super simple to debug, and I'm sure it's possible by putting more time utilizing the real-time debug feature. But I figure since this behavior seems to be emulation vs. standalone boot flow, I was trying to isolate and figure out what else changes to the device between the 2 boots.

And honestly it doesn't seem like much. As we both agree, looks like we're reaching boot from flash in both modes, so (probably) no issues with the boot pins or emu boot or OTP settings.

The only other thing I can think of at this point is in emulation boot, you get the help of the GEL file doing some initialization for you. It seems like the only thing the F280049C GEL file is doing is initializing memory (no PLL or anything that I saw in other C2000 devices). That might make sense if we were accidentally using some uninitialized variable or something. But no resolution reached yet.

By the way, when I try to load through CCS without the GEL file, I get this error:

Any thoughts on why that is?

Wallace,

When it  does not work, what is the failure? Does it gets stuck somewhere? where is the PC?

Hi Santosh:

The program doesn't actually get stuck anywhere, the PC goes through the same code as normal, but either some of the ADC/COMP data is weird or behaving weirdly, thus the calculations we do afterwards for commutation is faulty as well. If we start commutation again without resetting anything, it can work without observable issues, so it's only certain iterations during the same program run that cause this issue.

As mentioned above, for some reason, we can't reproduce this issue in emulation boot, but only in standalone flash boot. We also observe this issue in EMU_BOOT_FLASH from the GEL script with debugger attached, oddly enough.

My thoughts can't help but think about root cause being something in the GEL script. When I look at the emulation boot flow, I was reading some conflicting messages about where the boot code execution fits in. Can you help clarify? I would test emulation boot without GEL script, but as mentioned in my earlier response, it's not working.

Do you have any thoughts as to which parts of the GEL script would be relevant to move to our application?

• I tried the MRAM/LSRAM/GSRAM clearing at the top of main() [maybe need to do it somewhere earlier, let me know]
• I tried Device_Config() at the top of main() [not sure what it actually does]
• I didn't modify anything in device.c, but it has a strange note about #ifndef _FLASH Device_Cal() #endif and says it should not be called in standalone mode.

Any other thoughts?

Wallace,

We need to narrow the issue. Can we make a small code which can consistently fail.