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.