Factory testing: can we access "tinker" functions via USB for an unclaimed device?

hi all

we like to do some factory testing on our device with a P1. looks like USB is the easiest to do. we can get the particle ID from the device using:

 particle identify

all P1’s come with “tinker” installed? can we access tinker functions via USB for an unclaimed device? “particle call” does not seem to work for unclaimed devices

any one any idea?

help much appreciated!

Nope, in the default Tinker app there is no USB access to functions implemented.

thanks ScruffR… that is too bad - though that was a handy way to test

what are people doing for factory testing?


Typically they would flash their own firmware - either dedicated test apps or testing features of the production application.

we cannot seem to flash firmware reliably using swd. so the idea is to use usb to do this. this seems to depend on the device-os on the p1. i have asked particle if the guarantee device-os version on a order but i am not getting any response from them.

do other people have the same experience?

so far we have no reliable factory testing/flashing solution

There is no way to guarantee which version of Device OS will be present on a device from the factory, due to the lag through the distribution channel.

If you are using USB, you should flash Device OS (both parts), the bootloader, and your user firmware during your device setup. Any version of Device OS will support this; there is no need to have a specific version.

Also the most common reason SWD doesn’t work is that it’s disabled by default once Device OS boots. The easiest solution is to force the device into DFU mode (blinking yellow), at which time SWD will remain enabled and you can then flash everything by SWD. This is super-fast if you use a Segger J-Link.

1 Like

hi rickkas7,

thanks for help!

i am still not completely sure what to do/tell our factory…

  • usb does flash does not seem to work on the p1 samples we got. (usb identify does). what would be the usb command sequence to flash the p1 in the factory?

  • how is forcing dfu mode done in the factory? should be use tps for mode and reset and time? seems weird?

  • we got two versions of particle programmers and a st-link-v2: they give no reliable result. are you saying the segger j-link is faster?

  • assuming we get flashing with swd to work: is swd the preferred way?

i think it would be very nice to have this info on the particle website. right now i see examples that do not work (e.g.: we especially got the sparkfun redboard p1 and the st-link programmer – no joy)


To flash via usb:
particle flash --usb firmware.bin
To place your device into DFU mode via usb:

particle usb listen
particle usb dfu

mmm… still not working… i have a fresh sparkfun redboard p1 connected via usb. see below.

what am i doing wrong?

MackMyra:p1 frank$ particle identify

Your device id is <— id —>
Your system firmware version is 0.4.4

MackMyra:p1 frank$ particle flash --usb flash-test.bin

!!! 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.

  2. Release only the RESET/RST button while continuing to hold the MODE/SETUP button.

  3. Release the MODE/SETUP button once the device begins to blink yellow.

Error writing firmware: No DFU device found

MackMyra:p1 frank$ particle usb listen
IN control transfer failed: LIBUSB_TRANSFER_TIMED_OUT

MackMyra:p1 frank$ particle usb dfu
IN control transfer failed: LIBUSB_TRANSFER_TIMED_OUT

ok, black magic? this seems to work to get into dfu mode… why does this work??

The magic baudrate(s) is a feature that was virtually present right from the beginning and was later superseded (but not replaced) by the USB Control Requests (e.g. particle usb dfu).
However, only more recent device OS version support USB Control Requests, so the magic baudrate is the safer bet when you cannot be sure to get a fairly recent batch of devices.

Your working particle identify call indicates that the device is in Listening Mode (blinking blue) so you cannot use particle flash --usb in that mode.
You either need to use particle flash --serial or first swtich over into DFU Mode via particle usb dfu (as @no1089 already indicated) or via the magic baud rate.

thanks again scruffR! starts to make sense. too bad that this is nowhere to be found in the documentation

now we can identify the device and put it in dfu mode. i can also flash the application firmware

how can i also flash the device-os?

below my target files. flash-test.bin seems only the application as it is so small but i cannot flash (over usb) the hex or elf. help says it only accepts “bin”. is it possible over usb? or do we need to do this with an swd programmer?

MackMyra:p1 frank$ ls -al
total 12072
drwxr-xr-x  10 frank  staff      320 Jul  2 10:41 .
drwxr-xr-x   4 frank  staff      128 Jul  2 10:41 ..
-rwxr-xr-x   1 frank  staff     5304 Jul  2 10:41 flash-test.bin
-rw-r--r--   1 frank  staff       38 Jul  2 10:41 flash-test.bin.crc_block
-rw-r--r--   1 frank  staff     5300 Jul  2 10:41 flash-test.bin.no_crc
-rwxr-xr-x   1 frank  staff  1919776 Jul  2 10:41 flash-test.elf
-rw-r--r--   1 frank  staff    15027 Jul  2 10:41 flash-test.hex
-rw-r--r--   1 frank  staff   130957 Jul  2 10:41 flash-test.lst
-rw-r--r--   1 frank  staff  4088943 Jul  2 10:41 flash-test.map
drwxr-xr-x   3 frank  staff       96 Jul  2 10:41 obj

I wouldn’t say that - you may just not have found it :wink:

At least the error message clearly tells you so

With regards to the magic baudrate one instance where the docs do mention it is here

And for CLI the particle usb dfu docs can be found here

When you have the device OS binaries you can flash them just the same as you would flash your application. The only thing to pay attention to is the order in which you flash. The device OS on a Photon/P0/P1 consists of two parts and you need to flash

  1. part one
  2. part two
  3. application

If your new device OS requires a new bootloader you need to flash that too best before part 1 (and depending on your starting of OS version this may only work via particle flash --serial in Listening Mode).

1 Like

hi ScruffR,

you are right, the switching to 14400 baud is in the documentation… but it is like you can only find it when you know what you are looking for. some countries (not naming any…) have road signs like this: you see them pointing to your destination only when you are going in the right direction already.

thanks for helping me back to going into the right direction!

1 Like

just for other confused souls… here is what we got to work now (mac os 10.15.5, p1 on a sparkfun redboard with device os 0.4.4, flash-test is my test project, compiled with vcode):

// get device id and device os version
particle identify
// mac only: put in dfu mode
stty -f /dev/cu.usbmodem14101 14400
// update device os to latest
particle update
// flash application
particle flash --usb flash-test.bin

we can also flash the device os directly (not using ‘particle update’) using:

particle flash --usb .particle/node_modules/particle-cli/assets/updates/p1-system-part1\@1.5.2.bin
particle flash --usb .particle/node_modules/particle-cli/assets/updates/p1-system-part2\@1.5.2.bin

this will be handy to keep application and device-os versions together (in the factory)

open questions for us:

  • how do we update the bootloader (p1-bootloader@1.5.2+lto.bin)? is that possible with particle flash --usb? doing the same as device os flash gives (and i did not dare to try “–force” yet): Error writing firmware: unknown module function 2, use --force to override
  • after upgrading the device os and flashing the application the p1 will still come up in listen mode: how can we have it execute our test code? <— sorry, my fault, works! as long as SYSTEM_MODE(MANUAL) is used! so happy!

As mentioned above, you can always use particle flash --serial in Listening Mode (even for device OS and application) and with OS versions after 1.0.0 (IIRC) you should also be able to use particle flash --usb to flash the bootloader but never use force - if it doesn’t want to work there is probably a good reason for it.

This is due to the fact that your application expects to establish a cloud connection (as you already found out) but has no WiFi credentials stored to do so.

1 Like


MackMyra:updates frank$ particle flash --serial p1-bootloader\@1.5.2+lto.bin 
! PROTIP: Hold the SETUP button on your device until it blinks blue!
? Press ENTER when your device is blinking BLUE 
sending file: p1-bootloader@1.5.2+lto.bin

Flash success!

so in the factory we will first upgrade the bootloader (p1 will come up in listen-mode so that is easy) – just need to figure out how not to have to press ‘enter’

after upgrading the bootloader we will upgrade device os to a specific version and flash out test application

Have you tried the -q switch?

I went through this exact same gymnastics exercise with flashing a new device for shipping. One thing I would add, not sure how much it matters, but I flash the bootloader AFTER the system parts instead of before as @ScruffR suggested. This is per the release notes. They always say the following:

If your device does not connect to the cloud and it is offline, you should flash the bootloader to the device using particle flash --serial <bootloader.bin> . This should be done after upgrading system firmware

Maybe there are scenarios where it should be the other way though.

too bad… still needs manual “enter”:

MackMyra:updates frank$ particle -q flash --serial p1-bootloader@1.5.2+lto.bin
! PROTIP: Hold the SETUP button on your device until it blinks blue!
? Press ENTER when your device is blinking BLUE
sending file: p1-bootloader@1.5.2+lto.bin

Flash success!

Flash success!