• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 380 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS570LC4357: Processor getting stuck in halted "safe state"?

Micah Richert
Prodigy 10 points

Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

I am having an issue with the Launchpad XL2 (TMS570LC4357).  When the processor has the watchdog go off and configured to reset the system seems to get stuck in the "safe state" where the system is halted but not booting back up again (note, this is not abort).  If I attach a debugger when it is in this state I see PC is set at 0, and can access other registers (such as confirming that the system reset due to the watchdog).  However, the system won't start up until I hit the Reset or  PORRST buttons or power cycle the device.  Further, this seems to also be happening when I am guessing a bus-fault happens, i.e. the system gets into this halt state. I haven't been able to confirm this truly is a bus-fault because it happens randomly when I am trying to get Ethernet working correctly and have been unable to debug sufficiently.

I have two questions related to this.  First, how do I configure the system to automatically reboot instead of getting caught in this "safe state"?  For the case of bus-faults, I would prefer to trigger an interrupt so that I can inspect what caused the problem, is there a way to configure the system for this?  I have been investigating the ESM but none of the documentation or interfaces seem to point me in a useful direction.

  • 0
    TI__Guru**** 201486 points

    Hello Micah,

    The sys_startup.c generated through HALCOGen doesn't work well after the device is watchdog reset. 

    The system, VIM, ESM etc are not initialized. Please insert the initialization code between user code area 15.

  • 0 in reply to QJ Wang
    Prodigy 10 points

    Hi QJ,

    Thank you for responding.  However, putting code in the suggested section has no effect on getting stuck in this halt/"safe state".

    I want to know what this "safe state" is and how to prevent getting stuck in it; as in I want the system to restart without getting stuck.  Some additional information for when it gets stuck in this state, the program counter (PC) is 0 and LR is 0xC.  Also, reading from flash, i.e. reading memory from 0x0 and above is not reliable, sometimes I can read values and sometimes it is read by the debugger as all zeros.

  • +1
    Prodigy 10 points

    There are two issues here.  First, is the issue pointed out by QJ.  Second, is the default interrupt handlers defined in HL_sys_intvecs.asm, I strongly suggest it should be changed to the following:

    Previously the interrupt handlers for everything other than resetEntry were not sufficiently defined which then caused them to go into an infinite reset loop if they ever got activated.  The infinite reset loop then loses all information about what caused the interrupt in the first place.  By having them point to phantomInterrupt instead one can attach a debugger or customize phantomInterrupt to report what the error was.

    Also, in regards to the first issue, I also strongly suggest changing HL_sys_startup.c to do a proper boot for all reset conditions and then report reset source/reason to the application layer of your code.  One way to do this would be to either get rid of the switch statement all together or change the primary startup condition to use "default:" and remove the other cases.