No way to determine device type uniquely from provided ID codes

Posted on May 17, 2011 at 13:25

They probably share a common die and bond out differently. Or only test the feature subset you are paying for.

The STM32 parts I'm using have the RAM size in the WORD at 0x1FFFF7E2 wasn't aware they stopped doing that, they also have a 96-bit unique code at 0x1FFFF7E8..7F3. Perhaps you can get a secret decoder ring from ST to associate this, or fields within in it, with a specific part.

The System ROM appears to be flash memory, you could checksum or CRC 0x1FFFF000..7DF although there doesn't appear to be anything part specific in there. It could perhaps identify chips which are different or have broken boot loaders.

Having a complete unique machine readable part and stepping identifier which matches the human readable etching on the chip would certainly be a good thing. There is no doubt about that. Idiot proofing the programming process is also good, but they can be very cunning.

I think however you are over dramatizing or skipping some inspection or oversight steps.

This wouldn't be the first time in history that the same silicon die has been packaged and sold with different packaging/pinout/function/marking and binned at different speeds. Heck some of the vendors you name have shipped parts that are second sourced, die shrunk, or otherwise not identical but share a common electronic ID for decades too. Programming houses would be acutely aware of this, and could address it with a cursory amount of due diligence. If you can program and place 5K of the wrong part you need to get better incoming inspection people that can read the part numbers on the reel and confirm the parts on the reel have the same number, ditto for the people loading the pick-n-place machine and overseeing the process.

-Clive

Posted on May 17, 2011 at 13:25

Hello,

We've been planning to start production on our new product using the STM32 shortly. However, we just hit a very huge snag.

We have an external programming house burn our firmware into the micro, and then buy the 5k reels with the firmware already programmed for placement on our boards.

It is imperative that the burning program (in our case, we use BPMMicro) be able to accurately ID the device, to ensure that we don't end up burning 5K of the wrong part.

However, there currently appears to be absolutely no way to distinguish the device using any of the embedded ID codes.

The socket only fits one pin-count, so at least we can easily verify whether it is 48-pin, 64-pin, etc.

The DEV_ID only tells you high/med/low density. We are using a medium density, but there are six medium density devices in the 48-pin package (could increase if they release the connectivity or low-power in that package).

The Flash size register will make sure you don't burn off the end of flash memory. However, it is still insufficient to identify the device, because the F101, F102, F103, and F105 all come in the same flash size for the same pin package.

There is absolutely no way to determine whether a chip currently in the burning socket is an F101, F102, F103, or F105.

From reading the forum, there apparently used to be plans for a RAM size register at 0x1FFFF7E2. However, it appears that ST has cancelled that idea. And even if it was present, it still only narrows it down to two, because the F101 and F102 share the same RAM size, and the F103 and F105 share the same ram size.

This is bad. Every other micro on the planet includes a way to verify that you have the correct chip in the socket before you burn firmware into it. Atmel does it, NXP does it, TI does it, Microchip does it, Freescale does it, etc.

The results could be catastrophic if the programming house somehow manages to burn 5k of the wrong chip and we don't catch it until the boards are populated.

There are still 6 unused bytes from 0x1FFFF7E2 to 0x1FFFF7E7. I think it's imperative that ST release a new rev of the chip ASAP that includes the RAM size byte as well as an F10X ID into those remaining device signature bytes.

Isn't that just the system memory ROM space anyway? Can't ST burn it in somehow?

Thanks,

Ash.

Posted on May 17, 2011 at 13:25

According to the revision history of the STM32 Reference Manual (RM0008), the RAM size register paragraph was removed in revision 6 (September 2008). There is no explanation as the change description says:

Quote:

“RAM size register� section removed from Section 28: Device electronic

signature on page 949.