Particle doesn't enter DFU-mode when in while loop

Firmware Device OS
1

I am teaching an IoT class with the Particle Argons. My students have noticed a behavior that if they end up in a continuous while-loop

while (buttonState == low) {
buttonState = digitalRead(buttonPin);
}

if they try to flash new code to their particle (using Particle Workbench) then the device fails to enter DFU-mode.

I am assuming that the execution of the loop is somehow interfering with the Argon getting the signal over the USB-port to enter DFU-mode.

Two questions:

  1. Is this (or something like it) what is actually happening?
  2. How do I best explain to the students the issue so they know how to avoid it?

Thank you
Brian

2

Yes, that is expected because of the way USB requests are handled when threading is off.

My first recommendation is to add

SYSTEM_THREAD(ENABLED);

at the top of the file, not in a function. This decouples system actions from the user firmware (mostly) and is what I’d recommend.

Another way is to not write any code that blocks returning from loop(). This would typically involve finite state machines, which your students may not be up to yet.

The final way is that whenever you have a blocking loop, either call Particle.process() in the loop, or delay(1);.

But I still recommend the first option.

3

Rick - thank you. I assumed a small delay in the loop would help, but I have been trying to train my students to not use delay() in their code as they tend to like to add delays an then don’t understand why an input isn’t registering. We’ll go the SYSTEM_THREAD(ENABLED) route.

Appreciate the help.
Brian

4

On these devices potentially long blocking loops is not any better than using delay() :wink: