Posted on May 17, 2011 at 13:28I guess my point is that I wouldn't use data pulled off a device as a golden standard to produce all the others, I would want to use the first generation output from the tool chain, or automated make process. If the data on the working device were somehow different to the code that was supposed to be onboard I would be quite worried. Things have advanced considerably since I had to make golden EPROMS for a stand-alone PROM programmer where bytes/words had to be swapped and split across multiple devices.
When developing production code I use CVS to achieve source code control, I would check in and tag a build of software giving it a version number, I would associate that with the BIN/HEX file generated by the tools, and the version/build of the tool chain used to create it. The BIN/HEX file would then be signed off to production.
If at some point in the future I have to revisit the code because a customer (my boss, sales, whomever) finds a bug or wants a feature added, not only can I produce the ROM image they have, but the source code that made it. If necessary I can remake it, and versions and branches prior to and derived from it. Frankly anyone within the organization should be able to do it to.
I would want to be able take a blank STM32 and burn the hex file to it with any of a number of tools, I would not want to have the development IDE program it and then extract a binary image to generate a production image. I might want to pull off a binary image if I wanted to confirm that the tools programmed it correctly, or if someone gave me a random part and wanted to know/confirm what was on it.
In the case of part unique data (configuration, calibration, serial, etc), I would look to have the boot code identify the absence and enter a production test mode. Alternatively I would partition the image, or mark configuration data, so that the production programming tool could insert suitable data.
Hopefully that was the elaboration you were looking for.
-Clive
