Setup 20 BSOM's in a product without USB og reset/mode buttons

For running field test on the first units on a new product, I looking for a way to setup 20 units of B5-SOM based products at a time for a product setup in Console.

The challenge is that SOM’s and the product they are in, do not have USB or reset/mode buttons. So I am also looking towards a production setup without the App.

Scanning the QR code result in a serial number, adding this in console to the product claims the device and automatically adds the SIM as well (could be done with CLI I believe). If the product got online docs indicate it would OTA the released firmware.

However on the device the internal SIM still needs to be activated with the App or are there other options?

Hey @thrmttnw → have you seen our JTAG instructions? Using SWD/JTAG | Reference Documentation | Particle

For provisioning, you really don’t need to interact with the device apart from what you’ve done. I’m working on a nice doc of manufacturing best practices, but in the meantime the flow is:

Mfg → follow the JTAG instructions above, grab Serial No / ICCID by scanning. Best to flash two apps this way:
a) Mfg test application that exercises key components of your board and sets the setup flag done in this firmware
b) Your production application proper

Provisioning →
a) hit our API w/ Serial No for Device ID
b) hit our API to import & activate SIM
c) hit our API to import and claim your devices (optionally also naming them after the Serial Number - this can be a useful convention), adding them to any relevant device groups
^ you can accomplish all of the above with a batch script in the scripting language of your choice

@marekparticle Thanks, ahh so the setup flag does that. Thank you for the quick write-up.

That link is similar to what I expected. Except it starts out stating that SWD mode needs to be enabled by putting the device in PSU [Edit: DFU] mode with the reset and mode buttons (we don’t have)?

I have search a lot on how to do it, but can only find references to the buttons, and CLI or DFU-Util via USB serial (we also don’t have).

What is PSU-Mode?
If you mean DFU-Mode there is a command from firmware System.dfu()

BTW, even if you don’t have the SETUP/MODE and RESET buttons on your PCB you should still have respective pads on it to prevent problems like this in manufacturing :wink:

1 Like

Yes DFU mode as in the link, thanks. I will correct it above. Reset is available on a pad on our PCB not the mode button. For module debugging we would put the module in the BSOM breakout.

Reset and SWD pads are already available on 4 pads on the the B5 module and the data sheet states these are used by Particle to flash firmware. But again I wonder how the module is put in DFU mode in connection with that if necessary.

I would prefer us to do the same, as very fast options should be possible.

Is see.
In order to use the MD pad to put the device into DFU Mode you’d pull that pad low. That’s what the MODE/SETUP button does when you press it.

Unfortunately I haven’t worked with the B-SoM yet, so I don’t know wheter that MD pad is accessible on the module or via a breakout.

However, since you have a BSOM breakout, couldn’t you use that for provisioning?

Would also be nice if the datasheet would actually tell us what the twelve test points on the B523-SoM are connected to (i.e. if one exposed MD).

CC @rickkas7 - I feel like your perspective on the datasheet and any other useful flows available here might be useful.

BTW, even if you don’t have the SETUP/MODE and RESET buttons on your PCB you should still have respective pads on it to prevent problems like this in manufacturing :wink:

^ I agree with this as a general design principle. Exposing a Status RGB LED as well. Without either, troubleshooting down the line would be very difficult.

1 Like

Yes, except these connectors are not designed for a lot of module changes. But for 20 it would be fine. Would prefer to spend the automation time towards a production setup.

Yes, there is access to reset and also LEDs, just not the mode button. [Edit: and not USB. My initial thought is to let the first downloaded firmware set the setup flag to done, and perform a selftest and indicate the result with LED’s].

Still searching I just found this indicating a timed reset, is an option:

Looking for at solution that will keep working, is this also how Particle does this?

1 Like

I guess I will set up a support ticket. Just thought it would be good to have this info available in the community.

1 Like

… hmm, well the information seems to be there now. According to this part Using SWD/JTAG | Reference Documentation | Particle it should reset the mcu, erase and program.

For production I am now looking for a pre-built OpenOCD install without Particle Workbench, and a Particle config to place with it.

Tried drag and drop the other day on a Boron (super cool :+1:), but needed the mode button for that. If updated with the above built in reset, that would be great for SOM’s too, and for a service department.

Support closed the case without resoling it, stating that all the methods mentioned in the link above work without DFU mode set by buttons, despite the docs stating the opposite.

Specifically, the one thing I could try, drag and drop, does not work for me, with a Boron 2G3G, without putting the device in DFU mode with buttons as required in the documentation. Support keeps claiming the opposite. After 3 weeks of this, I have to give up on this one.

Here some findings that may help others for a Gen3 BSOM cellular product with a product set up in Console.

DFU mode (buttons/USB) is NOT needed at all - docs mentioned above, at the time of reading, are directly misleading and unfortunately wasted a lot of time in this case (also for support).

BUT, you must add you own SWD pads/connector on a PCB to flash in place as BSOM module SWD pads are on the >backside< of the module!

Alternatively flash module in the bsom breakout. The connector is not suited for large volume, but your own would be no different, so keep a stack and replace.

For a brick + app flashing config, use nRF tools + J-Link (4 secs) referenced in the link above)

For a no install setup use an updated Particle debugger + drag and drop (30 secs) or more complicated - a programmed J-Link standalone unit.

You can let you main SW check and set the “setup done flag” (reading likely only work in later OS versions):

PRODUCT_ID(01234);
PRODUCT_VERSION(117);

#include "dct.h"

void setup() {

    // Set "setup done flag" during production if not set
    // 0x01 = setup done
    // 0xff = setup not done (go into listening mode at boot)
    uint8_t setupDoneFlagCopy = 0x00;
    dct_read_app_data_copy(DCT_SETUP_DONE_OFFSET, &setupDoneFlagCopy, 1);  //int dct_read_app_data_copy(uint32_t offset, void* ptr, size_t size);
    if(setupDoneFlagCopy != 0x01){
	    const uint8_t val = 0x01;
	    dct_write_app_data(&val, DCT_SETUP_DONE_OFFSET, 1);
	    pinMode(D7, OUTPUT);
	    digitalWrite(D7, HIGH); // Solid blue on breakout signals done
	    delay(2*60*1000); // Nasty, replace with you own statemachine approach
    }
}

Steps I took:

  • Build a bin file w. your preferred tool including product ID/version
  • Convert bin to hex image (Chrome browser!): Particle Hex File Generator
  • Place B5 module in BSOM breakout board and power it
  • Connect an updated Particle debugger to the breakout and to Mac/PC
  • Drag and drop the hex file to the drive created by the Particle debugger
  • When the breakout board blue LED lights solid blue you are done
  • In console>product>devices>add module, enter serial (activates SIM with carriers)
  • The serial can be copied via the QR code on the module (the first of two series of chars)

In console product devices will have no owner. After plowing through all the documentation all day, I found this mention that indicates, you can claim via CLI if you want to, but for a cellular no credentials/customer/user product setup in Console, it should work without (see “for products only”):

For production test, this specific product is designed to be able to do an extensive self-test. Saves a lot of gear/scripting.

I have verified flashing and adding devices to a product in console this way, but have yet to see them running for a while.

1 Like