Order of flashing bootloader and device os?

Developer Tools CLI
1

we are getting ready to produce a product using the p1 and have been struggling with factory testing/flashing. see also the topic below

we only got it reliable to work with usb and this is what we plan to do, see below.

now the particle documentation says you need to flash device os first and then the bootloader and another place says you should not have to update the bootloader because the system firmware (device os?) will do that for you if necessary.

for us it seems more reliable flashing the bootloader first (particularly because you only need to enter dfu mode once)

can anyone tell me why which version should or should not work?

thanks
frank

particle identify
particle flash --serial p1-bootloader\@1.5.2+lto.bin --yes
stty -f /dev/cu.usbmodemxxxxxx 14400     (this is for mac, on windows we use: particle usb dfu)
particle flash --usb p1-system-part1\@1.5.2.bin
particle flash --usb p1-system-part2\@1.5.2.bin
particle flash --usb ~/Projects/evse/particle/flash-test/target/1.5.2/p1/application.bin
particle identify
2

The order I use is:

System part1
System part2
Tinker
bootloader
setup inc. wifi
application load

I think the bootloader update/alignment with OS version is really important. The order I use does mean putting the device in dfu mode twice!

I am not using 1.5.X as I have found that I have 12K less available RAM than with 1.4.4

3

hi armor: you load the application right after the system before the bootloader?

4

i did some further investigation and it seems the bootloader is automatically upgraded by the new system. see below: took a virgin p1 (was on 0.5.3 – see first “identify”, and bootloader “version 7” – see first “inspect”) and flashed it with device os / system 1.5.2. afterwards the bootloader is still “version 7”.

i power-cycled the device and yes: bootloader “version 502”

my initial factory script (including upgrading the bootloader) would not expose the “photon-xxxx” AP. only after reboot. with the system upgrading the bootloader it seems you have to reboot twice before you see the AP.

we do not care not having the AP in the factory but when the product is at the customer it should work right away. should we force a reboot in the factory (can this be done over usb?).

would appreciate someone with knowledge of how this works elaborate…

thanks
frank

MackMyra:deviceOs frank$ particle identify

Your device id is 410062001851363036373538
Your system firmware version is 0.5.3
MackMyra:deviceOs frank$ particle serial inspect
Platform: 8 - P1
Modules
  Bootloader module #0 - version 7, main location, 16384 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
  empty - main location, 262144 bytes max size
  System module #2 - version 21, main location, 262144 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #1 - version 21
  User module #1 - version 4, main location, 131072 bytes max size
    UUID: 11B13BD023486339343808493C222BBD27753EB71D4290F352EE4D7A11AB9E82
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #2 - version 21
  User module #1 - version 4, factory location, 131072 bytes max size
    UUID: 11B13BD023486339343808493C222BBD27753EB71D4290F352EE4D7A11AB9E82
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #2 - version 21
MackMyra:deviceOs frank$ stty -f /dev/cu.usbmodem00000000050C1 14400
MackMyra:deviceOs frank$ particle flash --usb p1-system-part1\@1.5.2.bin

Flash success!
MackMyra:deviceOs frank$ particle flash --usb p1-system-part2\@1.5.2.bin

Flash success!
MackMyra:deviceOs frank$ particle flash --usb 
application.bin              factory.sh                   p1-system-part1@1.5.2.bin
factory.bat                  lib/                         p1-system-part2@1.5.2.bin
factory.js                   p1-bootloader@1.5.2+lto.bin  
MackMyra:deviceOs frank$ particle flash --usb application.bin 

Flash success!
MackMyra:deviceOs frank$ particle identify

Your device id is 410062001851363036373538
Your system firmware version is 1.5.2
MackMyra:deviceOs frank$ particle serial inspect
Platform: 8 - P1
Modules
  Bootloader module #0 - version 7, main location, 16384 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
  System module #1 - version 1512, main location, 262144 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #2 - version 207
  System module #2 - version 1512, main location, 262144 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: FAIL
      System module #1 - version 1512
      Bootloader module #0 - version 400
  User module #1 - version 6, main location, 131072 bytes max size
    UUID: C08F12006C153E35DC090857368CD2A8D2FAB510283BC76CA46710E882E3F30B
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #2 - version 1512
  User module #1 - version 4, factory location, 131072 bytes max size
    UUID: 0A08E02C0A08AC2B0A08B42A0A08292B0A08014A024B1A6070473A2B0A08FC00
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #2 - version 21
MackMyra:deviceOs frank$

after power-cycle:

MackMyra:deviceOs frank$ particle serial inspect
Platform: 8 - P1
Modules
  Bootloader module #0 - version 502, main location, 16384 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
  System module #1 - version 1512, main location, 262144 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #2 - version 207
  System module #2 - version 1512, main location, 262144 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #1 - version 1512
      Bootloader module #0 - version 400
  User module #1 - version 6, main location, 131072 bytes max size
    UUID: 0D3A802532E549FE881F39851D2220A7FD8F0F5884C306E9EBA42F16409C27FA
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #2 - version 1512
  User module #1 - version 4, factory location, 131072 bytes max size
    UUID: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #2 - version 21
MackMyra:deviceOs frank$
5

just as you start you can make sense of it all…

i do a lot of testing on the same device as i do not have an unlimited supply of virgin p1 devices

so i thought i had it all figured out but:

particle usb dfu

does not work with the device os on my virgin p1 (0.5.3)

it gives this error:

Unable to open USB device: LIBUSB_ERROR_NOT_SUPPORTED

i can do (p1 is on com4):

mode com4: baud=14400

(it does give a “not supported” error but does work)

after upgrading device os (to 1.5.2) the “particle usb dfu” does work

problem: now i have to figure out the com port…

please can anyone in the know tell us what the correct way to “factory flash” is? something that does work for all p1’s we might get

6
  • If you load the bootloader first, the keys calls like particle keys doctor will not work until after you upgrade Device OS.
  • particle usb commands in the CLI will not work until Device OS is upgraded.
  • With 0.5.3 you will need to use magic baud rate to go into DFU until upgraded.

I would use the order you described in the original post.

On the Photon and P1 the bootloader can only be upgraded OTA with 0.7.0 and later. This means you need to have Wi-Fi credentials set, or you will go into safe mode. It’s better to explicitly upgrade the bootloader if possible.

7

thanks rickkas7

  • this clears up bootloader / device os flash order: in the factory this would not matter as device os will be flashed right after
  • in the factory we will always need to do the magic baud rate trick as we have no idea what device os version we get from particle

what i still do not get is why explicitly flashing bootloader is better? seems to me the less interaction the better? (i do not want to do anything over the air…)

may i issue a feature request?: particle factory my-application.bin

this would fail safe upgrade device os and bootloader over usb (to the version available in particle-cli/assets/updates) and flash the specified application. this would work without the need for an internet connection (after installing particle-cli of course). i would think this would help a lot of customers…

8

Hi @boddeke -

I am a bit late to this but here goes. I agree with the previous posters @rickkas7 and @armor… Here is the order I use. I suppose the first part does not apply as you are using P1…

  1. Download the four files I mentioned form Github. Make sure to download both Part1 and Part2 for photon firmware.
  2. Install and update Particle CLI on you computer
  3. On OSx… open Terminal (or CLI in workbench)
  4. Connect device to you USB port
  5. Make sure devices is in DFU mode (flashing yellow)
  6. In terminal type: particle flash --usb and then simply drag the downloaded files into the terminal (one by one) window. It will automatically enter te file name and path. The device should remain in DFU mode after each flash, unlike Particle Doctor.
  7. Hit Enter. When done, repeat with the next file, in this order:
  • photon-system-part1@1.5.bin
  • photon-system-part2@1.5.bin
  • photon-bootloader@1.5.0+lto.bin
  • photon-tinker@1.5.0.bin

You can use the version required.

Regards,
Friedl.

9

thanks friedl

thanks for sharing

manually upgrading a single device is something different from automatically doing this in the factory with thousands of devices

1 Like
10

Hi -

For sure. Sorry, could actually just send the order I suppose, just copied and posted from post assisting another user :wink: My understanding is the sequence is the same?

Regards,
Friedl.