Electron 2G breathing cyan but apparently not executing code

I’ve done a few projects with particle boards, and I’m pretty familiar with the devices. My end deployment will likely be outside of wifi range, so i wanted to try it out on an electron. However I haven’t had much luck even with a really simple “hello world” blinky LED program.

I have an Electron 2G, and I’m trying an OTA update. It flashes purple, goes through the network reconnect sequence and then breathes cyan. I simplified it to the following code:

int led = D7; // built-in LED on D7

void setup() {
    pinMode(led, OUTPUT);

}

void loop() {
     // To blink the LED, first we'll turn it on...
    digitalWrite(led, HIGH);

    // We'll leave it on for 1 second...
    delay(1000);

    // Then we'll turn it off...
    digitalWrite(led, LOW);
    
     // Wait 1 second...
    delay(1000); 
}

Aside from failing miserably at formatting the code in the editor, what am I missing? I would expect that the built-in LED on D7 would be blinking at 0.5 Hz, but all I get is the main RGB LED breathing cyan. This should work right?

Are you using the Web IDE to perform the OTA flash?

Yes, why?

Is the Blue D7 led working before?

Try putting your Electron into Safe Mode and then flash again.
This should work.

I assume that the blue LED works (it faintly lights up when I put it in safe mode).

Safe mode was my first troubleshooting, but just for the sake of completion I did it again. From safe mode, it flashed purple, updated, reconnected and still nothing.

Did I get a dud? This should be working and blinking at 0.5Hz, right? The dashboard event log says that it came online, but what else should I try to figure out what’s not working properly?

Have you got CLI installed?
Can you perform a wired upgrade via

particle update

and then try to flash that code via usb?

When I tried to update the firmware, I got an error 1 (put it in DFU mode, blinking yellow, etc...error 1), and 5 minutes of searching didn't turn up anything useful on what that error code meant in this context.

Regardless, I used the CLI to flash the firmware over USB, and still no blinking blue LED on D7.

Using "particle list" it shows up:

smiling-ranger [530031000c51343334xxxxxx] (Electron) is online
Variables:
analogvalue (int32)
Functions:
int led(String args)

However neither the function nor the variable are part of the code that I've uploaded. Those look like the code from the out of box example. Is it not actually updating the firmware? Can I force it to flush the firmware somehow?

If you post the full output of CLI when performing the update and flashing your code, we might be able to do something better than guessing with that.

Sure thing. I'm not sure what is useful and what is not, hence the error code comment. Here's the full copy of the interface...

C:\Users\bblack>particle update
!!! There was an error trying execute DFU utilities.

!!! For help with installing DFU Utilities, please see:
https://docs.particle.io/guide/tools-and-features/cli/#advanced-install

!!! You may also find our community forums helpful:
https://community.particle.io/

Error code: 1

C:\Users\bblack>particle update
!!! There was an error trying execute DFU utilities.

!!! For help with installing DFU Utilities, please see:
https://docs.particle.io/guide/tools-and-features/cli/#advanced-install

!!! You may also find our community forums helpful:
https://community.particle.io/

Error code: 1

C:\Users\bblack>particle flash --serial firmware.bin
! PROTIP: Hold the SETUP button on your device until it blinks blue!
? Press ENTER when your device is blinking BLUE
sending file: firmware.bin

Flash success!

C:\Users\bblack>

It seems you haven’t got dfu_util installed or set up properly in your path.

1 Like

Alright, it has taken me a few evenings of tinkering time to get all of the bits and pieces verified and / or installed, but I think my toolchain is all set up now. When I run the update command, now it tells me that I don't have any connected devices, but that's obviously not true (I'm watching the electron blink yellow).

C:\Users\bblack>particle list
aardvark_gerbil [xx] (Photon) is offline
puppy_boomer [xx] (Photon) is offline
station_lawyer [xx] (Photon) is offline
smiling-ranger [xx] (Electron) is online
Variables:
analogvalue (int32)
Functions:
int led(String args)

C:\Users\bblack>particle update

!!! I was unable to detect any devices in DFU mode...

Your device will blink yellow when in DFU mode.
If your device is not blinking yellow, please:

  1. Press and hold both the RESET/RST and MODE/SETUP buttons simultaneously.
  1. Release only the RESET/RST button while continuing to hold the MODE/SETUP button.
  1. Release the MODE/SETUP button once the device begins to blink yellow.

C:\Users\bblack>

Now that I appear to have the dfu utility installed and working properly but still can't seem to connect to or update the application firmware running on the device, what's next? It clearly seems to be running an old firmware that I installed from the shipping example. Is there a way to hard-reset it?

For sake of complete information, I'm using Win10 on a SurfaceBook.

You can see your device in device manager?
What driver have you got for it?
Can you try a different port/cable?

The DFU driver wasn't installed properly. Man, that's a lot of hoops to jump through! Anyway, that's fixed, everything shows up as expected in the Device Manager (driver version 5.2), updated successfully, re-flashed with blinky firmware, and nothing...

C:\Users\bblack>dfu-util -l
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Found DFU: [2b04:d00a] ver=0200, devnum=11, cfg=1, intf=0, alt=1, name="@DCT Flash /0x00000000/01016Kg", serial="00000000010C"
Found DFU: [2b04:d00a] ver=0200, devnum=11, cfg=1, intf=0, alt=0, name="@Internal Flash /0x08000000/03
016Ka,01016Kg,01064Kg,07*128Kg", serial="00000000010C"

C:\Users\bblack>particle update

Your device is ready for a system update.
This process should take about 30 seconds. Here goes!

! System firmware update successfully completed!

Your device should now restart automatically.
You may need to re-flash your application to the device.

C:\Users\bblack>particle flash --serial firmware.bin
! PROTIP: Hold the SETUP button on your device until it blinks blue!
? Press ENTER when your device is blinking BLUE
sending file: firmware.bin

Flash success!

I've tried different USB ports and different cables. However, since it's successfully flashing and updating the firmware, I would would be surprised if it were a port or cable problem, right?

What's next?

I do prefer particle flash --usb firmware.bin since it provides better feedback about the flash success or fail reason.

Sounds good. I’ll try the --usb option when I get home this evening.

Where can I find more documentation about the flash options and the advanced CLI in general?

I got the --serial command from the “how to” on electron flashing via USB, but the options aren’t explicitly listed in the CLI reference documentation. For instance why does the --serial option need for it to be flashing blue listening mode when the --usb option requires that it be in yellow-flashing DFU mode?

Because Listening/Setup mode enumerates the device as USB HID CDC device while DFU mode enumetates the device as DFU device and particle flash --usb uses dfu_util to talk to such devices.

Alright, what does this tell me?

C:\Users\bblack>particle flash --usb firmware.bin
running dfu-util -l
Found DFU device 2b04:d00a
checking file firmware.bin
spawning dfu-util -d 2b04:d00a -a 0 -i 0 -s 0x08080000:leave -D firmware.bin
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Opening DFU capable USB device...
ID 2b04:d00a
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08080000, size = 3144
Download [=========================] 100% 3144 bytes
Download done.
File downloaded successfully
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!

Flash success!

This flash worked.

I changed the code to flash faster, recompiled and flashed over the air...nothing. I flashed using serial, nothing changed. When I flashed using the --usb option, it finally worked.

What is the implication of this? What isn't working properly? Does that mean I have to flash using the DFU utility and this way only from now on? It's a 2G module, is that significant?

That seems like unexpected behavior and slightly painful. It's definitely a bug either way. Is there a way to find out if it's reproducible?

What's the implication of what?

Usually OTA and --serial should work (and do for me on 3G and 2G) just the same, but in these modes your user code can still interfere with the update, especially if you are using interrupts, SYSTEM_THREAD(ENABLED) or other code that might impact the timing and/or cellular module. Putting your device into Safe Mode before flashing might help against this most the time.
DFU Mode on the other hand will put the device into a state where your code has no way to interfere at all.

Sorry, let me be more explicit.

I flashed the same code from earlier in the post. There are obviously no system interrupts or asynchronous threads that are running in my code that might disrupt any other processes. The USB interface works but the serial and OTA versions don’t.

Those are all system features, and I’m assuming that updates only via USB is not expected behavior. It likely has to do with a combination of Windows 10 and the serial drivers. Based on the CLI logs that I posted, I hoped that there might be something that a more experienced eye would be able to piece together about why the USB interface works but neither of the other two options do.

Any thoughts, and any way to submit this as a bug to the development team?