application runs 9 times out of 10 NRF_ERROR_RESOURCES error free and then, once in a while, NRF_ERROR_RESOURCES massively present from the beginning

[astella]

To the kind attention of Nordic support team,

I'm testing a freertos project, with softdevice and radio notifications. A constant number of notifications is queued before the starting of the connection interval, and sent during the connection interval itself. It works very well, I get this high speed data stream. Every time I get a sporadic NRF_ERROR_RESOURCES, the feedback mechanism exploiting BLE_GATTS_EVT_HVN_TX_COMPLETE starts working as well, and the resource error disappear after a while.

Everything works fine, like 9 executions of the program out of 10 are really stable and NRF_ERROR_RESOURCES free. If I reset (Ctrl+Shift+F5 using Segger), it seems that, once in a while, from the beginning of the connection NRF_ERROR_RESOURCES is massively there, and it never goes away. Only reducing the number of queued notifications help.

But why the number of notifications should be reduced once in a while? All this sounds to you like a problem in the application, or there could be something changing in the connection? I thought about master forcing a different connection interval than the desired one. But using BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST I have no evidence for now that this behavior is due to a change in connection interval timing. I attached systemview files to the project and next days I'll be possibly able to post some more thing about this issue (also I'm gonna use Nordic sniffer). Really, just a quick opinion from your experts would be very much appreciated. Also, any debug strategy you would recommend.

Thank you in advance, best regards.

[Einar Thorsrud]

Yes, it could. If the crystal is incorrectly loaded, the frequency will be off. And also, if you have configured the SoftDevice incorrectly, specifying a better clock source accuracy then you actually have, that could give similar problems.

Can you share your clock configuration (the NRF_SDH_CLOCK_* defines from your sdk_config.h)? Also, which LF clock source do you use? If a crystal, can you let me know which exact crystal you are using and the value of your load caps?

The above was about the LF clock source which is normally the main suspect in such cases. It is theoretically possible that there is an issue with your HF crystal as well, but I would expect that to manifest itself differently. It could be worth checking anyway though (just verifying that the load caps are calculated as explained in General PCB design guidelines for nRF52 series.

[astella]

Hi Einar,

Thank you for your suggestions. We are not using external xtal as 32.768Hz oscillator. So we are setting 

NRF_SDH_CLOCK_LF_SRC 0

NRF_SDH_CLOCK_LF_RC_CTIV 16

NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 16 // other values tested

NRF_SDH_CLOCK_LF_ACCURACY 1

In SoftDevice specification is briefly mentioned that timing warning about HFXO startup time. We will be

doing such measurements as well. I'm curious about what "not correct operation" would mean, though. 

This is our main quartz. According to your suggestion C21,22 should be

C21,22 = 2*Cl - Cpcb - Cpin = 2 * 10 - Cpcb - 3

Supposing "similar layout to Nordic layout" and Cpcb = 1pF 

2 * 10 - 3 - 1 about 16pF

We have 12pF mounted for the moment. We will try to do rf measurements to understand if Cload trimming is needed

Best regards

[Einar Thorsrud]

Hi,

The config looks roughly OK, but the recommendation is to set NRF_SDH_CLOCK_LF_RC_TEMP_CTIV to 2 when using LFRC in order to do calibration often enough even if the temperature has not changed.

There is little in the described behavior that points to an issue with the HFCLK, but as you write the load caps should be about 16 pF in your case, so that should anyway be fixed.

astella said:

doing such measurements as well. I'm curious about what "not correct operation" would mean, though. 

This is mostly about timing. For instance, the Bluetooth stack needs to enable the HFXO a certain amount of time before using the radio so that the frequency is not off etc.