xWRL6432 MMWAVE-L-SDK  05.05.00.00
Watchdog reset mode

Introduction

This example uses the WDT module in reset mode to trigger SOC warm reset. Servicing the WDT for few iterations before triggering the warm reset. It will reset the device once it reaches the expiry time set by user.
Make sure to confirm the following configuration in syscfg.
WDT Reset Mode: trigger warm reset


In this example we are trying to show two different flows:

  • Reload Image from Flash
  • Reloading Application without reloading image from Flash

Supported Combinations

Parameter Value
CPU + OS m4fss0-0 freertos
Toolchain ti-arm-clang
Boards xWRL6432-evm
Example folder examples/drivers/watchdog/watchdog_reset/

Using SDK with SysConfig

A GUI tool SysConfig is used to configure different modules and peripherals of the example. Using this tool, users can select and customize different modules and peripherals. The SysConfig tool will generate the code for initializing and configuring these modules. This configuration is saved to a file called example.syscfg for every example. To know more about how to use SDK with SysConfig, Visit this page

Using SDK with SysConfig

Flow chart

The user can perform the following sequence if they want to reload complete image from flash during a watchdog reset. After exiting watchdog reset RBL is made to reload from flash by issuing a controlled warm reset with boot vector set to 0. Also when frontend is being used by the application, we have to ensure that frontend PD is ON to enable the RBL to load the frontend firmware.


If the user does not want to reload image from flash and when frontend is not being used we can maintain a backup of the data section so as to restore after watchdog reset. If the user reloads an image from Flash, we do not need to maintain a backup of the data section. The user can update the linker to have the data section only at the run address.


Steps to Enable Reload Image from Flash/Reloading Application without reloading image from flash

  • To enable reload image from flash the user can remove or comment out the following code in main.c
    /*if user does not want to reload image from flash and when frontend is not being used following will be
    required for resuming after a watchdog reset. This is to get a fresh copy of data section. If user
    is reloading image from flash then the following is not necessary and user can have data section only at
    run address by updating the linker.
    */
    /* Copying the data section from load memory to run memory location.*/
    uint32_t data_size = ((uintptr_t)&__LOAD_DATA_END - (uintptr_t)&__LOAD_DATA_START);
    memcpy((void*)&__RUN_DATA_START,(void*)&__LOAD_DATA_START,data_size);

    and replace the contents of the linker file with the following:
    /* make sure below retain is there in your linker command file, it keeps the vector table in the final binary */
    --retain="*(.vectors)"
    /* This is the stack that is used by code running within main()
    * In case of NORTOS,
    * - This means all the code outside of ISR uses this stack
    * In case of FreeRTOS
    * - This means all the code until vTaskStartScheduler() is called in main()
    * uses this stack.
    * - After vTaskStartScheduler() each task created in FreeRTOS has its own stack
    */
    --stack_size=8192
    /* This is the heap size for malloc() API in NORTOS and FreeRTOS
    * This is also the heap used by pvPortMalloc in FreeRTOS
    */
    --heap_size=8192
    SECTIONS
    {
    /* This has the M4F entry point and vector table, this MUST be at 0x0 */
    .vectors:{} palign(8) > M4F_VECS
    .bss: {} palign(8) > M4F_RAM12 /* This is where uninitialized globals go */
    RUN_START(__BSS_START)
    RUN_END(__BSS_END)
    .text: {} align(8) >> M4F_RAM12 | M4F_RAM3 /* This is where code resides */
    .data: {} align(8) >> M4F_RAM12 | M4F_RAM3 /* This is where initialized globals and static go */
    .rodata: {} align(8) >> M4F_RAM12 | M4F_RAM3 /* This is where const's go */
    .sysmem: {} palign(8) > M4F_RBL /* This is where the malloc heap goes */
    .stack: {} palign(8) > M4F_RBL /* This is where the main() stack goes */
    .l3: {} palign(8) > HWASS_SHM_MEM /* This is where L3 data goes */
    }
    MEMORY
    {
    M4F_VECS : ORIGIN = 0x00400000 , LENGTH = 0x00000200
    M4F_RAM12 : ORIGIN = 0x00400200 , LENGTH = (0x00058000 - 0x200) /* 32KB of RAM2 is being used by RBL */
    M4F_RBL : ORIGIN = 0x00458000 , LENGTH = 0x8000 /* 32KB of RAM2 is being used by RBL */
    M4F_RAM3 : ORIGIN = 0x00460000 , LENGTH = 0x00020000
    HWASS_SHM_MEM : ORIGIN = 0x60000000, LENGTH = 0x00080000 /* 256KB in APPSS PD, 96KB in FECSS PD and 160KB in HWA PD */
    }

  • To reload application without reloading image from flash the user can remove or comment out the following code in main.c
    SOC_RstReason rstrsn;
    rstrsn = SOC_getRstReason();
    if (rstrsn == SOC_RESET_REASON_WARM)
    {
    /* If user wants to reload complete image from flash during a watchdog reset following
    sequence can be followed. After exiting watchdog reset RBL is made to reload from flash
    by issuing a controlled warm reset with boot vector set to 0. Also when frontend is being
    used by the application, we have to ensure that frontend PD is ON to enable RBL load
    frontend firmware.
    */
    handleWdtRst();
    }
    and replace the contents of the linker file with the following:
    /* make sure below retain is there in your linker command file, it keeps the vector table in the final binary */
    --retain="*(.vectors)"
    /* This is the stack that is used by code running within main()
    * In case of NORTOS,
    * - This means all the code outside of ISR uses this stack
    * In case of FreeRTOS
    * - This means all the code until vTaskStartScheduler() is called in main()
    * uses this stack.
    * - After vTaskStartScheduler() each task created in FreeRTOS has its own stack
    */
    --stack_size=8192
    /* This is the heap size for malloc() API in NORTOS and FreeRTOS
    * This is also the heap used by pvPortMalloc in FreeRTOS
    */
    --heap_size=8192
    SECTIONS
    {
    /* This has the M4F entry point and vector table, this MUST be at 0x0 */
    .vectors:{} palign(8) > M4F_VECS
    .bss: {} palign(8) > M4F_RAM12 /* This is where uninitialized globals go */
    RUN_START(__BSS_START)
    RUN_END(__BSS_END)
    /*
    * Maintaining a backup of data section so as to restore after watchdog reset
    * As program executes data section will be updated. During watchdog/warm reset,
    * as RBL does not reload from flash we copy the data section from backed up memory
    * location.
    */
    GROUP
    {
    .data: {} palign(8) /* This is where initialized globals and static go */
    LOAD_START(__LOAD_DATA_START)
    LOAD_END(__LOAD_DATA_END)
    RUN_START(__RUN_DATA_START)
    } load > M4F_DATALOAD, run > M4F_DATARUN
    .text: {} align(8) >> M4F_RAM12 | M4F_RAM3 /* This is where code resides */
    .rodata: {} align(8) >> M4F_RAM12 | M4F_RAM3 /* This is where const's go */
    .sysmem: {} palign(8) > M4F_RBL /* This is where the malloc heap goes */
    .stack: {} palign(8) > M4F_RBL /* This is where the main() stack goes */
    .l3: {} palign(8) > HWASS_SHM_MEM /* This is where L3 data goes */
    }
    MEMORY
    {
    M4F_VECS : ORIGIN = 0x00400000 , LENGTH = 0x00000200
    M4F_RAM12 : ORIGIN = 0x00400200 , LENGTH = (0x00058000 - 0x200) /* 32KB of RAM2 is being used by RBL */
    M4F_RBL : ORIGIN = 0x00458000 , LENGTH = 0x8000 /* 32KB of RAM2 is being used by RBL */
    M4F_RAM3 : ORIGIN = 0x00460000 , LENGTH = 0x0001F000
    /* when using multi-core application's i.e more than one m4F active, make sure
    * this memory does not overlap with other m4F's
    */
    M4F_DATALOAD : ORIGIN = 0x0047F000 , LENGTH = 0x800 /*Memory space where data section is loaded*/
    M4F_DATARUN : ORIGIN = 0x0047F800 , LENGTH = 0x800 /*Memory space of data section during runtime*/
    HWASS_SHM_MEM : ORIGIN = 0x60000000, LENGTH = 0x00068000 /* 256KB in APPSS PD and 160KB in HWA PD */
    }

Steps to Run the Example

See Also

WATCHDOG

Sample Output

Shown below is a sample output when the application is run, Please note that application prints in both CCS and UART console.
CCS Console:

[MAIN_Cortex_R5_0_0] Watchdog reset Mode Test Started ...
Servicing WDT for few iterations
Watchdog triggers warm reset in 3000 (ms)
All tests have passed!!
Prints will be stopped after reset
Prints will be stopped after reset
Prints will be stopped after reset
'' ''
'' ''
'' ''
Prints will be stopped after reset

UART Console:

Watchdog reset Mode Test Started ...
Servicing WDT for few iterations
Watchdog triggers warm reset in 3000 (ms)
All tests have passed!!
Prints will be stopped after reset
Prints will be stopped after reset
Prints will be stopped after reset
'' ''
'' ''
'' ''
Prints will be stopped after reset
Note
Console prints will be stopped once WDT triggers warm reset.