iMXRT1024 Watchdog External Signals

[GUnderdown]

Hello,

I am having trouble understanding the external signals provided by the RT1024 watchdogs.

My confusion is mostly over Table 52.3 in the reference manual (page 2701). WDOG1_B and WDOG2_B have literally identical descriptions. What is the difference? Or are there just two identical ones so that we can set one to trigger on the software request, and one to trigger on the timeout????

Furthermore, WDOG1_ANY makes not much sense if it's the AND of WDOG1_B and WDOG2_B. It makes more sense if they were OR.

Thanks

[Hui_Ma]

Hi,

There are two Watchdog timers, WDOG1 & WDOG2. The WDOG1_B related to WDOG1 timer and WDOG2_B related to WDOG2 timer.
From the function, both pins has the same function.

WDOG1_ANY is the global watchdog signal. It is essentially: WDOG1_ANY = (WDOG1_B) && (WDOG2_B). WDOG1_ANY goes low if “any” of the WDOGx_B signals assert (goes low).

Wish it helps.

Mike

[GUnderdown]

" WDOG1_ANY = (WDOG1_B) && (WDOG2_B). WDOG1_ANY goes low if “any” of the WDOGx_B signals assert (goes low)."


That is what I am confused on. Given the " WDOG1_ANY = (WDOG1_B) && (WDOG2_B)", that is a logical AND, but you say it goes low if "any" of them go low, which implies a logical OR

[Hui_Ma]

Hi,

Due to the WDOGx_B & WDOG1_ANY signals low (logic 0) means asserted, please refer below table, it is a logic AND relationship:

Thanks for the attention.

Mike

[GUnderdown]

@Hui_Ma 

I have now gotten my custom board for the cpu built and am testing the watchdog timer. I am not seeing any activity on the WDOG_ANY or the WDOG1_B signals. Both outputs are logic LOW no matter what I do. WDOG1_B might be affected by my debugger, because it shares the line with JTAG TDI, but I doubt that because I am in SWD mode.

I have attached a screenshot of my config tools, is there anything you see that would be preventing me from seeing any signal on the outputs? I would expect my outputs to be HIGH until the watchdog resets, at which point they drop low (per pg 2708 RM). I see physical changes in the board (I have setup a blinky led, I turn it on before I enter an intentional infinite loop, and I see it turn off roughly at the right time for the watchdog to time out). Checking the registers, I don't see anything out of the ordinary. My WCR register reads as 0x137C after pausing during my infinite loop.

[Hui_Ma]

Hi,

Please check below registers value to confirm related pins was set as WDOG1 function:

SW_MUX_CTL_PAD_GPIO_AD_B0_14 SW MUX Control Register [MUX_MODE] bits with value 0b111 ALT7;

SW_MUX_CTL_PAD_GPIO_EMC_15 SW MUX Control Register [MUX_MODE] bits with value 0b100 ALT4;

Please check WICR (watchdog interrupt control register) [WTIS] bit to confirm if WDOG interrupt has occurred or not.

Wish it helps.

Mike

[GUnderdown]

WDOG 1 registers (after my blinky LED turns off, which I am relatively confident it the WDOG timing out. After this my debugger breaks at an unknown address)

Register values before timeout:

Here are the mux options for the WDOG1 signals, taken from the reference manual

Mux Control registers for the above pins:

• IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B0_14 0x00000007 ALT7
• IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B0_03 0x00000002 ALT2
• IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_15 0x00000000 ALT0
• IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_39 0x00000000 ALT0
• IOMUXC_SW_MUX_CTL_PAD_GPIO_SD_B0_06 0x00000005 ALT5

We are also not planning on using the interrupt, instead we just have a periodic task in FreeRTOS that will service the watchdog. Code for this task is below.

	Hardware HW = *((Hardware*)pvParameters);

	HW.WDOGStart();


	HW.Blinky2Set();
	HW.Blinky1Clear();
	const TickType_t xDelay = 1000 / portTICK_PERIOD_MS;
	while(true) {
		HW.WDOGService();
		HW.Blinky1Toggle();
		for(;;);	// temp infinite loop to test wwatchdog
		vTaskDelay( xDelay );
	}

void Hardware::WDOGService() {
	WDOG_Refresh(WDOG1);
}

I have re-verified that there is no output on either GPIO_AD_B0_03, as well as at GPIO_AD_B0_14. Both pins remain at 0V (with some noise) throughout the process.

[Hui_Ma]

Hi,

I did a test based RT1024 SDK demo [wdog01] with RT10124-EVK board.

Due to WODG1_ANY using GPIO_AD_B0_14 connects with ENET PHY (ENET_TXD0), I don't test that pad.

I test WDOG1_B using GPIO_AD_B0_03 pin and remove Jumper J49.

I make below two changes:

<pin_mux.c> void BOARD_InitPins(void) function:

  IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B0_03_WDOG1_B,1U);  /* GPIO_AD_B0_03 is configured as WDOG1_B */
  IOMUXC_SetPinConfig(IOMUXC_GPIO_AD_B0_03_WDOG1_B, 0xF0B0U); /* Enable pull-up */

<wdog.c> int main(void) function line111 add below code:

        config.enableTimeOutAssert = true;

 During the test, I could find WDOG1_B signal was asserted (from high voltage to low voltage) when WDOG1 timeout.

Wish it helps.

Mike

[GUnderdown]

@Hui_MaHere's a question though. Whenever the watchdog asserts, the value on the pin doesn't seem to change until I trigger a full POR reset, done by hand by shorting a test point on the reset line to ground.

I would expect that, as soon as the CPU wakes up from the watchdog reset, the pin configuration function would reset this line to the "off" state (logic high as I have observed it). This is to say, I see the WDOG1_B signal go low and stay low until POR.

Is there a way to force the external signals to reset as well?

[GUnderdown]

Using the SDK example, I have been able to reproduce that. I was probably forgetting to add in the code to enable the assert of the watchdog into the example code.

[GUnderdown]

Is there a way to clear the external signal through software? Or does it require someone coming up and pressing the reset button?