Firmware doesn't run on unclaimed/brand new device

[HEng]

Hi guys,

I’m trying to finish up a production test stand and I’m stumped.

My test firmware runs on initial sample hardware just fine-- this device has been claimed and connected to the cloud before.

New devices that I pull out of the box (not yet claimed, or connected to cloud) will not run my test firmware. Initially I thought it was because the system firmware is 0.5.3 and my test code was compiled against 0.7.0, but after using dfu-util to update the device, I am getting the same result.

I am using ymodem to upload test firmware and that works just fine on my initial sample hardware. It seems to succeed on new PCBs as well, but then the firmware will not run.

Does anyone have any suggestions on things to sanity check? At this point I’m stuck.

[nrobinson2000]

Have you flashed the 0.7.0 bootloader as well?

Ping @BDub

[HEng]

Is the bootloader actually a bootloader updater application? I can just flash this using YMODEM, right?

Otherwise, is there a DFU-UTIL command, because I’m not seeing it?

EDIT: It would be exceptionally helpful if someone has a tip on how to use dfu-util to flash the bootloader. This would mean I could do four consecutive dfu-util commands that loads part1, part2, bootloader, and application all in one go!

[HEng]

@nrobinson2000

You’re right, the bootloader being an old version is apparently enough to prevent firmware from running… since I need it to run on the test stand, I MUST update the system firmware and the bootloader before it will run.

I just did an update with

particle flash --serial bootloader-0.7.0-p1.bin

…which after having intractable installation problems with particle-cli/npm, unexpectedly worked!

[nrobinson2000]

@HEng

EDIT: It would be exceptionally helpful if someone has a tip on how to use dfu-util to flash the bootloader. This would mean I could do four consecutive dfu-util commands that loads part1, part2, bootloader, and application all in one go!

I could help with that. Are you on mac or Linux?

[HEng]

Linux.

So far I have a script that looks like

#!/bin/bash

# This script runs commands to update the P1 to 0.7.0 system firmware

dfu-util -d 2b04:d008 -a 0 -s 0x8020000 -D system-part1-0.7.0-p1.bin
dfu-util -d 2b04:d008 -a 0 -s 0x8060000:leave -D system-part2-0.7.0-p1.bin

particle flash --serial bootloader-0.7.0-p1.bin

But I would like something more like:

#!/bin/bash

# This script runs commands to update the P1 to 0.7.0 system firmware

dfu-util -d 2b04:d008 -a 0 -s 0x8020000 -D system-part1-0.7.0-p1.bin
dfu-util -d 2b04:d008 -a 0 -s 0x8060000 -D system-part2-0.7.0-p1.bin
dfu-util -d 2b04:d008 -a 0 -s 0x80?0000 -D bootloader-0.7.0-p1.bin
dfu-util -d 2b04:d008 -a 0 -s 0x80A0000:leave -D app.bin

[nrobinson2000]

What improvements are you looking for exactly?

If you need to have the P1 go into dfu mode automatically I would suggest incorporating custom-baud.c into your script.

I think you could also use:

particle flash --usb bootloader-0.7.0-p1.bin

To have it automatically write to the correct dfu address.

[HEng]

                                  v--What goes here??
dfu-util -d 2b04:d008 -a 0 -s 0x80?0000 -D bootloader-0.7.0-p1.bin

I can't find this information anywhere. I'm trying to avoid the particle command line tools because I have found them to be very flaky and somewhat unpredictable to install and use, especially since I'm integrating them into a larger script.

Also,

@nrobinson2000

If you need to have the P1 go into dfu mode automatically I would suggest incorporating custom-baud.c into your script.

Works like a charm!

[nrobinson2000]

@HEng

I’m trying to avoid the particle command line tools because I have found them to be very flaky and somewhat unpredictable to install and use, especially since I’m integrating them into a larger script.

Understood.

I just tried this (note the -v flag):

$ particle flash --usb -v temp-photon.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2b04:d006
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 = 0x080a0000, size = 3252
Download	[=========================] 100%         3252 bytes
Download done.
File downloaded successfully

Flash success

Right here:

Downloading to address = 0x080a0000, size = 3252

In this example 0x080a0000 is the address.

EDIT:

I think if you tried:

particle flash --usb -v bootloader-0.7.0-p1.bin

The address would be revealed.

[HEng]

@nrobinson2000

I think if you tried:

particle flash --usb -v bootloader-0.7.0-p1.bin

The address would be revealed.

Error writing firmware...unknown module function 2, use --force to override

[nrobinson2000]

I assume you are flashing the bootloader in the right step of the sequence?

That error sounds dumb.

[HEng]

It successfully flashes over serial with no complaints.

I am concerned that magic is happening behind the scenes here since information has been suspiciously omitted.

[nrobinson2000]

@HEng

I am concerned that magic is happening behind the scenes here since information has been suspiciously omitted.

Perhaps. Did you try --force?

[HEng]

Dare I?

[nrobinson2000]

It's the only way to be sure.

EDIT:

Note: DFU over USB on Electron/Photon/P1 (sequence not required)

You may update to 0.7.0 directly, but make sure you have installed v1.29.0 of the CLI (check with particle --version) then run particle update.

Note: P1/Photon Bootloader

The cloud will automatically update the bootloader on P1/Photon devices. If your device does not connect to the cloud, you should flash the bootloader to the device using particle flash --serial. This should be done after upgrading system firmware.

Definitely some particle magic here.

[HEng]

@nrobinson2000

It’s the only way to be sure.

And now I am sure that doesn't work!

Edited:
Somewhat as expected, it wrote to 0x080a0000, so no different than an application.

It ended up continuously fast flashing white. I recovered it by writing my test firmware back over the address at 0x080a0000.

I think that bootloader-0.7.0-p1.bin is a "bootloader updater application" that has a magic component.. or I think the serial handler does something special with it....

[nrobinson2000]

@HEng

Somewhat as expected, it wrote to 0x080a0000.

It ended up continuously fast flashing white. I recovered it by writing my test firmware back over the address at 0x080a0000.

I think that bootloader-0.7.0-p1.bin is a “bootloader updater application” that has a magic component. That doesn’t explain how my application was preserved in application memory when I updated the bootloader though!

Interesting. It's a shame that you are forced to used particle flash --serial. Out of curiosity, does -v have any effect?

[HEng]

@nrobinson2000

does -v have any effect?

It actually doesn't change the output at all using --serial.

[nrobinson2000]

Dang it.

shakes fist at particle for using particle magic

EDIT:

I just found this which explains it well.

Photon 7.0 USB failure

You most likely need to update the bootloader. Download the Photon bootloader here: Then flash it in listening mode (blinking dark blue): particle flash --serial bootloader-0.7.0-photon.bin In versions prior to 0.7.0 the bootloader is embedded in the system firmware. In 0.7.0 and later, there is not enough room, so it’s a separate download, which is done by safe mode healer over-the-air usually. However, if you have a Photon that is not set up for Wi-Fi yet or otherwise unable to connect to…

[ScruffR]

@nrobinson2000

I think you could also use:

particle flash --usb bootloader-0.7.0-p1.bin

Nope, the bootloader is running DFU Mode, so with the device in DFU Mode you can't replace the bootloader, but --serial is using YModem and this way you can replace the bootloader.