1 Introduction

Test Name: WDT Start-up Diagnostic.  

 

Purpose of Test: The Watchdog Timer (WDT) is a system function that monitors correct program operation and allows recovery from error situations, such as runaway or deadlocked code. This diagnostic verifies that it is working correctly.  

 

Description: The self-diagnostic routine verifies that the WDT is able to issue a timely system reset and that the WDT counter can be reset at start-up.

This diagnostic is intended to be executed at start-up, before entering the main function, as it involves multiple device resets. The diagnostic supports both the scenario where the WDT is enabled (and so locked) through the fuse bit and when it is not. In the former scenario, the diagnostic execution time will depend on the time-out period chosen for the WDT, while in the latter scenario, the WDT is enabled with the shortest WDT time-out period and disabled upon exiting the diagnostic.

For all devices besides AVR_EB, Timer/Counter A (TCA) is used to verify the timing of the WDT clock source since the TCA clock source is independent. For AVR_EB devices, Timer/Counter E (TCE) is used instead. The timer is set up and teared down as part of running the diagnostic. It is assumed that the timer resource is free at start-up before entering main.

Attention:

This diagnostic clears all Reset flags in the Reset Flag register (RSTFR). Use the DIAG_WDT_GetRSTFRCopy() API to retrieve a copy of the register at start-up to handle unexpected resets in the application.

The misra_project_deviation and misra_specific_deviation pages show an overview of the general project MISRA C:2012 deviations and specific deviations for the WDT Start-up Diagnostic APIs.

API Documentation:  

Watchdog Timer Start-up

Assumptions of Use (AoU):

AoU_01-WDT_STARTUP_TEST: This test assumes that the clock configurations are maintained at their Power-On Reset (POR) default values for the duration of the test.  

Reason: If the diagnostic test is integrated into an application that uses bootloaders sharing the same program Flash and peripheral resources, the bootloader code may configure the clock with custom, non-POR values. This could ultimately result in the failure of the WDT diagnostic test. In such scenarios, the system integrator must ensure that the clock configurations are reinitialized to their POR default values before calling the InitTimer() function.

AoU_02-WDT_STARTUP_TEST: If the diagnostic test is integrated into an application that uses bootloaders sharing the same program Flash and peripheral resources, the persistent variables declared in the diag_wdt_startup.c file must be placed at an absolute address in the data memory. Additionally, the bootloader’s linker settings must be modified to exclude these addresses from the data memory region region accessible to the bootloader.  

Reason: If the data memory address locations assigned to the persistent variables are not protected from access by the bootloader, the repeated resets during the WDT diagnostic test can lead to unintended changes to these variables caused by bootloader execution after each reset. This could ultimately result in the failure of the WDT diagnostic test.

Example:

Device: AVR128DA48

Updates to the diagnostic test:

The variable definitions for the following variables need to be updated to absolute addresses in data memory:

  • testState

  • invTestState

  • testResult

  • invTestResult

  • resetFlagsBackup

  • invResetFlagsBackup

  • timerOverflowCount

An example for the update in declarations is shown below.

Previous declaration: 
static volatile __persistent fsm_state_t testState;

static volatile __persistent fsm_state_t  invTestState;

static volatile __persistent diag_result_t testResult;

static volatile __persistent diag_result_t invTestResult;

static volatile __persistent uint8_t  resetFlagsBackup;

static volatile __persistent uint8_t invResetFlagsBackup;

static volatile __persistent uint32_t timerOverflowCount;
Suggested declaration: To shrink this data memory range to as small as physically possible, these absolute addresses must be consecutive: 
static volatile __persistent fsm_state_t __at(0x804000) testState;

static volatile __persistent fsm_state_t __at(0x804001) invTestState;

static volatile __persistent diag_result_t __at(0x804002) testResult;

static volatile __persistent diag_result_t __at(0x804003) invTestResult;

static volatile __persistent uint8_t __at(0x804004) resetFlagsBackup;

static volatile __persistent uint8_t __at(0x804005) invResetFlagsBackup;

static volatile __persistent uint32_t __at(0x804006) timerOverflowCount;
where, 0x804000:0x804006 are addresses in data memory.
An example for an API which sets the clock configuration is shown below: 
static void CLOCK_SetDefaultConigurations(void)
{
    ccp_write_io((void*) &(CLKCTRL.MCLKCTRLB), 0U);
    ccp_write_io((void*) &(CLKCTRL.OSCHFCTRLA), 12U);
    ccp_write_io((void*) &(CLKCTRL.PLLCTRLA), 1U);
}
Usage: 
void DIAG_WDT_Startup(void)
{
    // Diagnostic code
    :
    :
    :
    CLOCK_SetDefaultConigurations();
    
    // Set up the timer for time measurement and delays
    InitTimer();
    :
    :
    // Remaining diagnostic code
    :
    :
}

The CLOCK_SetDefaultConfigurations function may need modifications based on the specific device being used. Refer to the Data Sheet to understand the steps required for clock configurations.

Updates to bootloader linker settings: The following linker settings need to be added to the bootloader’s linker settings to exclude the data memory range where the diagnostic test variables for the WDT test are stored from the bootloader’s accessible data memory range. 
-Tdata=0x80400A -Wl,--defsym,__DATA_REGION_LENGTH__=0x3FF6,--defsym,__DATA_REGION_ORIGIN__=0x80400A
where,

  1. -Tdata=0x80400A: This option specifies the starting address of the data section in memory. By setting -Tdata=0x80400A, the linker places the data section starting at memory address 0x80400A.

  2. -Wl,--defsym,__DATA_REGION_LENGTH__=0x3FF6:

    • The -Wl setting passes options directly to the linker. In this case, –defsym is used to define a symbol with a specific value.

    • __DATA_REGION_LENGTH__=0x3FF6 defines a symbol __DATA_REGION_LENGTH__ with the value 0x3FF6. This symbol represents the length (or size) of the data region in memory.

    • The value 0x3FF6 indicates that the data region is 0x3FF6 bytes long. This value is calculated by subtracting 10 bytes from the total data memory. In this case, data memory = 0x4000 bytes, therefore, 4000 - 10 = 3FF6 bytes.

  3. --defsym,__DATA_REGION_ORIGIN__=0x80400A: Similar to the previous setting, this defines __DATA_REGION_ORIGIN__ symbol with the value 0x80400A. This symbol represents the starting address of the data region, which matches the address specified by -Tdata.