Boron Hardware Watchdog vs i2c

Firmware
1

I understand that the hardware watchdog in the Boron is based on the nRF52840 MCU . Where would I find details about how the watchdog is implemented in hardware? It seems to be interacting with the Boron i2c interface.

When I implement the hardware watchdog with

Watchdog.init(WatchdogConfiguration()
  .capabilities(WatchdogCap::NOTIFY) // leaves out SLEEP_RUNNING, so watchdog will stop while sleeping
  .timeout(20min));     // will trigger after 20 min  
          //I never call Watchdog.refresh since I just don't want Boron to run > 20 min
Watchdog.start();

It doesn't cause any problems on the 1st run through my code but it interferes with my i2c reads after a System.reset(RESET_NO_WAIT); I'm wondering if it uses the i2c interface somehow. Running OS 5.5.0

2

Looking at the specs for the Boron's nRF52840_OPS_v0.5 I see that there are several different types of reset.

Pages from nRF52840_OPS_v0.5_clip
Pages from nRF52840_OPS_v0.5_clip2747×1115 229 KB

When running with the hardware watchdog active I see different behavior of my code for i2c depending on if I reset:

  • with the reset button (the i2c code to read 2 BME280s following works fine)
    vs
  • with System.reset(RESET_NO_WAIT); (the same i2c code does not read the 1st of 2 BME280s)

Somebody know how the reset button and the System.reset relate to the reset types listed in the nRF52840 documentation?
And further how I might make the System.reset work more like the button reset?
thanks, john

3

The watchdog should have no interaction with I2C at all. The source is here. It's just a wrapper around the nRF52 SDK WDT functions.

System.reset() does some housekeeping functions and eventually does something platform specific. On Gen 3, it calls the nRF52 SDK function NVIC_SystemReset here. At the lowest layer the SDK uses the AIRCR register to soft reset the MCU, which is different than the hardware reset pin, but post-reset the behavior should be the same.

There's probably something else going on that's preventing your sensor from working properly - you're so deep into hardware specific stuff that it's highly unlikely that the real cause is the difference between the hardware and software reset. It's probably timing, or electrical, and it just happens to show up as a difference in reset behavior.

4

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.