Writing to MCU flash

We have a serial flash cal table on most of our products, written by the onboard ARM, with a checksum. That works fine.

We have a default cal table in the program, which gets loaded at first powerup or if the flash table is corrupted. Users are informed of we are running the default.

The cal table also includes cal table type ID, model number, dash number, serial number, and cal date.

The cal table resides in a separate soldered-down flash chip from the program/FPGA code, so we can mail a new plug-in code chip to a customer without trashing the calibrations.

We sometimes self-cal some things every powerup, like ADC gains and offsets, and keep those in ram. But with Susumus, you could cal at test time. You probably need some nonvolatile cals.

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics

So you don't ever have firmware write stuff to MCU flash?

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC / Hobbs ElectroOptics 
Optics, Electro-optics, Photonics, Analog Electronics 
Briarcliff Manor NY 10510 

http://electrooptical.net 
http://hobbs-eo.com

Is there anything behind the lore? Or is it just random mutterings on the idle packets streaming the Internet?

Many products, many MANY products have the ability to update their firmware. To do that requires they write to their own flash. How bad can it be?

Rick C.

- Get 6 months of free supercharging - Tesla referral code -

Users can do soft upgrades to the runtime code, but it's often easier and safer to mail them a chip rather than have them upgrade over ethernet or USB. There's a lot less to explain.

(Some people just take the box home and plug in the chip there, rather than dealing with their IT Prevention Department. These people also take their laptop to Starbucks to get files from us.)

We have two program images in each box, "factory" and "upgrade." A user can run software (sometimes just a browser) to flash the upgrade image.

At powerup, a boot loader checks for a valid upgrade image, and runs it if it looks OK. Otherwise it runs the factory image. If we mail the user a plugin flash chip, it has only a factory image. RMAs get reflashed with just the appropriate factory code.

With a hundred or two products having revs and dash numbers and ECOs, and multiple code revs, and corresponding cal tables, and factory cal software, we have a nontrivial configuration management problem. It's important that a user can tell us exactly what is the state of his box.

We made our own plugin DIP8 adapter for surface-mount serial flash chips, with room for a label.

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics

the update procedure does in some cases involve the host loading a flash programmer into RAM, so if you are the belt and suspenders type you avoid the small risk of having flash programming code in the product that could be triggered by accident

torsdag den 24. januar 2019 kl. 16.25.20 UTC+1 skrev Phil Hobbs:

I do it on an STM, but there is the small risk of having code in the MCU that can program flash possibly being triggered by some cosmic event, supply glitch etc.

Our presumably bug-free boot loader resides in the same flash as the runtime code images. In the improbable event that the loader gets trashed, we can send them a new plugin flash or they can send the box back.

Some simpler products use a single-chip approach, no outboard flash. They may not be field upgradable.

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics

I did not go through the 804 data sheet but on other LPC I've used:

1 - minimum size is going to be 4K blocks 2 - everything is going to stall while the flash operation is in progress, no interrupts, no nothing. If you are going to do some type of self cal you need to run the cal, gather the data and then do the write (well, erase and write).

If you are going to be updating the calibration table many many times I think it's best to have a SPI or I2C eeprom or flash.

--
Chisolm 
Republic of Texas

No on-board EEPROM on those parts? Maybe 8 bit has a life after all. Even the 50 cent ATTiny85 has 512 bytes of 100k-cycle EEPROM on die it can come in very handy

It's probably FUD. On AVR at least it's easy to declare a static program-memory-space buffer in the .data section that will never be used to put executable code. Then there are op-codes to write Flash memory space from executing code though they sometimes have to be executed from a certain address range in the Flash itself (bootloader section.)

There are function tags and compiler flags to ensure your write function is executed from the proper location. I would assume ARM has something similar.

With the caveats that Flash is only good for ~10k write cycles and that it can only be read and written to in "pages" of some size it would seem the worst that could happen is your Flash-buffer gets corrupted from a power loss during a write-out so CRC to test for it.

On that platform for C/C++ all the grunt assembler bullshit is macro-ified and there's a header to simplify the process avr/boot.h

Lasse Langwadt Christensen wrote

I use the code protection feature of Microchip PICs when I do not want to show the code in some cases. So releasing code memory update using that boot loader is out. I agree with J Larkin that it is better to simply send a new chip (are on sockets for that reason anyways). User settings and calibration are in EEPROM in the chip, or an external chip. Having default settings in code is a nice idea (have not done that, EEPROMs are programmed to default when programming). There is a small risk in using sockets, those can fail, good quality sockets are OK. I am wondering about J.L's security (especially the companies that go to starbucks for coffee and updates), WiFi has been completely hacked, Theoretically you could simply pose as the manufacturer and send a fixed update etc etc. Would be a no-no for me.

Replacing chips on sockets is easy, just added some features to some project today... however that also needed adding some hardware... Drone flight recorder can record flight and then you can have it fly that again and again all by itself. Saved as a text file, can edit it too. lat lon alt speed heading.... other commands.... to / from SDcard... Just for fun.

I've done a (proof-of-concept at least) field-upgradeable ATTiny 8 pin, a 512 byte bootloader is sufficient to hold code that can receive a bit-banged in serial stream with a "magic sequence" that the bootloader waits for a couple seconds to see if it receives on start-up, if it shows up it's saying "Attetion, bootloader, new program data coming in" and it writes out the stream to program memory and reboots when it's complete after performing a checksum.

If the process is interrupted or cheksum fails it's OK the bootloader section is untouchable so just try again.

I have thousands of AT91SAM and STM32 -based Cortex devices in the field, having the capacity of writing into the internal Flash.

The devil of the details depends on the particular chip, but in general you have to copy the innermost parts of the write loops into RAM and run them from there, as the Flash is inaccessible durin an erase or write. The minimum write unti depends on the chip (again), but it usually is from 1 byte to 8 bytes. Some manufacturers are not happy even to specify it.

Usually, the write code has to be linked so that it is prepared to run in the RAM addresses.

--

-TV

Have done it for years.

Sometimes we use a socketed SD card instead of a plugin dip flash chip. The Zynq SOCs know how to boot off SD cards.

--

John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  

jlarkin att highlandtechnology dott com 
http://www.highlandtechnology.com

There's EEPROM emulation code out there for that MCU. It should work okay, provided you don't need smooth functioning to continue during the write and are not too tight on the code space so that granularity matters.

I also note the endurance is claimed to be 200K for that part, which is not terrible (typically it's 1,000,000 for a serial EEPROM).

On the other hand, I think I'd at least consider laying out the PCB for an I2C EEPROM such as the AT24xx series. If even one piece of product gets bricked that would pay for a lot of 15 cent EEPROMs.

I'm using an external EEPROM with an M7 ARM because it's there anyway for the MAC address.

--Spehro Pefhany

We have one instrument where we want the front panel settings preserved over a power cycle, so we write to flash often. We use a 16 kbit FRAM that claims 1e14 writes.

--

John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  

jlarkin att highlandtechnology dott com 
http://www.highlandtechnology.com

Not a bad idea at all. In this case the cal will be pretty stable--the dpot only has 256 steps--so we can avoid that problem by doing the cal once at test time.

Thanks

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC / Hobbs ElectroOptics 
Optics, Electro-optics, Photonics, Analog Electronics 
Briarcliff Manor NY 10510 

http://electrooptical.net 
http://hobbs-eo.com