Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Hardware Version Mapping to Board Revision? #21

Open
phillipjohnston opened this issue May 12, 2022 · 2 comments
Open

Question: Hardware Version Mapping to Board Revision? #21

phillipjohnston opened this issue May 12, 2022 · 2 comments

Comments

@phillipjohnston
Copy link

Regarding hardware versions:

a major number for major layout and schematic changes such as changes to board dimensions, components placement or general functionality and
a minor number for minor layout and schematic changes such as component value changes, layout routing, copper fills, etc.

Does your team encode a hardware revision on the PCB that is readable by software?

  • If so, would this board revision map to the major number? Or would you need a mapping of some kind (e.g., PCB readable version 2 == Layout/Schematic version 2.3)
  • If not, this is definitely a useful practice!
@MarkoSagadin
Copy link
Collaborator

Does your team encode a hardware revision on the PCB that is readable by software?

So we have done the trick with the GPIO versioning in the past, I don't remember if we ever did the ADC versioning.

What we have found that works well is burning in the hardware version directly into the microcontroller. Nordic chips have UICRs - User information configuration registers.
It this just an extra command per register that has to be done by the JLink progammer during factory flashing time.

In this case we would use two 32-bit registers for two numbers (overkill, but there are many UICRs available).

My experience with other microcontrollers is limited in this area, do you know if for example STM32s, TIs and others support something similar?

I see this as a better alternative than GPIO and ADC versioning, you save on the BOM, plus sometimes you do not have pins to spare.

@phillipjohnston
Copy link
Author

In this case we would use two 32-bit registers for two numbers (overkill, but there are many UICRs available).

This makes sense and is a good idea. We have extended this in the past to flashing a whole "personality" structure, encoding hardware version, region, date/lot, and other values that are related to mfg.

My experience with other microcontrollers is limited in this area, do you know if for example STM32s, TIs and others support something similar?

I think this is an increasingly common processor option, though size varies widely. Sometimes we still use designs with an external EEPROM for such purposes, but increasingly we can use the processor's NVRAM.

Regarding specific vendors, I can't say for TI because it has been 10 years or so since I've used one of their processors. I have used ST processors that have "Backup RAM" which is persistent as long as you have battery power (similar to the RTC), but the lineup is so large that I cannot say it is present on every device. Apollo 3 processors also have this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants