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

[Kenneth]

Hi,

The crystal looks good. Were you able to do the manual test?

What SDK and SD are you using btw?

Best regards,
Kenneth

[wouchida]

Yes, I can start the oscillator manually.  See 3 paragraph above.  If I do this prior to calling sd_softdevice_enable, this function no longer hangs.

SDK: nRF5_SDK_11.0.0_89a8197

SD: s132_nrf52_2.0.0_softdevice

Also, I verified that the function sd_softdevice_enable is not returning while osc is running.  

[Kenneth]

Can you check if your system_nrf52 in your project contain workaround for errata_108()?

[wouchida]

No.

It only has the following:

errata_16
errata_31
errata_32
errata_36
errata_37
errata_57
errata_66

[Kenneth]

Then we might have found the issue!

You are missing a workaround for this issue (which may cause all kind of strange issues):
http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.Rev1.errata/anomaly_832_108.html?cp=2_1_1_1_1_33 

[wouchida]

Hi Kenneth,

This solves the problem on the problems board that I have.  We need to test this on a larger population of bad boards.  I want to get a better understanding of what is happening.  I assume that the function sd_softdevice_enable is putting the processor into a sleep mode waiting for the external LF oscillator to start up and when the processor wakes up, memory might be corrupted, so the function might not be able to return.  In the same line of reasoning, if the external LF oscillator is started prior to the call to sd_softdevice_enable, the function sd_softdevice_enable no longer need to wait for the oscillator to start because it already running, so the processor is never put into a sleep mode, so this function always returns.  Is my understanding correct? 

Thanks,

Wayne

[Kenneth]

wouchida said:

In the same line of reasoning, if the external LF oscillator is started prior to the call to sd_softdevice_enable, the function sd_softdevice_enable no longer need to wait for the oscillator to start because it already running, so the processor is never put into a sleep mode, so this function always returns.

That is likely, but not certain. I know there was a change at some point, from softdevice would always re-init the clock, to keep the LF clock running if it was already running.

Best regards,
Kenneth

[eiadj]

Kenneth,

Thanks for the help in resolving this issue.

Is this errata_108 issue chip specific (i.e. swapping the existing part with a new part should solve it)?

If that's the case, does this issue occur on all date or build codes or only a subset?

Thanks!

Eiad Jandali

[Kenneth]

All variants of the nRF82832 can have this issue (for instance it may vary over temperature), and thereby all applications running on the nRF52832 should apply this workaround yes.

Best regards,
Kenneth 

[eiadj]

Kenneth,

Ok, we have a different version of the product which essentially the same circuit with a different PCB layout and mechanical enclosure - we have NOT observed the issue with that product. Any idea's why?

With the product experiencing failures, we are seeing around 4% of units impacted - does that make sense based on Nordics data on this issue? Some context hear will help us understand is errata_108 is responsible for all of our issues or if there is a second effect we missing.

Can this issue spread with the working boards (Is errata_108 susceptibility something that could increases with usage time)? This will help dictate how we deal with existing inventory that already has firmware installed.

Thanks,

Eiad Jandali