2 Replies Latest reply on Jun 15, 2020 5:12 AM by NiMc_1688136

    CYW43907 Debug Watchdog Timeout

    NiMc_1688136

      Is there a way to debug why a watchdog timeout triggered with the CYW43907 in WICED?

       

      I know some MCU's have a ISR for watchdog or some STM32 implementations use a HW timer slightly shorter than the WDT period for debugging. Neither appears to be an option for the CYW43907.

       

      I am finding a low occurrence of Watchdog timeouts while testing low power. It is not feasible to run with an attached debugger due to: low rate of occurrence, number of devices under test, and low power behavior changes with debug code/debugger.

       

      Right now there are 0 clues. If i could somehow get register information (like exception handler dumps) or even the last executed FreeRTOS task would be great.

        • 1. Re: CYW43907 Debug Watchdog Timeout
          RaktimR_11

          Are you using the system monitor thread to detect the watchdog timeout or read_bits from the status register as defined in 43xxx_Wi-Fi/WICED/platform/MCU/BCM4390x/platform_appscr4.h?

          • 2. Re: CYW43907 Debug Watchdog Timeout
            NiMc_1688136

            RaktimR_11

            I do use the system monitor thread but the watchdog still triggers. Since the system monitor is in a thread, this leaves two possible areas of the watchdog:

            1. WWD thread is locking up - i think off the top of my head that it is the same level priority as the system monitor thread by default in WICED.
            2. This is with FreeRTOS + low power enabled. I have found if something blocks sleep from executing, the FreeRTOS scheduler basically stops executing and the idle task constantly tries to enter sleep mode without advancing the tick counter, so effectively the system monitor thread never executes, which is responsible for kicking the watchdog.
              1. I have to block entering sleep based on a GPIO condition and i found this check in one of the entering sleep callbacks would actually create this condition so i found and implemented the FreeRTOS macro, configPRE_SUPPRESS_TICKS_AND_SLEEP_PROCESSING, which cleared up most Watchdogs relating to this.