Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob

EZ-PD™ PMG1 MCU: Usage of watchdog timer (WDT) in USB PD firmware - KBA237291

EZ-PD™ PMG1 MCU: Usage of watchdog timer (WDT) in USB PD firmware - KBA237291

Infineon_Team
Employee
Employee
50 replies posted 25 likes received 25 replies posted

Community Translation: EZ-PD™ PMG1 MCU: USB PDファームウェアにおけるウォッチドッグタイマ(WDT)の使用方法 - KBA237291

This KBA explains how the watchdog timer (WDT) is used in the USB PD firmware implementation for EZ-PDTM PMG1 (Power Delivery Microcontroller Gen1) MCUs for USB Power Delivery (PD). In addition, it also provides details on configuring a WDT-based system reset generation in the USB PD firmware to protect the system from unexpected firmware crashes or lockup.

  1. Does the USB PD firmware use the watchdog timer (WDT) to handle PD functionality operations?

Yes. The USB PD firmware implemented on EZ-PDTM PMG1 devices use the watchdog timer (WDT) as a periodic interrupt generator to trigger software timers that are critical in carrying out many PD-related tasks.

  1. Can the WDT be used as an independent timer for system reset generation to protect the CPU, in the USB PD firmware?

In the USB PD firmware, the WDT is responsible for both the timing of the PD stack operations by triggering periodic interrupts as well as reset generation to protect the CPU. However, there are a few points to be considered in this dual logic implementation as discussed further in this article.

Watchdog timer in EZ-PDTM PMG1 devices:

The WDT in PMG1 devices is a 16-bit free-running, wrap-around, up-counter which runs from the LFCLK
(low-frequency clock) generated by the ILO (Internal Low-frequency Oscillator) (~40 kHz). The WDT generates periodic interrupts each of configurable period up to 1638 milliseconds (with a 40-kHz clock).

Infineon_Team_0-1679306273344.png

Figure 1 Watchdog timer block in EZ-PD™ PMG1 devices

The two parameters that can be used to adjust the interrupt period are:

  • Match value
  • Ignore bits

Whenever the WDT count reaches the match value, an interrupt will be generated. However, the next match value should be calculated by adding the current WDT count value to the match value, in the WDT ISR (interrupt service routine). Similarly, ignore bits specify the number of bits to be ignored in the 16-bit WDT count register.

For example, setting the ignore bits to ‘2’ will make the WDT a 14-bit counter. When the WDT is used to protect against system crashes, the WDT interrupt must be regularly cleared by feeding the watchdog from the main firmware loop. If the firmware does not clear the WDT interrupt for two consecutive times, the third match event will generate a hardware reset.

The WDT has the following general applications:

  • Periodic interrupt generator to execute various tasks in the firmware
  • Reset generator to trigger a system reset in case of an unexpected firmware execution path or brownout
  • Wakeup source in low-power modes (Sleep and Deep Sleep)

WDT usage in the USB PD firmware:

  1. WDT as a trigger timer for PD firmware

In the USBPD firmware, the WDT is configured as a timer to generate periodic interrupts. The associated interrupt service routine (ISR) is used to trigger software timers. These software timers are responsible for various Type-C and PD related tasks. If the system operates in Deep Sleep mode, the WDT is also used to wake up the system when required to execute the periodic PD tasks. This is ideally suited for
battery-powered applications where the system is to be operated in Deep Sleep mode to reduce the power consumption. The following code snippet shows the WDT interrupt handler.

static void wdt_interrupt_handler(void)
{
    /* Clear WDT pending interrupt */
    Cy_WDT_ClearInterrupt();


#if (CY_PDUTILS_TIMER_TICKLESS_ENABLE == 0)
 /* Load the timer match register. */
    Cy_WDT_SetMatch((Cy_WDT_GetCount() + gl_TimerCtx.multiplier))
#endif /* (CY_PDUTILS_TIMER_TICKLESS_ENABLE == 0) */

    /* Invoke the timer handler. */
    Cy_PdUtils_SwTimer_InterruptHandler(&(gl_TimerCtx));
}

  1. WDT as a system reset generator for USB PD firmware

In the USB PD firmware, the WDT is configured as a periodic interrupt generator. Therefore, a direct usage of WDT as a system reset generator is not feasible. This is because the WDT interrupts are cleared from the WDT interrupt handler itself and therefore, any lockup in the main firmware loop will not result in uncleared watchdog interrupts which are necessary to trigger a reset.

However, the USB PD code is written in such a way as to protect the firmware from crashes either in the main firmware loop or even in the WDT interrupt handler. Both of these independent actions can be enabled/disabled using two macros defined in the config.h file under the USB PD project files for ModusToolbox™, as shown in the following code snippet:

/* Enable watchdog hardware reset for CPU lock-up recovery */
#define WATCHDOG_HARDWARE_RESET_ENABLE              (1u)

/* Disable device reset on error (watchdog expiry or hard fault). */
#define RESET_ON_ERROR_ENABLE                       (1u)

/*
 * Watchdog reset period in ms. A lower value will increase the power
consumption in the
 * system due to frequent system wakeup in Deep Sleep mode operation.
 */

#define WATCHDOG_RESET_PERIOD_MS                    (750u)

WATCHDOG_HARDWARE_RESET_ENABLE

This macro is used to enable the WDT reset functionality. Enabling this macro with a value ‘1’ will generate a device reset if the WDT interrupt handler is blocked from periodic execution (lockup may happen while servicing a higher-priority interrupt or within a critical section), thereby resulting in pending uncleared WDT interrupts. However, enabling this macro will not protect the system from any crash which occurs in the main firmware loop which does not block the execution of the WDT ISR.

RESET_ON_ERROR_ENABLE

This macro is responsible for protecting the system against crashes in the main body of the firmware. Enabling this macro will frequently clear a global variable gl_main_loop_delay from the main firmware loop. On the other hand, the value of this value is incremented within a watchdog timer callback. If the main firmware loop crashes, this variable cannot be cleared and the incremental value of this variable increases beyond ‘3’. Upon this condition, a manual reset is issued from the watchdog timer callback as shown in the following code snippet:

    /*
   * It is possible that this timer is the only reason for the device to wake
   * from sleep.

   * Hence allow three consecutive timer expiries before resetting the device.
   */
     gl_main_loop_delay++;
     if (gl_main_loop_delay > 3)

     {
        if(gl_instrumentation_cb != NULL)
        {
            gl_instrumentation_cb(0, INST_EVT_WDT_RESET);
        }

        /* Store the reset signature into RAM. */
        gl_runtime_data_addr[WATCHDOG_RESET_OFFSET] = WATCHDOG_RESET_SIG;
        NVIC_SystemReset();
    }

WDT functional flowchart for USB PD firmware.png

Figure 2 WDT functional flowchart for USB PD firmware

Configuration of WDT-based system reset time in USB PD firmware:

As discussed above, the WDT interrupt period is responsible for the time taken to trigger a system reset following a firmware crash. The configuration parameters to adjust the interrupt period are the ‘match value’ and ‘ignore bits’. The ‘Match value’ can be used to configure the interrupt period only when the match value can be incremented in the WDT ISR each time. However, any lockup in the WDT ISR will cause a failure to update the next match value. Therefore, in case of a lockup in the WDT ISR, ignore bits alone will be used to set for course adjustment in the WDT interrupt period by calling the following API in the main function:

Cy_WDT_SetIgnoreBits(IGNORE_BITS);

Here, the IGNORE_BITS argument specifies the number of bits to be considered in the 16-bit WDT count register. A higher number of ignore bits will reduce the WDT interrupt period and thereby reduces the reset time. For example, considering a 40-kHz ILO clock frequency, setting the IGNORE_BITS to ‘2’ will result in a maximum WDT interrupt period equal to 410 milliseconds, and thereby a reset time equal to 1.23 seconds.

Image.png

On the other hand, when the main firmware loop crashes, but the WDT ISR execution still continues, the match value may be used for fine adjustments in the WDT interrupt period by updating the next match value in the WDT ISR. This is done in the firmware to configure the WDT interrupt period to the value of the WATCHDOG_RESET_PERIOD_MS macro specified in the config.h file. The reset time in case of main firmware loop crash is equal to three times the value of this macro.

Example: Steps to configure a 1-second reset time using the WDT in the USB PD firmware:

  • Set the WDT ignore bits to ‘2’ as a part of the initialization code using the Cy_WDT_SetIgnoreBits() API function in the main.c file. This will limit the WDT period to a maximum value corresponding to 16384 ILO clock cycles.
    Infineon_Team_2-1679307274889.png
    Figure 3 Setting WDT ignore bits value

  • Enable both the WATCHDOG_HARDWARE_RESET_ENABLE and RESET_ON_ERROR_ENABLE  macros by setting the value to ‘1’.
  • Set the value of the WATCHDOG_RESET_PERIOD_MS macro in config.h to 5% (WDT period tolerance) less than the maximum WDT interrupt period set using ignore bits (maximum 410 ms for 40-kHz ILO clock). Setting the value as 380 ms will be sufficient.
    Infineon_Team_3-1679307434888.pngFigure 4 Enabling the macros required for WDT-based system reset functionality


Relationship between system power consumption and WDT interrupt period:

It is common to have an increase in the system power consumption with an increase in the operating clock frequency. Considering the USB PD firmware in Deep Sleep operation, the system is woken up regularly at each WDT interrupt to execute the tasks in Active mode and then falls back to Deep Sleep again.

Once the system enters into a PD contract, the WDT is typically the source used to wake up the CPU, unless there is any occurrence of a critical event. Hence reset timing is dependent on the WDT interrupt period
(as discussed above), configuring the WDT to have a shorter reset time will also increase the rate at which the CPU is woken up from Deep Sleep. This will slightly raise the overall power consumption in the system. For a battery-powered system, it is therefore ideal to have a longer WDT interrupt period.

Case 1:

Consider the current drawn by PMG1 devices in Active mode as 10 mA (typical value) and the current drawn in Deep Sleep as 500 µA (using the SID_DS3 specification in PMG1-S1 datasheet). Assuming the time period of Active mode operation as 1 ms (application-dependent), Table 1 shows the average current drawn by the PMG1 device with respect to the WDT interrupt period. The system power consumption is linearly proportionally to the current drawn.

Table 1  Relationship between average system current and WDT interrupt period

Deep sleep current (µA)

Active current (mA)

Active time (ms)

WDT period (ms)

Average current (µA)

500

10

1

50

686.275

500

10

1

100

594.059

500

10

1

150

562.914

500

10

1

200

547.264

500

10

1

250

537.849

500

10

1

300

531.561

500

10

1

350

527.066

500

10

1

400

523.691

500

10

1

450

521.064

500

10

1

500

518.962

500

10

1

550

517.241

500

10

1

600

515.807

500

10

1

650

514.593

500

10

1

700

513.552

500

10

1

750

512.650

500

10

1

800

511.860

500

10

1

850

511.163

500

10

1

900

510.544

500

10

1

950

509.989


Note: The above power data represents the current drawn assuming the Active mode duration to be 1 ms with the Deep Sleep current of 500
µA. However, for the USB PD firmware operation on PMG1 devices, the values are much lower than the arbitrary values assumed for the above calculation.

Infineon_Team_4-1679307544469.png
Figure 5 Graph showing the dependence of current drawn by PMG1 device on the watchdog timer period
 

Case 2:

Example: Power consumption of PMG1 devices for USB PD DRP (dual-role-power) operation with 1-second reset time

The typical value of current consumption by PMG1 devices in Deep Sleep mode is approximately 500 µA with WDT wakeup, CC wakeup, and ADC/CSA/UVOV enabled (Refer to SID_DS3 specification in PMG1-S1 datasheet). The time duration of Active mode operation is application-dependent and comes out to be around 185 µs in the USB PD DRP firmware.

To configure a 1-second reset time, the IGNORE_BITS value is set to ‘2’ to put a cap on the maximum WDT interrupt period equivalent to 214 WDT counts. Considering the ILO clock frequency to be 40 kHz, the WDT interrupt period is calculated as follows:

Image.png

The reset time following a lockup of WDT ISR is three times of the above calculated value (3 x 409.6 = 1.23 seconds).

The reset time in case of a lockup in the main firmware loop is decided by the WATCHDOG_RESET_PERIOD_MS macro defined in the config.h file. This value should be not be greater than the maximum WDT interrupt period of 409.6 ms calculated above. Therefore, it is recommended to use a slightly lower value (say 380 ms) for this macro to account for the inaccuracy in the ILO clock frequency.

The power consumption for PMG1 devices (in terms of average current drawn) for the above configuration in the USB PD firmware is calculated as follows:

Image.png

ILO accuracy of WDT operation:

The Internal Low-frequency Oscillator (ILO) can operate in low-power modes and is used to generate the LFCLK clock. The typical value of the LFCLK frequency is 40 kHz with +/-50% accuracy. As the watchdog timer is directly powered by LFCLK generated by the ILO, any variation in its frequency can critically affects the interrupt period of WDT, which in turn affects the reset time and the execution of certain periodic firmware tasks. Therefore, the USB PD firmware has a built-in calibration feature, wherein during the system start-up, the actual WDT period is compared with that of the Arm® system timer (SysTick) which runs on the IMO (Internal Main Oscillator) clock, which is very accurate, comparatively.

Based on the mismatch in the WDT timing with respect to that of SysTick, the WDT is calibrated by adding appropriate compensation time required by adjusting the match value. The watchdog timing thus achieved lies within +/-5% of the value specified by the firmware.

Note: As the above-mentioned calibration is done by adjusting the WDT match value, it is valid only as long as the WDT ISR is executed periodically. Also, as the manual reset time in case of the main firmware loop crash depends on the periodicity of execution of WDT ISR, this reset time will be accurate within 5% of the value specified by the WATCHDOG_RESET_PERIOD_MS macro multiplied by three.

However, in case of a lockup in the WDT ISR execution, the match value for the WDT cannot be updated anymore and hence the calibration is no more valid. Thereafter, the WDT interrupt fires only as per the period specified by IGNORE_BITS, with the 50% accuracy of the ILO. Hence, the reset time in case of the WDT ISR lockup may have 50% tolerance.

Note: The watchdog timer calibration discussed above is done only at the device start-up phase and hence there is no dynamic calibration included in the firmware. Therefore, any deviation in the ILO clock frequency due to external factors like temperature is not compensated in the current firmware.

Extremum of WDT interrupt period

The maximum and minimum values that can be assigned to the WDT period in the USB PD firmware is dependent on few parameters. Reducing the WDT period will lead to an increase in the system power consumption as illustrated in Table 1 and Figure 3.

A very small period value of less than 5 ms may cause interference with the normal PD stack tasks execution by the CPU. In general, it is recommended to use higher values of WDT period to save power. However, the timer period value which corresponds to the number of ILO clock cycles specified by CY_PDUTILS_TIMER_HW_MAX_TIMEOUT (macro defined in the cy_pdutils_sw_timer.h file) is the upper limit. Any period value greater than this is redundant and does not provide any benefit. This is because exceeding this value will lead to splitting up of this period into multiple smaller intervals by the firmware action. This upper limit of the WDT period comes out to be 1.64 seconds for an ILO clock frequency of 40 kHz.

/* Start the timer if not already running. */
context->start_tick = cur_count;
    count = p_timer_handle[index].count;
    if (count > CY_PDUTILS_TIMER_HW_MAX_TIMEOUT)
    {
        count = CY_PDUTILS_TIMER_HW_MAX_TIMEOUT;
    }
    context->tick_time = (uint16_t)count;
    TIMER_CALL_MAP(Cy_PdUtils_HwTimer_LoadPeriod) (context,(uint16_t) (count + cur_count));     
    TIMER_CALL_MAP(Cy_PdUtils_HwTimer_Start) (context);

0 Likes
296 Views