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.

dataEntry is occurred when debug mode is not used.

Other Parts Discussed in Thread: TMS570LC4357, HALCOGEN

Hi TI,

I having a problem with data abort.

I am using TMS570LC4357 with HalCoGen Generated freeRTOS files and with TI recommended lwIP library


So I flash my TMS570LC4357 with my code and after that I enter into debug mode, then click on Run button in my debug window. At this time every thing is fine.

My controller is working good as my expectation.
 (i.e: When I am in debug mode, Everything is perfect. My controller doesn't show any error and data abort is not occurred.)

But after I unplug everything (except Serial port communication line and power line.), I just power my TMS570 controller.

At this time, my controller is getting locked in dataEntry line of HL_sys_intvecs.asm file. (I added sciPrint() fucntion to Print a character after dataEntry line of HL_sys_intvecs.asm file. In this way only I came to know that this is happening out of debug session.)

If this happens in the debug mode, I think, I can try solving this issue. But unfortunately this is happening only after I exit from the debug mode.

So I cannot find a way to resolve this. And I dont why this is not happening in the debug mode?

Please anybody expalin me why is this happening?

(I am really new to arm architecture. So I want to know what and why it is happening.)

Please anybody explain me.

Thanks in advance.

Regards,

Karthikeyan.K

  • Karthikeyan,

    The example

    and the instructions that we posted here:

    to make it work on the lc4357 launchpad, are not freertos based, and do work standalone (i.e. no data abort problem if you run from flash without CCS connected).

    So not really sure what is causing your problem;  but suspect it may be something to do with how you added FreeRTOS to the mix.

    The recent versions of FreeRTOS have added MPU support and by default tasks that are created are created in User mode - which would block off a lot of the hardware registers on the device.  You may be running into this type of issue.   There is an option you need to use when you create a task to make it have Privilege.   There should be some posts on this forum about that topic.

    You can connect a debugger after your program crashes, and inspect the state of the device.  Instead of doing a 'debug as' which by default automatically reloads your program, just open the target configuration window and launch a debug session.   Then 'connect' and you should see the program counter at the data abort vector if this is where you are getting stuck.  Then you can analyze the coprocessor registers that tell what the address was causing the data abort (if it was precise) and/or the LR to at least figure out what area of code you executed when the abort occurred which will probably narrow the issue down really quickly.

    Best Regards,

    Anthony