PCB ID Hardware or Firmware ?

Go To Last Post
47 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

 

 

 

 

 

 

 

 

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Wed. Oct 28, 2020 - 09:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

djoshi wrote:
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.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


This should cover you for all your PCB variants and more:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For 5 choices you could use an ADC input and a voltage divider, so change 2 resistors for each PCB type.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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)

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Oct 29, 2020 - 03:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Thu. Oct 29, 2020 - 05:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

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.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

Last Edited: Thu. Oct 29, 2020 - 07:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

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.

/Jakob Selbing

Last Edited: Thu. Oct 29, 2020 - 07:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:

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?  wink  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

 

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 ?

  1. Is it purely to distinguish between the 5 different variants of board?
     
  2. Is it to give a unique "serial number" to each individual product?
     

These are really 2 different things!

 

  1. Will not give you a "serial number"
     
  2. Will not help to distinguish the different PCB variants.

 

 

EDIT

 

I guess one way to give you both would be to use one of the 1-Wire EEPROMs; then:

 

  1. is answered by what you program into the EEPROM;
  2. is provided by the EEPROM's unique ID.

 

You could pre-program the EEPROMs, and your BoM would call up the appropriate pre-programmed chip according to the board variant being built.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Thu. Oct 29, 2020 - 08:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

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:

 

https://www.maximintegrated.com/en/products/DS2411

 

I get a buck-ish at Digikey.  Jameco has the 18B20 temp sensors for $2.75.

 

awneil wrote:

But, as  jaksel said, the questions is: what is the purpose of this ID ?

  1. Is it purely to distinguish between the 5 different variants of board?
     
  2. Is it to give a unique "serial number" to each individual product?
     

These are really 2 different things!

 

  1. Will not give you a "serial number"
     
  2. Will not help to distinguish the different PCB variants.

 

Which is why I added:

Quote:

And it would be then up to you to keep track of which SN was built with which hardware.  S.

 

S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It will be only one board at a time present .

 

Do not have any ADC pin available and maybe just 1-2 GPIOs 

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meslomp wrote:

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. 

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:

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?

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaksel wrote:

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

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

djoshi wrote:

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?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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" ?

 

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

djoshi wrote:

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

djoshi wrote:

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...

/Jakob Selbing

Last Edited: Thu. Oct 29, 2020 - 11:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaksel wrote:
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.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaksel wrote:
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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaksel wrote:

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:
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

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Thu. Oct 29, 2020 - 12:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
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!

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:
I get a buck-ish at Digikey.
Approximately that for a crypto-authenticator :

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]

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:
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

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
Is it not possible to auto detect what variant the PCB is by looking to see what else is fitted?
Possible

PCBA manufacturers of old had optical comparators; today, that's likely by ML so data flow is automated.

ML - Machine Learning

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:
(how many bytes do you want for your SN?)
GUID would work though that may be too much.

16 bits isn't enough (the annoyance of USB VID and PID)

4 bytes?

If AVR GCC then 3 bytes.

 

P.S.

Scroungre wrote:
Preview next time?
It's handy ... becoming a habit .. if I remember smiley

 


Online GUID Generator

Types | avr-gcc - GCC Wiki

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

gchapman wrote:

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?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:
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

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I seem to remember that for the SAM D20/21 ...

 

frown

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:
the MCU need never know

Ah - I see what you're getting at.

 

From the OP, I was inferring that the MCU did need to know - but, as you say, that ain't necessarily so.

 

Maybe  djoshi will eventually clarify these things ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Last Edited: Fri. Oct 30, 2020 - 07:14 AM