SoftDevice Timing Fault with LFXO

RE: SoftDevice Timing Fault with LFXO

Sigurd — Thu, 02 May 2019 12:05:27 GMT

Based on your description, then it seems to be software related, and not a problem with the crystal.

Are you hardfaulting, or are you entering the app_error_fault_handler() ?

If you are entering the app_error_fault_handler(), then please confirm what pc value that is printed in

__LOG(LOG_SRC_APP, LOG_LEVEL_ERROR, "Softdevice assert: %u:%u\n", pc, info);

If you are hardfaulting, make sure that the hardfault library is used.

Add these to your projects:

$(SDK_ROOT)/components/libraries/hardfault/hardfault_implementation.c
$(SDK_ROOT)/components/libraries/hardfault/nrf52/handler/hardfault_handler_gcc.c

And set HARDFAULT_HANDLER_ENABLED to 1 in sdk_config.h, and add DEBUG_NRF in your preprocessor definitions.

RE: SoftDevice Timing Fault with LFXO

adrfc — Fri, 12 Apr 2019 15:42:26 GMT

[quote userid="15146" url="~/f/nordic-q-a/45546/softdevice-timing-fault-with-lfxo/181675"]Sounds like it could be a issue with the crystal. If the modules are old, and they used to work before, it could be crystal ageing worsening the accuracy. Are you able to desolder the crystal from the module, and solder a new crystal(a crystal you know is working at 20ppm) to the module, and see if that solves the issue ?[/quote]

The devices are less than 8 months old, so ageing is rather unlikely.

Swapping the crystals between one working and one non-working (but otherwise identical) boards produces inconsistent results: on some piece the issue does "move" with the crystal, but at other times both boards start or stop working.

We also realized that the issue has arisen even on a board that uses a different crystal (for which we are not able to retrieve the specifications right now, but should have been chosen as an equivalent replacement).

[quote userid="15146" url="~/f/nordic-q-a/45546/softdevice-timing-fault-with-lfxo/181675"]How did you do these measurements?[/quote]

We tried two methods:

Measuring the crystal directly with an oscilloscope (with the obvious problems that brings).
Connecting the tick event of an RTC peripheral to a GPIOTE toggle task through PPI, with LFXO as the LFCLK source.

That said, we also tested the Light Switch Proxy Server example in the nRF5 SDK for Mesh 2.2.0, using nRF5 SDK 15.0.0 and s132 6.0.0, and the issue did not arise on known non-working board.

Alberto

RE: SoftDevice Timing Fault with LFXO

Sigurd — Thu, 11 Apr 2019 14:50:56 GMT

Sounds like it could be a issue with the crystal. If the modules are old, and they used to work before, it could be crystal ageing worsening the accuracy. Are you able to desolder the crystal from the module, and solder a new crystal(a crystal you know is working at 20ppm) to the module, and see if that solves the issue ?

[quote user=""]As far as measurement is concerned, we could not find any conclusive difference in the clock frequency between working and non-working boards, but, without a reliable way to get the clock signal from the microcontroller, our measurements have been somewhat approximate.[/quote]

How did you do these measurements?

RE: SoftDevice Timing Fault with LFXO

adrfc — Wed, 10 Apr 2019 08:48:29 GMT

[quote userid="15146" url="~/f/nordic-q-a/45546/softdevice-timing-fault-with-lfxo/180035"]1) Do you see this issue when the project is compiled in both "Release" and "Debug" configuration?[/quote]

Yes, the configuration makes no difference. It also does not matter whether a debugger is attached or not.

[quote userid="15146" url="~/f/nordic-q-a/45546/softdevice-timing-fault-with-lfxo/180035"]2) How about NRF_CLOCK_LF_ACCURACY_50_PPM ?[/quote]

Any value except 20ppm seems working.

[quote userid="15146" url="~/f/nordic-q-a/45546/softdevice-timing-fault-with-lfxo/180035"]No, if you set a worse(higher) ppm value , then the SoftDevice will take this into account in the timining calcuation (e.g. when to open/close BLE RX/TX window). [/quote]

That was my assumption, but by "increasing accuracy" I meant specifing a lower, rather than higher, ppm value.

[quote userid="15146" url="~/f/nordic-q-a/45546/softdevice-timing-fault-with-lfxo/180035"]Is it always this PC value you see?[/quote]

Yes. To be clear: this is the PC of the frame before stopping in the hard fault handler.

RE: SoftDevice Timing Fault with LFXO

Sigurd — Wed, 03 Apr 2019 13:34:39 GMT

Hi,

1) Do you see this issue when the project is compiled in both "Release" and "Debug" configuration?

[quote userid="73646" url="~/f/nordic-q-a/45546/softdevice-timing-fault-with-lfxo"]to either 250ppm or 1ppm seems to fix the fault.[/quote]

2) How about NRF_CLOCK_LF_ACCURACY_50_PPM ?

[quote userid="73646" url="~/f/nordic-q-a/45546/softdevice-timing-fault-with-lfxo"]expected that increasing the specified accuracy would, if anything, lead to worse problems.[/quote]

No, if you set a worse(higher) ppm value , then the SoftDevice will take this into account in the timining calcuation (e.g. when to open/close BLE RX/TX window).

[quote userid="73646" url="~/f/nordic-q-a/45546/softdevice-timing-fault-with-lfxo"]0x000152d4 for S132 6.1.0 and 0x00015326 for 6.1.1[/quote]

Is it always this PC value you see?