Provisioning/inserting serial number post-production.

[SeanHowsonTB]

Hi Folks,

Using SDK17.1.0 & S140

Currently developing firmware for a product that needs a serial number. I could happily use the random number in the FICR regs. This would fit my needs just fine.

This would mean 1 firmware image would be uploaded to the product and it would be ready to sell. Simple. Cheap. Easy.

But there is a concern amoung a couple of my colleagues that this leaves us vulnerable to counterfeighting etc. while we would never knowingly use an untrustworthy partner, apparently  manufacturing partners have in the past been known to do such things.

A safety mechanism for this, would be to have some way of inserting (via debug port) a non-volatile serial number at a second geographical location. it is likely we will have a second location for final test/boxing/some-assembly. Without a valid serial number, the product will not be compatible with it's mobile application.

My quesiton is:

What would be a simple way to store around ~128bits of data that the firmware could easily read. Ideally i want to just run a small program on a windows PC to replace these few bits of memory with a valid serial number.

Ideally such a memory location should not need special treatment during a DFU (this would invoke more work!).

I think someone previously recommended the FICR regs, or what about the UICR regs? Are these more appropriate? Where are these each ACTUALLY stored on the NRF52840, exactly? Hex address? - Struggling to find a reference to this!

This is a fairly small peice of work so ideally i'd like to avoid learning to use an entire flash library for the sake of reading a mere 128bits.

If you have any other suggested location, feel free to share? I'm looking for some small location, tucked away, intended for this sort of use. Ideally NOT the start of a 128KB page of flash that i may later want to use for much bigger things! :)

Open to suggestions, emphasis on quick, & simple, minimal work...

Thanks

Sean

[Frank Viganske]

Hi Sean,

the UICR registers CUSTOMER[0..31] can be used for storing customer data. You can read them easily from software, like any other register, so you will not need a special library for this. See link: https://infocenter.nordicsemi.com/topic/ps_nrf52840/uicr.html?cp=4_0_0_3_4

The FICR are not writable, so you can't use these.

I'm not sure if the UICR area needs any special treatment during DFU, maybe someone else can answer that.

Another thing you should know about the UICR: these can only be programmed once from within your application. If you want to reprogram them, you need to do a complete chip erase. So for your application they behave like OTP memory.

Best regards

Frank

[Kenneth]

If you have the capability to insert data over debug port at a second location, you may just consider programming the entire firmware at that location, and let the factory only have firmware to perform production test. I would like to add that there are several unique registers in FICR that may be helpful here, for instance if you combine DEVICEID[0-1] and DEVICEADDR[0-1] you will have a 64+48 bit unique number, not sure if you really need the entire 128-bit, there are quite a lot of combinations already at 48-bit. The values in FICR cannot be changed by any means, so if you did read out the FICR values during production and stored them somewhere central location, you would have full control over which have been programmed by you and not later.

In terms of how UICR work I can see Frank already have summarized it well.

Best regards,
Kenneth

[SeanHowsonTB]

Thank you both for a pair a of great answers,

options such as letting factory number 1 only have a peice of test firmware are very much on the table, it's quite possible this may be the route i will go down.

As (upon further thinking), i've realised, that without deeper security measures in place, simply having a valid SN, doesn't stop a malicious party from theoretically, buying a unit and copying it's serial number, until we picked up on the fact the same serial number had been registered all over the globe, the presence of a serial number would provide no security against counterfeighting at all.... of course there are numerious ways around all of the above, they all just incurr lots of work... Hence a simple solution like the test FW solution may prove valid.

I think the only question that remains for me is around DFU's. If for example i use the DEVICEADDR regs (which i actually already do), to generate a serial number, and for the sake of this discussion, i copy it to UICR.

I then perform a DFU

Kenneth, do you happen to know if both the UICR & FICR copies will be retained?

Thanks,

Sean

[Kenneth]

SeanHowsonTB said:

Kenneth, do you happen to know if both the UICR & FICR copies will be retained?

Yes for DFU (,though I don't undersand why you would want to copy data FICR->UICR, since you can always read data from FICR internally in any case).

Kenneth

[SeanHowsonTB]

I wouldn't, it was a poorly thought through way of asking if both memory areas would be retained.  Hence the "for the sake of this discussion" comment.

Should have just asked the same question twice, once for UICR and again, for FICR.

Thanks again,

Sean