Boron automatically enters DFU mode (blinking yellow)

Firmware Device OS
1

Hello,

I have 10+ Boron 2G/3G deployed on the field and 2 with me on my bench. All are running device OS 1.4.4. Nothing is connected to the RST & MD pins.
It sporadically already happened before, but after the cloud service outage, it seems, that all are stuck in DFU mode, fast blinking yellow (at least the two devices on my bench are stuck in DFU mode). Now if I plug them into the computer with an USB cable, Windows 10 recognizes them as “Boron DFU Mode”.
Previously I assumed that this DFU mode was happening because of physical handling of the devices, cable plugging in, etc.

In my firmware I have an application watchdog, which is not functional in DFU mode of course, but also have the nRF hardware watchdog enabled, but now it does not fire either (previously it was working properly):

#define HWWDTIMEOUTMS 6 * 60 * 1000  //hardware WDT: minute * 60 * 1000 = ms,
hwwd.initialize( HWWDTIMEOUTMS );
hwwd.pet(); //kick hardware watchdog

void HWWatchDog::initialize(uint32_t timeInMilliseconds) {
    *(uint32_t *) WDT_RREN_REG = 0x00000001;    //default reset value, not necessary, just for safety
    *(uint32_t *) WDT_CRV_REG = (uint32_t) (timeInMilliseconds * 32.768);   //set counter register reset value
    *(uint32_t *) WDT_REG = 0x00000001; //start WDT
}
void HWWatchDog::pet() {
    *(uint32_t *) WDT_RR0_REG = WDT_RELOAD;
}

My questions:
1.) Why and how can a device enter into DFU mode automatically (without USB connection or pushing any buttons)?
2.) Is it an intended behavior, or a bug in the device OS?
3.) Why isn’t there any timeout for DFU mode (e.g. 1 hour), to recover stuck devices?
4.) Does DFU mode intentionally and automatically disables the nRF built-in hardware watchdog?
5.) Is there any way to recover my remote devices without visiting them?

I learned the lesson on the hard way: an external hardware watchdog is indispensable…
I didn’t yet try to reset the devices on my bench, (with reset button or EN pin), but that would probably exit DFU mode, because I’d like to test the remote reset solution on them, if there’s any.

Any ideas are appreciated!

2

A faulty MODE switch could cause that and also a System.dfu() call in code.

2.) Depends on the actual cause

3.) Good question, but depending on the cause that might still not solve the issue

4.) How would the HWDT be engaged after a reset before that code has been executed?

5.) Again, depending on actual cause - maybe, maybe not.

However, fast blinking yellow does not look like standard DFU Mode.
Got a video?

3

Hi ScruffR,

Thank you for your quick reply.
1.) I don’t call System.dfu(), and it’s hard to believe, that all of my Borons has faulty mode switches, which goes wrong at about the same time. But I’ll investigate my PCB carefully to see if other parts may have some parasitic effects on those pins. However, I think it’s unlikely.
2.) Is there any known event or logic which puts the system into DFU mode without the intention of the user (intentional beeing e.g. System.dfu() or button sequences, or USB commands)
4.) Do you mean that DFU mode always starts after a reset? So there is no way for the system to go from run -> DFU, but only run -> reset -> DFU. That can explain why the HWDT is off.
5.) What can I try?

Here is a short video about the blinking. In the clip, there is a short glitch, but in reality, the blinking has a regular, even pattern: https://drive.google.com/drive/folders/13nH-GsjG4TqXYO9gQmLM3v_xtexM0fLf?usp=sharing
EDIT: If the video doesn’t play well, it is pretty much identical to the DFU Mode example in the docs: https://docs.particle.io/tutorials/device-os/led/boron/#dfu-mode-device-firmware-upgrade-
EDIT 2: I changed the topic title from “fast blinking yellow” to “blinking yellow”, because “fast blinking” shows factory reset, which is not my case.

Is there more than one DFU mode?

4

Nope, not meaning that, but we also don't know how the device ended up in DFU Mode in the first place, so the possibility needs to be considered.

Not really, but the limited number of distinguishable colours on the system LED may lead to some confusion and sometime there may be erroneous colour "codes" that don't indicate any known state.

But after clarifying the above and your error description it might be best to file a support ticket at support.particle.io (referencing this thread too).