sd_softdevice_enable does not return

[wouchida]

On one of our products, we are experiencing approximately 4% failures during production.  I traced the problem to be caused by function sd_softdevice_enable not returning.  This problem does not occur if I have a Segger JTAG probe connected or if the internal LF 32 KHz RC oscillator is used instead of the external crystal.  But with the external 32 KHz (20 ppm) crystal oscillator, about 4% of boards do not return from the sd_softdevice_enable function.  On the problem boards, our hardware engineers believe that this LF external oscillator is starting up normally.  They do not observe any startup differences between a good board or a bad board.  I would like to know the reasons why the function sd_softdevice_enable might not return.

[Kenneth]

Hi,

The only 'wait state' in the softdevice enable is the wait for the lfclk started event. So likely the external crystal do not start as expected.

Best regards,
Kenneth

[eiadj]

Hi Kenneth,

We've looked at a number of units - some working, some non-working - and the 32kHz crystal starts-up identically in both scenarios (see attached screenshots). We've also verified that the parameters of the oscillator operation are accurate (frequency, amplitude, offset).

Furthermore, swapping the crystal and capacitors does NOT cause a defective board to start functioning and moving the crystal+caps from a defective board to a good board doesn't affect functionality.

What would be the next things to look at that could be causing a malfunction of the softdevice_enable function?

Best,

Eiad Jandali

Hardware Engineer

XTAL start-up on a functioning board

XTAL start-up on a non-functioning board

[Hung Bui]

Hi Eiad, 

 

Kenneth is on vacation so I will try to help. 

As far as I know, your 4% error rate is in the ballpark of with what we observed. We recommend to implement the errata fix in all of your product.

Of the "working product" you have now, if it's working properly it doesn't mean that the chip doesn't have the issue, but it's possible that the corrupted memory is at a location that it doesn't affect the current normal operation of the device , at this moment. It can be guaranted that it will always works fine in the future. 

[wouchida]

Questions:
1. I assume that for errata 108, the following code segments from a later SDK can be used. Is this correct?

2. Currently, we are using nRF52832 chip, revision Rev 1 (QFAA-B00) and will be eventually transitioning to Rev 2 (QFAA-E00).  Will the below fix and the errata fixes for SDK_11 still work for the Rev 2 hardware?  In other words, will the hardware version check still be satisfied for to Rev 2 hardware?

/* Workaround for Errata 108 "RAM: RAM content cannot be trusted upon waking up from System ON Idle or System OFF mode" found at the Errata document for your device located at infocenter.nordicsemi.com/ */
if (errata_108()){
        *(volatile uint32_t *)0x40000EE4 = *(volatile uint32_t *)0x10000258 & 0x0000004F;
}

static bool errata_108(void)
{
    if ((((*(uint32_t *)0xF0000FE0) & 0x000000FF) == 0x6) && (((*(uint32_t *)0xF0000FE4) & 0x0000000F) == 0x0)){
        if (((*(uint32_t *)0xF0000FE8) & 0x000000F0) == 0x30){
            return true;
        }
        if (((*(uint32_t *)0xF0000FE8) & 0x000000F0) == 0x40){
            return true;
        }
        if (((*(uint32_t *)0xF0000FE8) & 0x000000F0) == 0x50){
            return true;
        }
    }

    return false;
}

Thanks,

Wayne

[Hung Bui]

Hi Wayne, 

Yes, it's the correct workaround. 

The errata is remained on Rev2 and the above code can be used for Rev 2 as well. 

 

 

[knowic]

Hi, sir,

Have you get the problem solved? We have meet the similar problem and try to find the reason

Thanks,

Jason Hu

[Hung Bui]

Hi Jason, 

The errata is still valid for rev 2 chip. The workaround is as described here. 

It's already implemented in our current SDK.