How to save time in production with STM32F429

[Linda]

Posted on May 25, 2015 at 14:22

Hi,

We are preparing production now. Because we use Unique ID to protect the products, each time we need to key the 96 digit Unique ID into the original file, then run the compile(rebuild), then flash into MCU. There is any way to skip the compile(rebuild) step. It take too long to compile for each MCU.Thanks a lot 

[Mark Edwards]

Posted on May 29, 2015 at 19:50

 I took the .HEX and try modify it , but I don't know where I should modify.

Doesn’t your compiler give you a .MAP file? It will tell you exactly where “Serial_String�? is located.

PowerShell script to convert generic file to device specific file and then run the compile(rebuild),

flash into MCU, cycle.

Are you using encrypted code? If not, editing the raw file should be enough to do away with Compile Time. If you are, I can’t see away around re-compiling, so the signature is correct.

[Chris1]

Posted on May 29, 2015 at 21:30 The way we serialize products is to include a feature in the firmware that allows the system to receive information from a computer that calibrates the product and provides a unique serial number.  The firmware stores the serial number and calibration information in an EEPROM or a dedicated region of the flash memory.  The firmware image itself is not different from unit to unit. If we did not have a suitable communication interface in the product or test / calibration equipment, I would advocate use of a production programmer that can automatically write a number to a specific flash address and increment the number after each programming operation, such as Segger's Flasher ARM.   This is a simple solution for simple scenarios, this would not work well for more complex situations requiring signing, etc.  

[Jeroen3]

Posted on June 02, 2015 at 11:31

Because it's complicated for to maintain software that modifies each binary flashed in. Our binary is identical, and then when first programmed and run on the testbench, the product calculates it own crc and writes this to flash.

You can make such simple self-signing binary the same way, possibly by adding this into a higher flash page that will get erased when done, if you're paranoid enough.No need for extra tooling. Just have the production crew press ''download'' and wait for the green blinky led.

[Hamid.Wasti]

Posted on June 02, 2015 at 12:03

> the product calculates it own crc and writes this to flash.

That is a really dangerous practice. If the binary is not downloaded correctly, the CRC will reflect the incorrect data. This means you can have a chip with a valid CRC but bad binary. In order to provide full protection, the CRC has to be computed at compile/link time and downloaded to the processor with the binary.

[Hamid.Wasti]

Posted on June 02, 2015 at 12:12

> Signing and encrypting a firmware image can get quite involved, so I'll stick here with just a small chip/board unique structure that can be filled in by a suitably coded programming station.

There is an easy way to improve the code posted above by clive1. Instead of declaring SIGNFOO as a static const at some unknown location in the middle of the text section, I would explicitly place it high in the Flash PROM and get a pointer to that address. This way you always know where this structure is located and do not have to change the programming software every time the code changes.

[Linda]

Posted on June 03, 2015 at 21:32

Thanks all you, I finally make it work.

I appreciate these help for your guys!