RT1062 RTWDOG

[michael_mueller]

I want to simply use the RTWDOG peripheral, with the interrupt before reset. 
I used the MCUXpresso SDK, and generated an example for the RTWDOG (see the code snippet below).

But the behavior is like this :

1) The ISR routine "testWdogIRQ()" is never called

2) In place, the debugger stops at adress 0x202090 (ROM section of the RT)

Do someone have any idea about it ?

Thank you in advance ;-)

-------------------------------------------------------------------

/* RTWDOG_IRQn interrupt handler */
void testWdogIRQ(void) {
/* Place your code here */
__asm volatile ("bkpt");
}

/*
* @brief Application entry point.
*/
int main(void) {

/* Init board hardware. */
BOARD_InitBootPins();
BOARD_InitBootClocks();
BOARD_InitBootPeripherals();

.....

-------------------------------------------------------------------

/* clang-format on */
const rtwdog_config_t RTWDOG_config = {
.clockSource = kRTWDOG_ClockSource1,
.prescaler = kRTWDOG_ClockPrescalerDivide256,
.testMode = kRTWDOG_TestModeDisabled,
.enableUpdate = true,
.timeoutValue = 200,
.enableWindowMode = false,
.windowValue = 0,
.enableRtwdog = true,
.workMode = {
.enableWait = true,
.enableStop = false,
.enableDebug = false
},
.enableInterrupt = true
};

void RTWDOG_init(void) {
/* RTWDOG peripheral initialization */
RTWDOG_Init(RTWDOG_PERIPHERAL, &RTWDOG_config);
/* Enable interrupt RTWDOG_IRQn request in the NVIC */
EnableIRQ(RTWDOG_IRQN);
}

-------------------------------------------------------------------

[michael_mueller]

Hello Sabina,

I use the MIMXRT1060-EVK

I was expecting the following behavior :

1) Init the RT1062 (Clocks, peripherals, etc...)
2) Configure RTWDOG (with INT enabled)

3) Enable the interrupts (NVIC_EnableIRQ(RTWDOG_IRQn))

4) Wait until the RTWDOG barks...

5) RTWDOG_IRQHandler is called

6) system reset, restart to 1)

But this is the behavior now (with the SDK example evkmimxrt1060_rtwdog):

1) Init the RT1062 (Clocks, peripherals, etc...)
2) Configure RTWDOG (with INT enabled)

3) Enable the interrupts (NVIC_EnableIRQ(RTWDOG_IRQn))

4) Wait until the RTWDOG barks...

5) The interrupt is not called, but debugger stops in ROM section (0x202090)

6) Then I continue the debugging, and the system do a reset (as excpected)

The interrupt handler "RTWDOG_IRQHandler " is never called  :-S

PS: I just use the SDK example "as is", without modification.

Best Regards,

Michael

[mjbcswitzerland]

Michael

How are you testing the watchdog interrupt? Don't forget that after the watchdog interrupt is called 255 clocks before the watchdog reset takes place. Trying to verify with a debugger may not be the best approach to take - I would signal the interrupt has taken place of a GPIO output.

I always use the interrupt to ensure that the FlexRAM is set back to a state that the ROM loader can handle otherwise (if one has remapped FlexRAM) it can cause the ROM loader to fail and thus no recovery at all.

Below are snippets from the uTasker project's use of WDOG3

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

// If the watchdog fires this interrupt is called 255 clock cycles before the watchdog reset takes place
//
static __interrupt void wdog3_irq(void)
{
    IOMUXC_GPR_GPR16 = (IOMUXC_GPR_GPR16_RESERVED | IOMUXC_GPR_GPR16_INIT_ITCM_EN | IOMUXC_GPR_GPR16_INIT_DTCM_EN); // set the FlexRAM layout back to that taken from the eFuse setting (default configuration)
    FOREVER_LOOP() {}
}


Initialisation:

#define WATCHDOG_TIMEOUT_SECS    2


UNLOCK_WDOG3();
WDOG3_TOVAL = ((WATCHDOG_TIMEOUT_SECS) * 32000);

WDOG3_WIN = 0;

WDOG3_CS = (WDOG_CS_INT | WDOG_CS_CLK_LPO | WDOG_CS_FLG | WDOG_CS_CMD32EN | WDOG_CS_EN); // enable watchdog with WATCHDOG_TIMEOUT_SECS timeout (32kHz reference)

fnEnterInterrupt(irq_RTWDOG_ID, 0, wdog3_irq);                       // enter WDOG3 interrupt (highest priority)
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[michael_mueller]

Hi Mark ;-)

I never tested to toggle a GPIO to test the interrupt call. And I think I won't do it, because I though I could use the watchdog interrupt as a developper  debugging purpose. 

It may be my bad interpretation of : "Optional timeout interrupt to allow post-processing diagnostics" of the reference manual. My goal was to provide the developper a break, for memory and process analysis, just before the resets happend. That why I tested by adding an "asm bkpt" as first instruction of the handler. 

But if the watchdog is not stopped after the interrupt, while debugging, then it is not usable at all for my purpose. What I don't really understand is the " Next, the watchdog delays 255 bus clocks (from the interrupt vector fetch, not the reset-triggering event) before forcing a reset, to allow the interrupt service routine (ISR) to perform tasks (like analyzing the stack to debug code)." That mean, if I cannot stop the reset process while debugging, I have to save in non-volatile (slow) areas the stack and some other interesting memory? 

Regards,

Michael

[mjbcswitzerland]

Michael

You could try disabling the watchdog to see whether it maybe doesn't generate the interrupt; this is something I never tried and maybe it allows you to stop the reset taking place (?)

If you reserve an area in SRAM that is not used by the application it will be preserved across resets and so you can quite quickly save a context, or such there for analysis after the reset has taken place.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[michael_mueller]

Mark

I tried, like you proposed, to toggle a GPIO. I generated a pulse of ~10us.

Below is the test routine :

static void rt106xRtwdHandler(void)
{
    // First we clear the interrupt flag
    g_rt106xRtwd.CS |= 0x00004000;

// If this part is uncommented, then the pulse never comes, and debugger is not halting
//#ifdef EMU
//    __asm__ __volatile__ ("bkpt 0":::"memory");
//#endif

    rt106xGpioSetOutputLevel(&m_debugPin, RT106X_GPIO_OUT_LEVEL_HIGH);
    halDelay(10); // Wait 10us
    rt106xGpioSetOutputLevel(&m_debugPin, RT106X_GPIO_OUT_LEVEL_LOW);

// If this part is uncommented, then the pulse comes, but debugger is not halting
//#ifdef EMU
//    __asm__ __volatile__ ("bkpt 0":::"memory");
//#endif
}

My feeling is, the breakpoint actualy works, but the debugger never halt. The reset occurs here ~70us after the IRQ has been called.

Even if I would disable the RTWDOG in the IRQ (is it allowed at all ?), the reset occurs. It looks like unconditional. After all it's the job of the Watchdog... :-D

Do you have more ideas ?

If not, I think we may close the thread. I will try the other watchdogs for our application, that may be usable for our use-case.

[mjbcswitzerland · Accepted solution]

Michael

I doubt that the debugger can halt after the break-point is hit since the reset will already cause such operation to be disrupted as it takes place so quickly after the break-point is hit.

If it is not possible to stop the watchdog from resetting it means that there are a limited number of instruction cycles to do what you want and if these are not adequate it will be necessary to either restrict what you do or try to find an alternative method.

What you could of course do is to use a general purpose timer with a slightly shorter timeout than the watchdog timer - you retrigger it together with the watchdog retrigger. If there is a failure the timer interrupt will interrupt first, which allows you more time to save information and you could then also retrigger the watchdog to give yourself more time if you like.

Whether using the interrupt from the watchdog timer or from a different timer you will need to ensure that you never block interrupts otherwise you may have code failing in a protected region that can't be interrupted. In this case these timer interrupts need to be given highest priority and protected regions mask lower interrupt priorities rather than all interrupts.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[michael_mueller]

Mark,

Thank you very much for your time ;-)

The RTWDOG is finally not the best method for us. I try to use the normal WDOG with the interrupt configured like a half second before the reset, and it work like intended. The watchdog interrupt can be halted (only in our debug build), then we can do a manual analysis, then it will flush like filesystem buffer, save some datas, etc...

> What you could of course do is to use a general purpose timer with a slightly shorter timeout than the watchdog >timer - you retrigger it together with the watchdog retrigger. If there is a failure the timer interrupt will interrupt first, >which allows you more time to save information and you could then also retrigger the watchdog to give yourself more >time if you like.

We did that before on our Coldfire processor. But if the WDOG gives us this mechanism, then it's better to use it.

We can close this thread ;-)

Thank you very much for your help!

[Sabina_Bruce]

Hello Michael,

Hope you are doing well.

Could you please clarify what you mean by "with interrupt before reset".

I recommend to refer to example provided in the SDK for the RTWDOG. 

Best Regards,

Sabina

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------