Hi All
Just wanted to know what is the general preference when you want to give a PCB a unique ID.
I have about 5 slightly different PCBs(variation in components and functions), but the firmware project is the same.
I am going to be adding some new PCBs , is it better to program the ID using eeprom , but with the risk if it was to get corrupted or have hardware id using a simple IC such as TCA9534A or something similar?
I have much the same "problem" and will use the 9534 to give each board an ID code. In my case, it will be a variety of serial I/O boards (RS232, RS422, USB, etc). There will also be a variety of power boards (solar, 12V, higher voltage ac/dc, etc) with the same treatment.
Jim
You can use some resistors (or solder jumps to a dac r2r chain) to generate different voltages (per board type) for the ADC--though I don't really recommend that. Better to lay out different traces (connect each to gnd or vcc as needed) to the chip I/O pins as an ID...if a pin shortage, use an expander, but that is not an absolute requirement. You can take a few output(s) and pull low/high with resistors to set a pattern...then momentarily set as inputs to read them at powerup. But again, that requires the correct components installed---a failure or messup makes the board look like a different type...maybe an issue, maybe not. Is one PCB layout going to have potentially multiple identities?--something to consider. Factory ID set in the EEPROM is easy & effective (as long as it gets set properly.
Is it a big disaster if the board is misidentified (say the same board is used as a pizza oven controller or a SMD reflow oven controller)? That might guide your tradeoffs. You may have somewhat similar thoughts for serial numbers, but then you don't need to consider they type of board. Instead you consider how tough/secure you want to to make changing the serial number.
We kept 3 pins "spare" to tie high/low, as input to show board rev (0 to 7) level (but we had 44 or 64 pins).
Some teks scopes let you change the models to a much more $$$ model by moving around some resistors (and fiddling with some BW caps)
These board ID resistors (R1061<->R1064), with which the model can be set, are near these EEPROMs as well. Soldered is 0.
TDS784A: 7, 0 1 1 1
TDS754A: 8, 1 0 0 0
TDS744A: 6, 0 1 1 0
I've found it convenient where I have spare processor pins to use solder bridges to enable a binary input to define the board number. Bonus prize is that the number isn't defined until after basic testing is complete and I'm up to a production version - at which point I can hardwire the input on the PCB - but prior to that I have some convenient pins to which I can attach scope or logic probes for debugging.
It's not a power drain either: only when it is required to read the value need the input include a pull-up or -down; the rest of the time it can be hi-z with no (well, absolutely minimal) power consumption.
Neil
I have about 5 slightly different PCBs(
For just 5 variants, 3 pins that can be tied high or low would be sufficient.
If you want to be a bit more clever, you could distinguish high, low, and open.
This should cover you for all your PCB variants and more:
A lot depends on whether or not these boards have micros on them and whether or not the host system has at least 3 available GPIO pins available. Also depends a lot whether or not there is a serial bus already routed to these boards.
If you use something like the 9534, you need to pay attention to whether or not there can be more than one such board resident in the system at any given time. The issue is that all of the 9534s will respond to the one unique address that is shared by all. In my case, I have a "board select" line to every board slot so I can disable all but the one that I want to query. But, if it is only one board at a time, the 9534 is easy.
Jim
For 5 choices you could use an ADC input and a voltage divider, so change 2 resistors for each PCB type.
I was thinking they could get a short R2R ladder (they sell some such arrays, at least in through-hole), then solder-jumper a binary code.
One question is do they want the ID to be hard-coded to the fab (such as etching traces), or factory alterable. There is some advantage of making it perm with the fab revision.
not 100% sure the fab layout is the same or different (sounds like it probably is the same fab with option parts installed).
I have about 5 slightly different PCBs(variation in components and functions)
We still do not know if only one board is present at any time or if two or more can be simultaneously present.
Likewise, we don't know if the ADC is available or if any GPIO pins are available in the MCU.
Jim
I have about 5 slightly different PCBs(variation in components and functions), but the firmware project is the same.
In that case you already have different BOM files. thus I would say make the hardware unique.
You can do it multiple ways as already described above all depending on the number of IO available and type of IO available
- use ADC ( that can give you a lot of variants with just 2 resistors and one ADC IO line)
- use GPIO lines gives powers of 2 per available IO line, so dependent on the number of varaints needed to be identified you might need quit a lot of IO lines
- use the internal EEPROM to store a ID, if processor has EEPROM and if there is space left in it for this to be done, and you make sure that value is never changed again.
- use a flash page to store the parameters after programming, that gives the need for a second "programming step". Then you need to be careful when updating in the field.
- use an external eeprom on an available bus. might need extra IO for sure an extra programming step.
Is it not possible to auto detect what variant the PCB is by looking to see what else is fitted?
Plus, as hinted above, if using IO pins to set a type, getting three values out of each pin is trivial. There is a Design Note in the tutorial section about this. Trinary Coding.
I was idly plinking at a Python script that would, as part of the AVR programming sequence, deliberately park a unique serial number (SN) somewhere in the Flash - by importing the hex file, tweaking just those bytes as per an external file, then programming the chip.
That might not work so well with a bootloader. Has the advantage of not needing any external hardware, deals with a pratically-infinite number of boards (how many bytes do you want for your SN?) and can be easily read out by the chip itself.
And it would be then up to you to keep track of which SN was built with which hardware. S.
PS - A sillier way would be to buy something like a Dallas 18B20 1-wire temp sensor, and install it on the board. They come from the factory with guaranteed unique 64-bit serial numbers... Then just query the temp sensor for what its ID is, and write that down instead... Unique and unchangeable. S.
Edit: Typo. Preview next time?
Just wanted to know what is the general preference when you want to give a PCB a unique ID.
I have about 5 slightly different PCBs(variation in components and functions), but the firmware project is the same.
May I ask what is the purpose of the unique ID? Is it only to distinguish between these 5 PCBs or do you really need to identify exactly which production PCB that the firmware runs on? Must the firmware allow for changes of the unique ID without the firmware being changed?
If the purpose is only to allow firmware to run on different PCBs then I would say it is far easier to simply define the target PCB during compile-time (e.g. using pre-processor symbols). Hence you use different firmware binaries for different PCBs. The firmware always "knows" which PCB it is intended to run on. This is how I solved it in my current project.
Unique and unchangeable. S.
Quoting myself, poor style, I know, but a few more things spring to mind.
Ask them nicely, you'll also get the temperature! Bit pricey, though - $5 a pop. Maybe there's cheaper 1-Wire gizmos out there. Or cheaper vendors than Digikey.
Furthermore, you can encode the temperature sensor's SN into the firmware somewhere on initial power-up during testing, and if anyone tries to copy your board and rip off your firmware, it'll come with a different sensor and the SNs will be different, so the chip can scream "I'm being hacked!" and start erasing itself. Would a would-be copier think to go to huge lengths to copy an innocent temperature sensor? 
S.
Maybe there's cheaper 1-Wire gizmos out there.
Dunno how prices compare, but they certainly make a 1-Wire gizmo which is purely a serial number:
https://www.maximintegrated.com/en/products/DS2411
https://www.maximintegrated.com/en/products/DS2401
Other manufacturers have similar products.
Many microcontrollers (and other digital parts) have a "unique ID" these days.
But, as jaksel said, the questions is: what is the purpose of this ID ?
These are really 2 different things!
EDIT
I guess one way to give you both would be to use one of the 1-Wire EEPROMs; then:
You could pre-program the EEPROMs, and your BoM would call up the appropriate pre-programmed chip according to the board variant being built.
Scroungre wrote:
Maybe there's cheaper 1-Wire gizmos out there.
Dunno how prices compare, but they certainly make a 1-Wire gizmo which is purely a serial number:
I get a buck-ish at Digikey. Jameco has the 18B20 temp sensors for $2.75.
But, as jaksel said, the questions is: what is the purpose of this ID ?
- Is it purely to distinguish between the 5 different variants of board?
- Is it to give a unique "serial number" to each individual product?
These are really 2 different things!
- Will not give you a "serial number"
- Will not help to distinguish the different PCB variants.
Which is why I added:
And it would be then up to you to keep track of which SN was built with which hardware. S.
S.
It will be only one board at a time present .
Do not have any ADC pin available and maybe just 1-2 GPIOs
djoshi wrote:
I have about 5 slightly different PCBs(variation in components and functions), but the firmware project is the same.
In that case you already have different BOM files. thus I would say make the hardware unique.
You can do it multiple ways as already described above all depending on the number of IO available and type of IO available
- use ADC ( that can give you a lot of variants with just 2 resistors and one ADC IO line)
- use GPIO lines gives powers of 2 per available IO line, so dependent on the number of varaints needed to be identified you might need quit a lot of IO lines
- use the internal EEPROM to store a ID, if processor has EEPROM and if there is space left in it for this to be done, and you make sure that value is never changed again.
- use a flash page to store the parameters after programming, that gives the need for a second "programming step". Then you need to be careful when updating in the field.
- use an external eeprom on an available bus. might need extra IO for sure an extra programming step.
Yes, small change in BOM, where certain components are not soldered.
Thanks for all the suggestions.
I was idly plinking at a Python script that would, as part of the AVR programming sequence, deliberately park a unique serial number (SN) somewhere in the Flash - by importing the hex file, tweaking just those bytes as per an external file, then programming the chip.
That might not work so well with a bootloader. Has the advantage of not needing any external hardware, deals with a pratically-infinite number of boards (how many bytes do you want for your SN?) and can be easily read out by the chip itself.
And it would be then up to you to keep track of which SN was built with which hardware. S.
PS - A sillier way would be to buy something like a Dallas 18B20 1-wire temp sensor, and install it on the board. They come from the factory with guaranteed unique 64-bit serial numbers... Then just query the temp sensor for what its ID is, and write that down instead... Unique and unchangeable. S.
Edit: Typo. Preview next time?
Wouldn't that mean, if board would have a unique id. I am looking for more of a board type id?
djoshi wrote:Just wanted to know what is the general preference when you want to give a PCB a unique ID.
I have about 5 slightly different PCBs(variation in components and functions), but the firmware project is the same.
May I ask what is the purpose of the unique ID? Is it only to distinguish between these 5 PCBs or do you really need to identify exactly which production PCB that the firmware runs on? Must the firmware allow for changes of the unique ID without the firmware being changed?
If the purpose is only to allow firmware to run on different PCBs then I would say it is far easier to simply define the target PCB during compile-time (e.g. using pre-processor symbols). Hence you use different firmware binaries for different PCBs. The firmware always "knows" which PCB it is intended to run on. This is how I solved it in my current project.
The aim to keep one firmware is so that when i make any update to my core application, it is identical to for all pcb types
Yes, small change in BOM, where certain components are not soldered.
So is it not possible for your firmware to simply detect if one or more of those components are fitted?
That doesn't fully answer the question.
See also #16 - is the purpose purely to distinguish between the 5 different variants of board, or do you also want each board to have a unique "serial number" ?
Scroungre wrote:
And it would be then up to you to keep track of which SN was built with which hardware. S.
Wouldn't that mean, if board would have a unique id. I am looking for more of a board type id?
Yes. That's exactly what it means. For 'board type id' you have somewhere a list of serial numbers, and beside each serial number is a note on 'what board type' that particular board is. S.
jaksel wrote:May I ask what is the purpose of the unique ID? Is it only to distinguish between these 5 PCBs or do you really need to identify exactly which production PCB that the firmware runs on? Must the firmware allow for changes of the unique ID without the firmware being changed?
If the purpose is only to allow firmware to run on different PCBs then I would say it is far easier to simply define the target PCB during compile-time (e.g. using pre-processor symbols). Hence you use different firmware binaries for different PCBs. The firmware always "knows" which PCB it is intended to run on. This is how I solved it in my current project.
The aim to keep one firmware is so that when i make any update to my core application, it is identical to for all pcb types
Do you mean that the binary must be identical or do you mean that the source code is identical? Those are very different!
If you mean that the source code is identical, then the best solution IMHO is probably to define the PCB type at compile-time and keep different binaries for different boards. After all, when you program your firmware into a PCB, you know what type that PCB is right? If it will never change, there's no point in having run-time checks in the firmware.
Having an identical binary OTOH is a different question...
If you mean that the source code is identical, then the best solution IMHO is probably to define the PCB type at compile-time and keep different binaries for different boards.
Should be easily doable in Atmel Studio by having multiple Projects in the Solution - you can build all the Projects with one click ...
Other IDEs have equivalent features and, of course, a makefile can do it.
After all, when you program your firmware into a PCB, you know what type that PCB is right?
If you're producing five different versions of your product, you should always know which binary goes to which PCB. But people make mistakes. If a simple runtime check on first boot can determine the PCB variant then there is one less source for errors. And the first boot will probably be a production test of some kind so you can catch the mistake quickly.
Especially if the difference is only that some optional feature is not populated on this PCB, it is easy to add the check into the firmware and produce a binary that skips everything related to that feature if the PCB doesn't have it.
Do you mean that the binary must be identical or do you mean that the source code is identical? Those are very different!
This being, of course, what my little Python script was supposed to do - monkey around with the binary without changing the source. As awneil pointed out, a makefile could do the same thing with a little clever inclusion of a mechanically-generated file. S.
a makefile could do the same thing with a little clever inclusion of a mechanically-generated file. S.
Indeed. And Atmel Studio (like other IDEs) has the facility to run external tools before and/or after a build ...
Also, as we seem to be talking about manufacturing/production, a decent production programmer should be able to "serialise" the binary as it programs the chips ...
EDIT
fix quote
Perhaps a basic (cheap) PCB, don't know ID, and with things added there is a way to find out if they are there, like an output pin can be read low or high depending if the part.
Many I2C parts have an ID that can be read.
We don't know the differences but perhaps it's all in all is cheaper to have everything on all boards
an output pin can be read low or high
Or even as "not connected" - as previously mentioned
perhaps it's all in all is cheaper to have everything on all boards
It can be - by the time you factor-in all the management issues!
There is a Design Note in the tutorial section about this. Trinary Coding
https://www.avrfreaks.net/forum/avrfreaks-design-notes
Specifically: https://www.avrfreaks.net/commen...
We don't know the differences but perhaps it's all in all is cheaper to have everything on all boards
Ala IBM in the 'good old days', when enabling an extra-cost accessory or expansion device merely meant the installation or removal of a jumper.
That still remains a perfectly valid method of board differentiation - install everything, then selectively enable with little hardware jumper blocks. This also improves maintenance - when a device is shipped back for repair, you don't have to have one of that specific configuration to replace it with - you just put in the ordinary one and set the jumpers to match. S.
I get a buck-ish at Digikey.
https://www.microchipdirect.com/product/search/all/ATECC608B
Using a Cryptographic IC for Key Management and Logistical Support (Atmel)
[page 4]
Integrating product line management
[third paragraph]
[memory zones : 1. customer secret, 2. manufacturer secret, 3. make, 4. model]
install everything, then selectively enable with little hardware jumper blocks.
Or, these days, enable with a software "key" ...
For that, you probably do want a unique serial number for each board
Is it not possible to auto detect what variant the PCB is by looking to see what else is fitted?
PCBA manufacturers of old had optical comparators; today, that's likely by ML so data flow is automated.
ML - Machine Learning
Brian Fairchild wrote:Is it not possible to auto detect what variant the PCB is by looking to see what else is fitted?Possible
I was thinking more along the lines of if a chip is not fitted can the firmware see if registers can be written and read back? If some circuitry is not fitted can the pin which normally drives it be wiggled to see if it's there or not?
Leads to a somewhat interesting question: Does the microcontroller (MCU) even need to know what kind of board it is put in? Given identical firmware, how would the MCU know? Does the MCU have to report what kind of board it is plugged into? S.
Does the microcontroller (MCU) even need to know what kind of board it is put in?
OP said there are ~ 5 variants, with "different functions"
I guess the MCU shouldn't attempt to do "functions" that rely on things not present. And shouldn't wait for inputs from parts that aren't there.
Given identical firmware, how would the MCU know?
It would check: either as Brian said looking for presence/absence of functional signals, or just looking at DIP switches / jumpers / links / some sort of "config" memory
Does the MCU have to report what kind of board it is plugged into?
It probably should - so verify that the detection is working, if nothing else
Maybe. But if they're independent analog circuits that really don't care what the MCU thinks, then the MCU need never know. Look at post #2 where it's just communications and power supply. The MCU really doesn't have to care about them - part of the point of making the whole shebang modular is that it doesn't have to care. S.
Heh. A recent Arm project used the vendor's defined unique device ID bit as part of the encryption for networking command and control. Unfortunately the chap that wrote the code failed to observe that the bit in question weren't, as they at first glance appeared, in contiguous order...
Neil
We're not trying to hide nuclear secrets from the Russians here. Encryption is very easy to do wrong, and very difficult to do right. By 'ID bit' and 'the bit' I presume you mean 'ID Bit String', because one bit wouldn't have a whole lot of entropy... S.
I seem to remember that for the SAM D20/21 ...
@Scroungre - 'bits' of course; my typo. Or rather bytes: on that particular ARM it's a string of about a dozen characters, but they're not in contiguous addresses in the memory space. So my colleague ended up with thousands of devices all with the same ID, which had the potential rather to upset their communications with the servers. Fixable by an OTA firmware update, once we'd worked out what the issue was.
Neil
Just make a different firmware for each variant. You obviously want to identify each differently. Hard code a variable in the firmware. Use a compile define, then your code can be identical, and you can have a different compile script for each variant. Simplistic solution without additional hardware.
