Mapping HWID to revision information

[pabigot]

This thread provides some references for those of us who need to have firmware that runs on multiple releases, but don't necessarily know what revisions are in the field. Unfortunately, the new release 2.0 of nWP-21 removes all the tables with HWID to build code, tested versions, and other useful information.

Will that material be re-appearing in a new white paper, preferably with more complete information? Please?

[Stefan Birnir Sverrisson]

Hi

For nRF51 SDK 8.1.0 there is a new function

void nrf_ic_info_get(nrf_ic_info_t* p_ic_info)  

that can be called from your application which returns information about chip revision, RAM size and ROM size. More information in \SDK v8.1.0\components\libraries\ic_info\nrf_ic_info.h

Update 11.6.2015 The above function should work for all nRF51 revisions, i.e. revisions 1, 2 and 3. I have tested it with several SDK versions:

• nRF51 SDK 8.1.0 (compatible with nRF51 rev 3): Works
• nRF51 SDK 6.1.0 (compatible with nRF51 rev 2 and rev 3): Works
• nRF51 SDK 5.2.0 (compatible with nRF51 rev 2): Works
• nRF51 SDK 4.4.2 (compatible with nRF51 rev 1 and rev 2): Works if you replace "SIZERAMBLOCKS" with "SIZERAMBLOCK[0]" in line 22 in nrf51_ic_info.c

To check the IC revision, RAM size and Flash size, copy the nrf51_ic_info.h and nrf51_ic_info.c files from SDK 8.1.0 into the SDK that you are using and call the function mentioned above.

Update 25.5.2016 HWID/FWID list may be described on this thread.

[pabigot]

I'm one of those who use the SDK only as a way to get nrf51.h and nrf51_bitfields.h. The only thing this API provides that wasn't already available in the FICR is a way to get the IC revision (1, 2, or 3). Because the Series Compatibility Matrix v2.1 only lists SDK 8.1 as compatible with rev 3 chips and the Private Peripheral Bus region is not documented I have no reason to believe reading bits 3..7 of 0xF0000FE8 is a guaranteed way to identify rev 1 or 2 ICs.

Also, ic_revision isn't detailed enough. The product anomalies are still coupled to package+variant+build within a revision. If we have code that determines the need for a PAN workaround at runtime, we need identification at that level of detail. HWID is the only (partially) documented solution available across the lifespan of the product. We really need a table that's kept up to date.

[Stefan Birnir Sverrisson]

Thank you for your valuable feedback pabigot. I have updated my answer to address the first part of your concern.

[Stefan Birnir Sverrisson]

@pabigot: Can you point to a specific anomaly that is dependent on package+variant+build within a revision.

[pabigot]

Most of them? nRF51822-PAN-v2.4, example #17: RADIO END to START connection using PPI or short is not functional applies to nRF51822-QFAA-C0 not to nRF51822-QFAA-G0. In the rev 3 PANs 69 and 71 apply to QFAA but not QFAC.

Unless I misunderstand what those tables are saying.

(Thanks for confirming the code can be used independent of chip; it'd still be nice to have it backed up in documentation; it makes me curious where the other bits of that word carry information I could use.)

[pabigot]

Even if there is a way to figure out revision, there is still existing code that uses HWID as a table index, for which lack of information is a problem. I had to push a patch to OpenOCD to recognize the QFACA1 chip that's used in the nRF51-DK/Dongle/Beacon since its HWID wasn't in the list of recognized devices. It could be that OpenOCD could use a different way of identifying what the target is, but I wouldn't want to move that way. We really do need that mapping.