AM2634: Watchdog expiry time is too long

Hi Thomas,

Thomas Meier said:

From the configuration, I would assume the watchdog to reset my controller after 200ms. While observing a toggling GPIO, the measurement shows, that the watchdog expires not earlier than 640 ms after the last clear signal was sent to the watchdog. How can this be?

I digged down into the generated .c files and noticed an entry in the ti_power_clock_config.c file, which sets up the clock frequencies for the different module in an array called gSocModulesClockFrequency[]. There, the clkRate value for the WDT0 is set to 5MHz. Where is this value coming from? Why is this 5MHz?

I think the 5 MHz clock frequency is a SW bug. The WWDT clock select is set for SYS_CLK @ 200 MHz. The maximum clock divider value before the input to the WWDT functional clock is 8, so there is no way to generate a 5 MHz clock given the 200 MHz clock input (200/5=40, 40>8).

You can see the values of the clock select and divider by looking at these MSS_RCM registers:

• WDT0_CLK_SRC_SEL, address = 0x53208128
• WDT0_CLK_DIV_VAL, address = 0x53208228

The WDT frequency can be changed by modifying this file: <SDK>\source\drivers\.meta\watchdog\soc\watchdog_am263x.syscfg.js. For example, change the value of "let wdt_func_clk" from 5000000 to 25000000. Then 200000000/8=25000000 is a clock frequency allowed by the hardware.

I experimented with the WDT example code documented here: https://software-dl.ti.com/mcu-plus-sdk/esd/AM263X/08_05_00_24/exports/docs/api_guide_am263x/EXAMPLES_DRIVERS_WATCHDOG_RESET_MODE.html

I noticed another small mistake in the application code function watchdog_reset_mode_main(). In the following code, the constant for converting msec to usec should be 1000, not 100:

/* wait for (expiry time/2 ) time */
ClockP_usleep((wdtExpiryTimeinMs*100)/2);

I updated the WDT period to 200 msec. I also added a GPIO output to check timing. My logic analyzer capture of the GPIO output shows the WDT timing now correct. I've shared by example code below.

Thomas Meier said:

Further, I don't get, what the "Digital WDT Window Size" is for. Can you explain what this value is?

This is described in the TRM please see:

• Section 13.5.1.4.1 RTI Digital Windowed Watchdog
• Figure 13-274. RTI Digital Windowed Watchdog Timing Example

Basically, this is a window within which the WDT must be serviced. The WDT action (reset or interrupt) will be tripped if the WDT isn't serviced within the window the or the WDT servied outside the window.

Thomas Meier said:

And finally, during debugging I believe to have stumbled over a bug in the MCU Plus SDK (version 08.05.00.24): (File soc_rcm.c, line 84) In the gXTALInfo array the Finp value gets initialized to the MHz value of the external oscillator (25000000Hz converted to 25MHz). But in the function SOC_rcmGetPeripheralClockFrequency (file soc_rcm.c, line 1702) this value is assumed to be in Hz.

 I agree, the function SOC_rcmGetPeripheralClockFrequency() return 25 Hz for the SOC_RcmPeripheralClockSource_XTALCLK clock.

Thomas Meier said:

Where can I report this issue?

I'll file a bug report for the issues you discovered.

Regards,
Frank

watchdog_reset_mode_am263x-cc_r5fss0-0_nortos_ti-arm-clang.zip

Hi Thomas,

This is a bug in the SDK where the input frequency to the WDT is wrongly set there by improper working of expiry time. We already have a bug for this internally filed to fix this [MCUSDK-8989] WDT Reset takes more than expiration time - Texas Instruments JIRA posting it here for tracking purpose. Currently we are able get the WDT app working in conjunction with SBL QSPI after the input frequency is fixed properly. 

This example will be available in the MCU+SDK 8.6 release which is planned to be released in the end of next week. Hope this helps.

Thanks