nRF51822 QFAA H30 fails production test

[Jimmie Johansson]

Hi,

We have used nRF51822 QFAA H10 in our product for a long time but the latest order was fulfilled with H30-devices and now our production test fails.

The test step is verifying a speaker by producing a tone with PWM (Timer with CC, GPIOTE and PPI) and the new H30 devices don't sound correct (haven't received any faulty units yet). We have a workaround in code for PAN73:

static __INLINE void pan73_workaround_activate(uint8_t timer)
{
    // nRF51822 rev3 silicon (H0) needs workaround when using PPI with GPIOTE
    
    uint8_t rev = (NRF_FICR->CONFIGID & 0xF0) >> 4;
    if (rev == 7 || rev == 8 || rev == 9) {
        if (timer == 0) {
            *(uint32_t *)0x40008C0C = 1;
        } else if (timer == 1) {
            *(uint32_t *)0x40009C0C = 1;
        } else if (timer == 2) {
            *(uint32_t *)0x4000AC0C = 1;
        }
    }
}

Are there any changes in H30 compared to H10 that could cause issues? This is a legacy code base with SDK 4.4.2 and S110 5.2.1.

[Sigurd]

Hi,

Jimmie Johansson said:

Are there any changes in H30 compared to H10 that could cause issues?

No, there are no functional changes from H10 to H30 that could cause issues.

[Jimmie Johansson]

What is the CONFIGID for nrf51822 QFAA H30? Am I matching it correctly in the code?

[Sigurd]

Jimmie Johansson said:

What is the CONFIGID for nrf51822 QFAA H30? Am I matching it correctly in the code?

I think the HWID part of the CONFIGID is 0x0138 for the H30 variant and 0x008F for H10. So with your matching code, rev would be assigned the value 3, and the pan workaround would not be applied.

[Jimmie Johansson]

I'm trying to understand and I'm a bit stressed out since our production is stopped because of this.

The latest SDK 12.3.0 for the nRF51 has a file called nrf_ic_info.c that is supposed to be the official way to identify a chip revision (in order to apply the correct PANs). That file was written before the H30 came out, so it does not match it.

There is no way to find the HWID in the documentation, apart from the file nrf51deviceids.xml installed with nRF go studio, and it did not contain any information about H30 (or H20).

PCN 100 where H30 is introduced says that there are no consequences of the change.

And rutronik does not even list the production site, so we can only order Hx0 chips and get H00, H10, H20 or H30 delivered.

How can we be proactive in the future? What should I do when H40 shows up?

You write that you think that the new HWID is 0x0138. Can you verify this so I can make a new firmware for the factory?

[Sigurd]

Jimmie Johansson said:

The latest SDK 12.3.0 for the nRF51 has a file called nrf_ic_info.c that is supposed to be the official way to identify a chip revision

That is correct. But you are not using that function. In nrf_ic_info_get(), the ic_data is read like this,

uint32_t ic_data    = ((*((uint32_t volatile *)0xF0000FE8)) & 0x000000F0) >> 4;

But you are using the CONFIGID in FICR instead, looking at the HWID, that is not the same thing as ic_data in nrf_ic_info_get().

Jimmie Johansson said:

How can we be proactive in the future? What should I do when H40 shows up?

Use nrf_ic_info_get(), and the implementation it uses to find the IC revision. Don't use the HWID.

Jimmie Johansson said:

You write that you think that the new HWID is 0x0138. Can you verify this so I can make a new firmware for the factory?

I doubled checked our internal systems, and H30 is listed with HWID 0x0138. But again, use the original nrf_ic_info_get() function instead.

[Jimmie Johansson]

Thank you so much! I completely missed that detail. Was sure that the code I use was copied from nrf_ic_info.c.