This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Full mapping of HWID to Build code

Hello,

we are trying to avoid using code that triggers hardware issue #39 in the nrf51822, which appears to be fixed in chips whose build code is Hx0.

We would like to do that programmatically reading FICR->CONFIGID, field HWID. However, we are unable to find a complete mapping of the values to the build version.

The closest I got is:

  • whitepapers nWP-18 and nWP-21 list some of them, but explicitly state that the list is incomplete (e.g. only the value for H00 is given, not for H10, H20....)
  • nRFgo Studio translates the HWID to the build number, but AFAIK I have no access to its code, so I don't know how the magic happens.

Is there a full lookup table (or better yet, a simple translation algorithm) to get the build code from the HWID and vice versa?

Thanks in advance, Matteo

  • Hi

    Yes, you are correct, the first and second revision hardware of nRF51 has some current consumption issues with GPIOTE->IN (sensing signals from a GPIO pin) and GPIOTE->OUT (controlling GPIO pin, as nRF51822-PAN v2.4 anomaly #39 suggests. The third revision hardware has a solution for the GPIOTE->OUT tasks, but GPIOTE->IN is still high current. For input signal sensing on GPIO, use the GPIOTE->PORT event instead of GPIOTE->IN.

    Information on what nRF51 chips are third revision hardware, check out this thread. The third revision nRF51 hardware resides on the new nRF51 DK.

    For anomaly #39, perhaps this thread provides some furhter clues.

    Update 2.12.2014 Anomaly #39 is present for first and second revision of the nRF51 hardware but is fixed for third revision. You can see if a chip is third revision by simply reading the HWID field. For example, if you read HWID and see that it is 0x007B, then it is third revision (according to nWP-021 v1.0, table 1) and anomaly #39 is therefore fixed.

    Update 3.12.2014 I think my thick head has finally understood your concern after you pointed me to footnote #6. The response is that there is no complete mapping available between build codes and HWIDs. So you can check the zero values in the build code, e.g. HWID 0072 which maps to H00. If at a later point you discover you have in your production line H10 chips, then you must add the HWID for build code H10 into your check routine to recognize H10 chips as nRF51 revision 3 chips.

    Update 11.6.2015 See this thread on how to get the hardware revision, RAM and FLASH size programmatically

  • Hello Stefan,

    unfortunately, the thread you point to for third revision information, refers in turn to WP-21, which I checked already and which does not report the HWID for all builds (just a few of them, as stated in the original question).

    Table 1 in WP-21 has a note (note 6) which reads: "The x in the build code could be any digit 0..9. (HWID is given for x = 0, if X ≠ 0 the HWID will be different)."

    Could you please provide pointers to a complete table or to any other way to resolve an HWID to a Build code?

    Thanks in advance, Matteo

  • To clarify, this image is a screenshot of Table 1 from WP-21, the document you are referring to. It states explicitly that 0072 is not the only HWID for 3rd revision. For example, I have on my desk a few Gx0 chips whose HWID is not 003C. However, I need a reliable way to identify 3rd revision chips.

    My question is: what are the other ones?

  • If this information isn't available from Nordic (!), perhaps we can crowd-source it. In addition to the ones in the table I have HWID 0086 on a N51422 QFACA1 1439AA on a nRF51 DK, so that id should be third revision.

  • It is now possible to know the nrf51 hardware revision programmatically, see this thread

Related