TMS320F28379S: Code Not Executing from Flash After DCSM Implementation on TMS320F28379S

Hello,

When you say the code doesn't run, what do you see exactly? Does the debugger disconnect? Does the code seem to hit a breakpoint somewhere?

One of two things could be happening:

1) ECSL protection: ECSL protection takes effect anytime a debug halt occurs or an attempt to connect to the device by the debugger occurs when the program counter is in a secured memory region. Resetting the device will cause the DCSM to become locked and activate ECSL protection. To use a debugger with DCSM enabled, you must be using "Wait Boot" mode instead of flash boot so that ECSL does not cause the debugger to disconnect.

2) Your code, which functions normally when DCSM is disabled, no longer works properly because code in an unsecure region is attempting to access secure memories.

Thank you,

Luke

Hi Luke,

As per my observation

Rajamurugan Kaleeswaran said:

Observations:
1.After initial unlock (without reset), uploading the application via CCS works fine.
2.But after a power cycle or reset, it doesn't run.
3.Using UniFlash, I unlocked with the correct password and flashed the application. It gets uploaded successfully, but again, it doesn't execute post-upload or after a reset.

1.What is the use of wait boot mode I need to run my application code from Flash. so I made my get boot to flash boot.

2.How to find which part of code in unsecure region is accessing the code in secure region I've only implemented basic LED blink code.

Luke Jones said:

When you say the code doesn't run, what do you see exactly? Does the debugger disconnect? Does the code seem to hit a breakpoint somewhere?

I can say that code is not executing from the flash memory after reset and same while uploading code using uniflash after unlocking.

but the code was running after code upload using ccs after unlocking.

kindly provide what and where should i look to solve this issue 

Hello,

Wait boot is for debugging only when DCSM is enabled. It allows you to connect to a device via JTAG even if the application code entry point is located in a secured memory region.

You can select wait boot temporarily by modifying the boot mode select pins.

It seems the LED does not blink even when JTAG is not connected. Can you share the values you've programmed at addresses 0x78000 to 0x78040 by taking a screenshot of the memory browser?

Thank you,

Luke

Rajamurugan Kaleeswaran said:

1.After initial unlock (without reset), uploading the application via CCS works fine.
2.But after a power cycle or reset, it doesn't run.

Hi,

We have the very same issue x49c MCU after GrabRam GrabEXEonly locked (secured) B0Z1, B1Z1 sectors 0-7. And default link pointers LP (0x1FFFFFFF) no longer match DCSM register LP values (0xFFFFFFFF). Oddly B0Z1 (0x5F000) and B0Z2 (0x5F100) remain (0xFFFFFFFF) after LP MSB bit 28 was changed to a legal value per TRM Fig.3-18. Oddly Boot to Flash after soft reset works great CCS debug run application, after GEL code unlocks default CSMPWDKEY's. Even boots to flash after UniFlash soft reset and not after POR or hardware reset. 

Though what seems to have caused GPIO boot mode select pins to be ignored; DCSM register BOOTDEF = 0xFFFFFFFF is asserted whenever default link pointers are changed from 0x1FFFFFFF and DCSM logic ignores OTP not being programmed 0x5F. Seemingly the boot mode pins are being set to factory after reading the OTP locations by default. Perhaps one alternative, make the application not relay on GPIO pins program 0x5A into the OTP shown below.

Hi Luke,

Kindly find the mentioned screenshot below and  suggest further steps or solution for this issue.

 Perhaps also look at DCSM register 0x5F000, 0x5F050 and note any link pointer error flag bits being set. Our boot issue turned out to be software related, removed CMD sections #pragma, loading functions into high speed LSRAM. Worked great in debug, not on POR or hard reset.

Took a while to pin down which one the cause being there were many #pragma sections. 

Best of luck.

Hi Genatco,

Genatco said:

Perhaps also look at DCSM register 0x5F000, 0x5F050 and note any link pointer error flag bits being set

Thanks for your replies and help so far.

I'm still facing the issue where my code runs fine in CCS debug , but doesn't execute after a power cycle or hardware reset or flashing via UniFlash, when DCSM is enabled.

From what you mentioned, it seems that the issue might be due to functions or sections of code being placed in LSRAM using #pragma CODE_SECTION or through the .cmd file.

I'm still new to this, and I don’t fully understand how to resolve this.

SO my Question is, 

1.Is there any reference documents or links and I’d really appreciate if you could please guide me on how to solve this issue with steps.

2.After implementation of DCSM how to check it is implemented correctly.

3.After DCSM implementation now while uploading code using CCS, The code only gets dump while the controller in SCI boot mode and i'm getting a Low power mode error when controller is in Boot to Flash mode.

Kindly find the previous chats for reference for my setup.

Thanks again for your time and support!

Hi Rajamurugan,

1. You can consult the DCSM section in the SysCtrl chapter of the TRM and look up other posts on E2E to check if you're seeing a similar issue.

2. You can unlock the DCSM and look at the OTP locations (0x78000 to 0x783FF) to check that you've programmed the correct OTP values.

3. If you've secured the flash via DCSM you won't be able to connect over JTAG if you're in flash boot mode.

Thank you,

Luke