EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

Question About Firmware Releases and Part Numbers

Started by Mr. C April 7, 2005
I was wondering how people handle a firmware change in the
manufacturing process.  One thing we  are considering is  issuing a
new part number for every firmware release.  The number may be a "Rev
B" or some extension of a base part number, but it would be unique for
each firmware release.  Then, when a unit is built, it must use a
certain "part number" that is really a firmware release, probably in
the form of some FLASH programming device, or at least a file that
contains the memory image for a micro-controller.

A problem comes into play if there are already manufactured units
ready to ship when a new firmware release is issued.  I would think
the micro-controller, or EPROMs, or whatever form the firmware is
released in would have a sticker on it with maybe the part number?  Or
should the sticker have the firmware revision number, or both?

We also thought of forgetting about the part number scheme and just
having some sort of list or database with the "correct" firmware
release listed.  The advantage there would be special runs of an older
firmware release (something we have to do at times) could easily be
made without worrying about using a part number that was obsoleted by
a newer one.

I know the best way can cepend on the manufacturing/part number/ECO
system in use.  But I am sure others have been down this road before
and may have some good suggestions.  I am all ears and thankful for
those that may wish to reply.

Lou

> I was wondering how people handle a firmware change in the > manufacturing process. One thing we are considering is issuing a > new part number for every firmware release. The number may be a "Rev
We consider a programmed microcontroller or EEPROM to be a subassembly with its own bill of materials. When the firmware is revised, the part number gets an incrementing suffix. The downside of this method is that it's legal for the blank microcontroller to change, too. So it might not be possible to upgrade from version xxxxx1 to xxxxx2 without desoldering the part. This doesn't affect us much because we mostly use OTP devices and even when they are flash devices, we don't allow field-upgrades (it's RTB or no upgrade).
> released in would have a sticker on it with maybe the part number?
Or
> should the sticker have the firmware revision number, or both?
Our stickers have the internal part number only. Users and factory workers don't normally care about the internal firmware rev#, they simply need to be told "if the part number is xxxxxx2 or higher, it's got ABC feature". Masked parts are laser-marked with the internal part number.
Mr. C wrote:

> I was wondering how people handle a firmware change in the > manufacturing process. One thing we are considering is issuing a > new part number for every firmware release. The number may be a "Rev > B" or some extension of a base part number, but it would be unique for > each firmware release. Then, when a unit is built, it must use a > certain "part number" that is really a firmware release, probably in > the form of some FLASH programming device, or at least a file that > contains the memory image for a micro-controller. > > A problem comes into play if there are already manufactured units > ready to ship when a new firmware release is issued. I would think > the micro-controller, or EPROMs, or whatever form the firmware is > released in would have a sticker on it with maybe the part number? Or > should the sticker have the firmware revision number, or both? > > We also thought of forgetting about the part number scheme and just > having some sort of list or database with the "correct" firmware > release listed. The advantage there would be special runs of an older > firmware release (something we have to do at times) could easily be > made without worrying about using a part number that was obsoleted by > a newer one. > > I know the best way can cepend on the manufacturing/part number/ECO > system in use. But I am sure others have been down this road before > and may have some good suggestions. I am all ears and thankful for > those that may wish to reply. > > Lou
If you consider that the firmware is just another component, mentioned on the bill of materials then you should not have much problem tracking what is what. I identify things by main functionality. If the base functions change then that is a different part number (and a different model dash number for the final product too). For upgrades that maintain the same base functionality the part number is the same but the revision number changes. Each item that has a part number has a proper drawing in the general assembly set that details the part (and yes, if it is an EPROM, the part is drawn with one view showing the labelling details). Keeping track of the changes is basic configuration management. -- ******************************************************************** Paul E. Bennett ....................<email://peb@amleth.demon.co.uk> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/> Mob: +44 (0)7811-639972 Tel: +44 (0)1235-811095 Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/ ********************************************************************
larwe@larwe.com wrote:
> > I was wondering how people handle a firmware change in the > > manufacturing process. One thing we are considering is issuing a > > new part number for every firmware release. The number may be a
"Rev
> > We consider a programmed microcontroller or EEPROM to be a
subassembly
> with its own bill of materials. When the firmware is revised, the
part
> number gets an incrementing suffix. The downside of this method is
that
> it's legal for the blank microcontroller to change, too. So it might > not be possible to upgrade from version xxxxx1 to xxxxx2 without > desoldering the part. This doesn't affect us much because we mostly
use
> OTP devices and even when they are flash devices, we don't allow > field-upgrades (it's RTB or no upgrade). > > > released in would have a sticker on it with maybe the part number? > Or > > should the sticker have the firmware revision number, or both? > > Our stickers have the internal part number only. Users and factory > workers don't normally care about the internal firmware rev#, they > simply need to be told "if the part number is xxxxxx2 or higher, it's > got ABC feature". > > Masked parts are laser-marked with the internal part number.
This depends on what you call firmware. We do the same as you do for parts that can be considered hardware-like i.e. small MCUs that are replacements for hardware. But for the main functionality we cannot change the revision number on labels each time the customer requests a change. We have a hierarchical database, the top item is the equipment, the hardware and software are sub items each with their part/rev number. A document is delivered to the customer and identifies all part/rev numbers and reasons for change. The manufacturing process is not affected by main software changes.

The 2024 Embedded Online Conference