TMS320F28379D: Code works in debug mode and doesn't work in Release mode

Hello Saddam,

Saddam Ansari said:

However, upon transitioning to release mode, unexpected behavior such as erratic outputs, failure to complete required tasks occurred.

Can you please provide specifics on the exact issue you're seeing? Have you tried comparing execution for running from Flash and RAM for both debug and release modes? In debug mode, are you selecting resume or are you stepping through the code? If you're using Flash, have you tried using the maximum Flash wait states in release mode?

Omer Amir said:

Can you please provide specifics on the exact issue you're seeing?

-> we are using 3 timer interrupts(32ms, 32ms, 50ms), and each timer ISR have lots of functions running simultaneously, and now when i have added couple of functions more, then its not working desirably 

Omer Amir said:

In debug mode, are you selecting resume or are you stepping through the code?

-> we are selecting resume, but we have tried stepping as well. we have tried both and both are working in debugging mode

Omer Amir said:

If you're using Flash, have you tried using the maximum Flash wait states in release mode?

-> can you tell me, weather i have to write code for it or i have to modify in properties, can you help how to do it ?

PFA  of the files for reference

map_and_command_files.rar

Best Regards,

Saddam

Hello Saddam,

Just to verify one thing, in the debug mode are you executing with optimizations turned off?

Saddam Ansari said:

-> can you tell me, weather i have to write code for it or i have to modify in properties, can you help how to do it ?

You can use the driverlib function Flash_setWaitstates to set the Flash wait states. This function modifies the FRDCNTL register:

Hi Omer,

Omer Amir said:

Just to verify one thing, in the debug mode are you executing with optimizations turned off?

-> Yes, optimization is turned off, in both the modes i.e debug and release mode.

-> Called this function "Flash_setWaitstates(FLASH0CTRL_BASE, DEVICE_FLASH_WAITSTATES);", (DEVICE_FLASH_WAITSTATES = 15) in main file before while(1), but the problem didn't solved.

Best Regards

Saddam

Hi Ki

Ki said:

I assume you are referring to the "debug" and "release" build configurations.

-> No.

What i am referring is explain below : 

a) Debug Mode : code is loaded with debugger connected and play button is clicked and code works fine.

b) Release Mode : code is loaded with debugger and play button is clicked and debugger is removed and the system is reset and code gets stuck.

NOTE : We are only using debug in build configurations.

Best Regards

Saddam

Saddam Ansari said:

b) Release Mode : code is loaded with debugger and play button is clicked and debugger is removed and the system is reset and code gets stuck.

What do you mean "debugger is removed". Are you terminating the debug session or are you simply doing a "run free" and detaching the debug probe?

Hi Ki,

Ki said:

What do you mean "debugger is removed". Are you terminating the debug session or are you simply doing a "run free" and detaching the debug probe?

Yes, I am simply doing free run by clicking the play button(green color), and after couple of seconds terminating the debug session, and then detaching the debug probe and resetting the system by turning power off and then on. I am doing this simply for downloading the code into the controller.

At first i thought there is a bug in the code, but if there is a bug then how the code is running in debugging mode(i.e when debugger is connected and i am stepping into the code), i can't find the actual problem.

NOTE : Build Configuration is in debug mode.

Best Regards

Saddam

Saddam Ansari said:

Yes, I am simply doing free run by clicking the play button(green color)

The green play button does not do a "free run". It does a standard debug run. 

See this section regarding a free run (the note at the bottom of the section):

https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_debug-main.html#after-launch

This option will run the target and then properly detach the debugger from accessing the target. A standard run does not do that as the debugger will continually poll the target while the target is running and also make any real-time debug accesses if applicable. At this point you can physically disconnect the debug probe from the target while the debugger is still running.

Try this but do not terminate the debug session yet. See if this works as expected. Then try terminating the debug session. What is the result?

Thanks

ki

HI Ki

1) Understand one thing that i want to load my code (i.e CCS project) into my microcontroller as i have mention above, and i am not using any external tools like uniflash to do this task.

2) So how i am loading the code in microcontroller without using uniflash ?

Answer : I am connecting the debugger to microcontroller via jtag pins, in CCS after launching the code in debug mode by clicking the 'bug symbol' the perspective changes from CCS Edit to CCS Debug, and then clicking the resume button(green color) for a debug run.

2a) Till debug run code is working properly, but as i remove the debugger and restart the system(i.e controller) the code gets stuck.

3) Till now everytime the code was running same in "debug run" and "debug run + after restarting the system".

NOTE : I think online meeting should be arranged if the above the points i have mention in this reply are not clear, because me showing the problem is much more easier to under rather than explaining.

Best Regards

Saddam

Saddam Ansari said:

2a) Till debug run code is working properly, but as i remove the debugger and restart the system(i.e controller) the code gets stuck.

Thanks for the clarification. This is the key point. You use CCS debugger to flash and then run the target. It all works. Then you terminate the debugger, restart the system (not attached to a debug session) and the code gets stuck.

When you restart the system (I assume power cycle or reset), the environment has changed. Note that when you start a debug session with CCS, the debugger often does some target initialization when it connects to the target. This is often done with startup GEL files. These actions may be needed to put the target in the proper state to run correctly. You would be missing these steps when your restart the system and run the code without in a debug session. Did you account for this?

In any case, this is not a CCS issue but more an environment issue. I will bring this attention to the C2000 experts for further comment.

Thanks

ki

Hi,

But these were the same conditions i was applying earlier, why these problem occurred now, by adding more functions in my code ?

Best Regards

Saddam

Saddam Ansari said:

But these were the same conditions i was applying earlier, why these problem occurred now, by adding more functions in my code ?

Perhaps. I will defer to the C2000 experts on this.

Saddam,

            When code works with the debugger connected but not in standalone mode, it is likely because of the presence initialized constants in RAM. Please check for the presence of any in your project. The below post provides helpful tips:

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/878674/faq-flash---how-to-modify-an-application-from-ram-configuration-to-flash-configuration 

The upcoming weekend is a long weekend in the US. Please expect a response by early next week.

Hi,

Hareesh Janakiraman said:

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/878674/faq-flash---how-to-modify-an-application-from-ram-configuration-to-flash-configuration 

In our project, we have already used flash linker cmd file, configured boot pins to flash boot.

All the initialized sections are mapped to Flash memory in the Flash based linker command file as you can see i have provided in .zip file in earlier response.

Virtual meeting by TI can be helpful in order to solve this problem.

Best Regards

Saddam

Hello Saddam,

Saddam Ansari said:

2a) Till debug run code is working properly, but as i remove the debugger and restart the system(i.e controller) the code gets stuck.

When you say the code gets stuck, are you able to verify where it gets stuck? Have you tried reconnecting the debugger and just connecting to the device without loading the code (i.e. launch the target configuration ccxml file and connect to target without loading code)?

Saddam Ansari said:

But these were the same conditions i was applying earlier, why these problem occurred now, by adding more functions in my code ?

Can you please show what exact code you added that made the program different?

Hi,

Omer Amir said:

When you say the code gets stuck, are you able to verify where it gets stuck?

-> No, because the code doesn't works in standalone mode, and it works in debug mode, hence i can't find out where it gets stuck.

Omer Amir said:

Can you please show what exact code you added that made the program different?

-> I can show you the code in online meeting.

Hello Saddam,

I have sent you a friend request, please accept and we can message on coordinating a meeting.

Done

Continuing this offline, I will respond if there is any new information.

Hi Guys,

Had nearly same issue with x49c MCU, the build in both run cases debug, not release. Recommend enable CCS memory map view to determine where any #pragma sections are being loaded in SRAM, developers may have to combine sections to isolate issues. Secondly remove later added ISR functions until lockup stops, identify the function or ISR causing the lock up issue. The debug emulator with JTAG simulator does not seem to execute code as rapidly as standalone C code run by the CPU without JTAG control.  

Regards,