Particle Workbench programming Boron

Firmware
1

Hello, I am trying for the first time using Particle Workbench to program a Boron. Everything seems to work, except getting it to run (see below the fix). Sorry if this is a repeat question, I did search for an answer.

After creating a new project (led blink + serial hello world), getting the device to DFU mode, compiling and uploading all seem to work, but then nothing happens.

Eventually, I found that after uploading via USB, the device runs the program but only after manually doing particle usb stop-listening. Is that the way things are supposed to work? Is there some way to automate this?

1 Like
2

Yes, but you only have to do that once. If you had set up the device using the Particle mobile app the flag would have been cleared automatically, but if you set up the device manually you need to do that step once.

1 Like
3

That may well be the case for you, but I just uploaded the program again and it it stuck at blinking blue and presumably will remain that way until I again do the usb stop-listening. Perhaps there is some way to make this operation sticky?

One thing I did not try was to unclaim the Boron. Instead, I put Cellular.off() in the setup, because I plan to go back to cellular after some I2C development/debugging locally. I’ve verified that removing Cellular.off() and reprogramming puts the device back into contact with the cloud, though curiously it seems I have to do this more than once for it to take effect.

4

Sorry, in DFU mode (blinking yellow) you need to do:

particle usb setup-done

instead of stop-listening.

1 Like
5

Thanks for the suggestion (usb setup-done). Here’s what I encountered

  1. Did not work in DFU mode (message said try when not in DFU mode).
  2. Did work otherwise, effect seems permanent.
  3. Very strange behavior now. Can’t get into DFU mode (by buttons or command) beyond a second or two. Goes from flashing yellow to flashing green too quickly. Device can start, then blinks green (looking for network), then briefly flash white, then again green. Repeats a few times. Eventually got to white heartbeat and program ran, but then spontaneously jumped back to blinking green. In some cases, blink green -> blink cyan -> heartbeat white. It’s like, even though I wrote code which puts Cellular.off(), the supervisor needs to get cellular anyway or at least try to get cellular for some period?
  4. Only way I found to program is do “particle usb start-listening”, which puts it in a mode where I can do a new flash. Buttons didn’t get to this state, unlike documentation advised.

My question to you is this: Can I undo the “particle usb setup-done” change and get back to where things were previously, where at least the app ran predictably?

Update after an hour. The unpredictability seems to be solved by always flashing both OS and app. Things are now stable. Also, I understand a bit more about the connectivity when the Boron starts - I assume so that the event can be seen on the console.

6

Further update. I find that “particle usb start-listening” sometimes doesn’t take (blinking blue reverts to blinking green, etc). Usually trying the start-listening several times gets the Boron into the proper state for flashing again.

7

Programming by USB on the Boron continues to be challenging - the device won’t stay in DFU mode long enough. After many trials and errs, I’ve found that first conditioning the Boron with these two cli commands may work:

particle usb stop-listening
particle usb start-listening

That (at least in some tests) puts the Boron into the flashing blue mode. Thereafter, it can be put into DFU mode and programmed. The behavior of the Boron reminds me of how a watchdog works, difficult to kill without some extra measure.

8

Hello, I have the same problem.
I compile and flash in Local and don’t have any error.
But when I watch the serial monitor, absolutely nothing.

this is my code :

SYSTEM_MODE(MANUAL);

void setup(void) {
    Serial.begin(9600);
}

void loop(void) {
    Serial.println("oui");
}

any ideas ?

9

You can check the binary whether it is actually targeted at the correct platform.

particle binary inspect <yourFirmware.bin>

You may also want to double check whether your device has already got the correct device OS version installed for your application, since your code uses MANUAL mode the device cannot automatically upgrade the device OS if needed

particle serial inspect
10

I have this with binary inspect

CRC is ok (93e0a6e8)
 Compiled for boron
 This is an application module number 1 at version 6
 It depends on a system module number 1 at version 1512

and this with serial inspect

    Bootloader module #0 - version 502, main location, 49152 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
    System module #1 - version 1102
  System module #1 - version 1512, main location, 671744 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
    Bootloader module #0 - version 501
    Radio stack module #0 - version 202
  User module #1 - version 6, main location, 131072 bytes max size
    UUID: E2F6D44C9DA3B539B5B0531F188E1EDFAECB998CAEF9C0C09BA90C6AF958996B
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
    System module #1 - version 1512
    Radio stack module #0 - version 202, main location, 192512 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS

and my device OS is already up-to-date, that’s why I don’t understand why Serial command don’t work

11

What host OS are you running?
What application do you use as serial terminal?
Have you tried particle serial monitor --follow?
What does that report?

BTW, you may want to add a delay in loop() not to overwhelm your terminal program.

12

I finally understand that without :

particle flash --usb tinker

ont time, the output of the console won’t be on my serial monitor.
That was my problem :slight_smile:

13

My case turned out to have another cause. I was programming the Boron through a USB hub that shared with multiple devices (SEGGER, FTDI serial, a Xenon). The reason it took so long to diagnose is that I could not see in the documentation the meaning of the led behavior - green for a while, then white flash, then green again, repeating. This behavior means that the Boron is underpowered, because the UBlox chip needs a burst of current to search/communicate on cellular. I learned this in another forum thread. After learning this, I was able to fix the problem immediately.

14

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