TM4C129ENCPDT: Calling MAP_SysCtlReset() will sometimes hang the processor

Hi,

  SysCtlReset() is a software system reset. There is no reason that it will not reset. It is just matter of writing to the SYSRESREQ bit of the processor's APINT register. I'm not sure why it will hang. What is the message that you are printing? Are you sending the message through UART or through the debugger console? if you are printing a message on the debugger console then it needs a lot of heap memory. Maybe it already hangs before executing SysCtlReset(). If that is the case, the hang is not due to calling SysCtlReset. 

5.2.2.6 Software Reset
Software can reset a specific peripheral or generate a reset to the entire microcontroller.
Peripherals can be individually reset by software via peripheral-specific reset registers available
beginning at System Control offset 0x500 (for example the Watchdog Timer Software Reset
(SRWD) register page 354). If the bit position corresponding to a peripheral is set and subsequently
cleared, the peripheral is reset.
The entire microcontroller, including the core, can be reset by software by setting the SYSRESREQ
bit in the Application Interrupt and Reset Control (APINT) register in the core peripheral memory
map space. The software-initiated system reset sequence is as follows:
1. A software microcontroller reset is initiated by setting the SYSRESREQ bit.
2. An internal reset is asserted.
3. The internal reset is deasserted and the microcontroller loads from memory the initial stack
pointer, the initial program counter, and the first instruction designated by the program counter,
and then begins execution.

The message basically says the processor is rebooting in 4 seconds. It is sending it through the UART and we always see the message. The only other line of code between the print and the call to MAP_SysCtlReset() is delay_ms(4000);

Hi,

  You are saying after the last UART message, the UART stops because the processor hangs somewhere and not able to carry out the software reset using MAP_SysCtlReset, right? Your sequence seems very simple and straight forward and I can't understand why the reset does not take place. What is the delay_ms() function. I want to know if has anything to do with this function. Can you use  SysCtlDelay(g_ui32SysClock * 4 / 3)? g_ui32SysClock is the return value after you setup the clock using SysCtlClockFreqSet(). If you are running at 120Mhz then it will return 120000000 which is equal to 1 second. 

  Can you repeat the problem on all of your boards?

  Can you repeat the problem on a LaunchPad?

Our reboot message is sent out a uart and the ethernet port (I think the messages we are recording are from the ethernet).

Our delay_ms() function checks for upper bounds then calls
MAP_SysCtlDelay(delay_time_ms * (clock_hertz() / 3000));
It's also called everywhere in our code, so if it was a problem, we would see it other places.

We have a 2nd processor on the board that talks to the TM4C over a uart and if it doesn't respond for 10 minutes, it toggles the reset line. This is when we see the TM4C come back.
This problem has been seen on several of our boards (in our test environment), so we know it's not limited to 1 board.

If interrupts were disabled when MAP_SysCtlReset() was called, could that stop it from resetting?

Jeff Hendrix said:

We have a 2nd processor on the board that talks to the TM4C over a uart and if it doesn't respond for 10 minutes, it toggles the reset line. This is when we see the TM4C come back.

Does the second processor check and decode the message that is received from the first processor or it just checks for any message that is received. The reason I ask is because if the message fails certain check by the 2nd processor then the 2nd processor can pull the reset line, can it? I will suggest you check what the uart message is sent by the first one. Perhaps it was a corrupted message or something that is not recognized by the 2nd processor. In this case it is the UART to investigate, not MAP_SysCtlReset. 

I will suggest you also toggle some GPIO pin in parallel to sending the UART message. This way you can analyze if the processor 1 is reset by MAP_SysCtlReset or not. Assert the GPIO pin high after you go through a reset sequence. The GPIO pin should clear the pin once it reaches the next MAP_SysCtlReset event.

Jeff Hendrix said:

This problem has been seen on several of our boards (in our test environment), so we know it's not limited to 1 board.

It if happens to multiple boards, I'm more inclined to think it is software related but it could still be hardware related. 

Jeff Hendrix said:

If interrupts were disabled when MAP_SysCtlReset() was called, could that stop it from resetting?

No, the reset does not depend on the interrupt enable. 

We are looking hard at the boot up sequence to see if there is anywhere it could be getting stuck at.

Not yet, but I think the hang might be when it's rebooting. I opened another E2E to hopefully track that down (you have been helping on that thread)

e2e.ti.com/.../5173652

Ok,

  We will use the new thread for our discussion.