Factory Firmware Updates

Firmware
1

So with the major features being merged into master,

  1. Am I right to say essentially the core still stays with the ‘Factory Reset Firmware’ version programmed during production?

  2. Only dfu-util is possible to update the copy of ‘Factory Reset Firmware’ i believe?

  3. Would be nice to see some ‘Factory Reset Firmware’ pushed through the cloud in future :smiley:

Or it’s somehow possible with the current infrastructure?

I won’t mind giving it a shot but that’s kinda the most important piece of code when you meet some ‘dead’ core/ error etcs…

2

  1. Yes, unless you have a really old core… then after your factory reset occurs and it connects to the cloud, it updates itself to the latest factory firmware (thereby taking a little bit longer to restore). This updated factory firmware is not saved to external flash.

  2. Correct.

  3. This would be risky, but doable.

The core is completely recoverable even if you brick the bootloader… but you need a one time cost of $20 JTAG programmer, and $20 JTAG programming adapter.

3

Having reliable cloud update of that would be really cool!

Things get more fun with people using local clouds and they might need to update their factory reset firmware once in a while and multiples of them.

4

How about an application called SparkAirLoad?

  1. It fetches the new factory bin file from a known location over http.
  2. then it updates the serial flash at the factor offset.

@BDub or @timb willing to code it?

1 Like
5

While that does sound like fun, I’m completely backed up with tons of things in the pipeline to finish!

I would suggest baking in an expected SHA-1 Hash into the application for the target BIN, and checking it for errors before and after writing to Flash (if possible).

I wonder if the DFU-UTIL process even does any kind of significant error checking…

6

Sounds like a feature for the command line interface :slight_smile:

7

or could be done through the Cloud - no need to wire up an external http service for this. but as @BDub said this has to be done super carefully, because the current architecture of the factory reset is designed to make the Core as unbrickable as possible, and we want to keep it that way :slight_smile:

8

We should KIV this feature then! I’m sure the advanced user would love to have this when they make products with :spark: core inside :smiley:

9

I’m with @BDub, I’m totally backed up right now working on three boards/projects for :spark: plus a bunch of other stuff.

10

@kennethlimcp

I am not failure the TLA (Three Letter Acronym) KIV please elaborate

11

Keep in view hahahaha :smiley:

12

I would like to see the BOOT0 pin to be available. Unfortunately, it is grounded with a via under the device! Why on earth?

1 Like
13

I don’t have time to look up what BOOT0 does… what would you use it for?

14

It allows one to enable system bootloader over USART1, using PA9 and PA10 pins, which are accessible as LED3 and LED4.

15

Keep going… :wink:

How do you intend to use that vs. what we currently have working for a bootloader?

16

I’m thinking he wants to use the internal UART boot loader?

In this case your best bet would be to change the current boot loader firmware to work over Serial1 instead if Serial and flash it with a JTAG adapter.

17

I think there is a little more to it…

Embedded boot loader - It is a way to enable the ST factory bootloader in ROM (I think it is locked Flash) - The Pin should be brought out to a test pad at the minimum. It would aid in mfg, and because it is the only way to recover/program a part without a jtag.