TM4C129 Reset

Hello Khaled,

You could toggle a GPIO in the Watchdog Interrupt Handler. The example "./examples/boards/ek-tm4c1294xl/watchdog" already does this.

Thanks,
Sai

Hi
I don't want to toggle the pin in the interrupt handler (the first time the watchdog triggers). I want to toggle the pin when the watchdog triggers a Cortex reset i.e. when the watchdog is not serviced on time.
Khaled.

khaled saab said:

I want to toggle the pin when the watchdog triggers a Cortex reset i.e. when the watchdog is not serviced on time.

I can't see a direct way make the watchdog toggle a pin when the watchdog triggers a reset.

Maybe an indirect method will work. E.g.:

a) Attach an external pull-up resistor on a spare GPIO.

b) When the software starts running it outputs a low on the GPIO.

c) When the watchdog triggers a Cortex reset, the GPIO will be tri-stated and will be pulled up externally, thus giving an external indication that a reset has occurred.

Not sure how quickly the GPIOs are tri-stated when the watchdog triggers a Corex reset.

One limitation with this indirect method is that can't tell the difference between the watchdog triggering a Cortex reset, or any other reset reason.

Don't you want to do this on every reset? What reason would there be to only reset the board on watchdog and not other cases.

It's normally something you would do on every reset regardless of source. You can, however, tell the reset source by reading the reset cause register.

Robert

I'm not sure that it will work if we do it every time.

The point is that I want a WDG output pin that asserts when ever the Cortex resets and attach that WDG pin to the board reset circuitry.

I would like to avoid a closed loop reset i.e. the Cortex WDG triggers that triggers a board reset that triggers a Cortex reset that triggers a second "WDG pin" reset....

But from all of your inputs and looking more at the Cortex pins, it seems that there is no true WDG pin.

thanks for all of your inputs.

Khaled.

Khaled,

If I recall correctly, the watchdog interrupt on a typical configuration will be called once to"give you a chance of knowing something went wrong".

Then, if the timer rolls again, it will reset the MCU.

Assuming that the first watchdog timeout should actually never happen, and your application should have been designed in a way as to not let the dog starve, I'd suggest that you simply suicide the board inside the interrupt handler:

dogIntHandler(void)

{

GPIOPinWrite(boardResetLineBase, boardResetLinePin, boardResetLinePin);

SysCtlDelay(someTimeToResetYourBoard);

SysCtlReset();// Suicide

while(1);// Just in case

}

Regards,

Bruno

khaled saab said:

I'm not sure that it will work if we do it every time.

If your board reset does not work every time, that's a big problem. I would address that as a high priority item.

khaled saab said:

I would like to avoid a closed loop reset i.e. the Cortex WDG triggers that triggers a board reset that triggers a Cortex reset that triggers a second "WDG pin" reset....

That's primarily a h/w issue on your reset circuitry. Your micro's reset out should not reset the micro. ever.

And a primary reset will clear the watchdog, pretty much by definition.

khaled saab said:

But from all of your inputs and looking more at the Cortex pins, it seems that there is no true WDG pin.

I've never seen a micro with one. I have seen them with reset out but the reset out is asserted regardless of the reset source.

I think you've confused your self about the way a board reset works. If you have a board reset to set the external devices to a known state you can drive it from the external reset (I.E. from your external supervisory IC) but the board reset should not feed back to the micro reset input.

Reset sources are diode ored so that the reset sources do not interfere. The board reset signal could be a diode or of the reset out from the micro and the supervisory IC, while the micro would come only from the supervisory IC.

Alternately the board reset only comes from the micro, not any external reset. Since you always reset the board on the micro reset you put the H/W in a known state before using.  In this arrangement you lose the power-on reset and have a short period on startup before the board peripherals are reset. Only you know if this is significant enough to push you to a diode ored solution.

In either case it is quite possible with no worries about circular reset chains.

Robert

I would suggest that the watchdog interrupt should never be used.

Robert

Hi Bruno
The watchdog interrupt is normal. After the first interrupt triggers, you should clear that interrupt before the second interrupt is generated. if the first interrupt is not cleared/serviced before the second one is generated a Cortex WDG reset is generated.
khaled.

I understand, Khaled. What I was suggesting you is that you should not wait for the second interrupt:
Make sure you are reseting the watchdog inside your application, as it is normally done.
IF it, only once, reaches the interrupt, then at that moment you control your board_reset GPIO, and then reset the MCU (I mean, don't even wait for a second interrupt - finish the problem right away!)

Hi Robert,
You are correct. I could add a supervisory IC and I'm already using OR'ed resets. But I wanted the watchdog timeout to assert of the WDGOUT pin that will be OR'ed with the remaining reset inputs but not going to back to the micro it self.
All in all, its clear that the WDGOUT don't exist on the micro and I should find an alternative.
thank you all.
khaled.

khaled saab said:

You are correct. I could add a supervisory IC

I wasn't suggesting that. It's just that the only way you run into a circular reset problem is if you deliberately connect a reset out to the reset in.

khaled saab said:

But I wanted the watchdog timeout to assert of the WDGOUT pin that will be OR'ed with the remaining reset inputs but not going to back to the micro it self.

That is very doable as I explained.

What you haven't explained is why it is worth restricting it to a watchdog only.  I don't understand why you don't want the board to be consistent regardless of the reset source.

Robert

You are welcome but I remain curious, why only on watchdog? Surely it makes sense to do this for all other reset sources as well.

Robert

all other resets are routed/hardwired to our system reset and I did not want to create a conditions for possible "loop" reset.
The only one missing was a watchdog Cortex reset.
Khaled

khaled saab said:

all other resets are routed/hardwired to our system reset and I did not want to create a conditions for possible "loop" reset.

I think you are over-thinking this.

If a loop is possible in the case of other resets it is surely possible in the case of a watchdog. The electrical connections have not changed.

It neither case should a reset out from the processor drive a reset in. In neither case should the watchdog be active immediately after reset from any source.

Far more robust not to have your reset process be conditional on how you get to it.

Robert