This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Debug error in CCSv6

Other Parts Discussed in Thread: TMS570LS20216, TMS570LS3137, HALCOGEN

I tried demo code LED blinky of TMS570LS3137 for  TMS570LS20216. During debug, the program doesnot enter main(). I get the following error

Should I make any changes in portable.h  to add portmacro.h path for Cortex-R4_TI_CCS5 for using with this microcontroller (TMS570LS20216)? Please explain the necessary changes to be made. I use TMS570 MCU Development kit for the same.

  • Hi,

    There was some problem with your previous post, can you repost the error message? Maybe it's just a project configuration issue, not something related to the microcontrollers.

    Regards

    J

  • I try the FreeRTOS demo Blinky code for TMS570LS3137 modified to TMS570LS20216. The error is as in the following

    Program doesnt enter main(). Plz help to solve this error. I use CCSv6. Board is TMS570 MCU Development Kit

  • Hello Sindhu,

    There are significant differences between the LS3137 and the LS20216 that would need to be accommodated. I will forward your post to our LS3137 device owner so that he can point out specific differences.

    In the mean time, I would suggest using Halcogen to inspect the differences and generate the code. There is support in Halcogen to generate code with the FreeRTOS on the LS20216ZWT device. If you generate this code, you can then compare some of the code differences. Also note that there may be differences in the development kits such that different pins are used for the LED toggles. If the example project you have for the LS3137 still has the Halcogen project files included, then you may be able to reload the project into Halcogen to see any differences; however, this is a long shot since there have been updates to Halcogen generated peripheral drivers and to FreeRTOS.

    Also, there is example code for the LS20xxx devices located on the TI Wiki located at this link: http://processors.wiki.ti.com/index.php/Category:TMS570

  • Thank You Johannes and Chuck for the response! I did change the pin details in accordance with TMS570LS20216 in the program. And I realize the screenshot doesnt paste on the canvas after posting

    This is the error I get. And regarding the link providing programs, I need sample code for TMS570LS20216 FreeRTOS code. I already tried the sample programs in that link.

  • Hello Sindhu,

    The point of my post was to go back to the basics. i.e., rather than try and convert an existing LS3137 program to a LS20216 program, it might be beneficial to start with the LS20216 FreeRTOS shell and implement the application (i.e., blinky program calls) to the LS20216 FreeRTOS shell. LS20216 is an earlier device and there may be features and content within the LS3137 that is not supported by LS20216. To begin, the linker command files will be different as well as anything related to the technology (65nm vs 90nm).

    None the less, I don't see any errors in the screen capture you provided. It is normal for the debugger to execute to main then stop when starting up a debug session. Did you try and run the application at this point? Does the application not execute beyond what you show in the screen capture?

  • Thanks Chuck, that was a great suggestion indeed. I'll start a new program for LS20216.

    Regarding the error, the debug session did stop after this point and CCS does no action beyond this. Am in need of help to correct this issue.

    Thanks!

  • Sindhu,

    In regard to the error you are getting with your debug session, this may be caused by the startup code accessing some peripheral, feature or location that exists in the LS3137 but not in the LS20216. I would recommend having the debug session start at c_init and step through the code until you find where the error is.

    You could begin by placing a breakpoint at the reset vector to stop execution there. Next, place breakpoints at various blocks of code during startup to narrow the scope of which part of the code is causing an issue. This is sort of a binary search methodology to find the offending code.

    Once you narrow the location of the code that is causing the issue, break before the code and step through until you can find the specific code that is causing the issue.

    I would also check the ESM register, reset status registers, etc, to see if there have been any identifiable errors that could help locate the issue.