Softdevice S140 temporarily stops advertising BLE

[karnram]

We are using softdevice S140 6.1.1 with nrf52840 for a BLE peripheral. We see that mobile devices are not able to discover this peripheral intermittently for some time during the day ranging few minutes to hours. In an exception case, it required a physical power reset to recover from this issue. We use FAST BLE advertising with interval of 150ms and timeout of 0 (infinite). We additionally handle GAP connection and disconnection events to change the advertisement to Non-connectable when someone connects and back to connectable when the user disconnects. We don't see any failures in firmware logs which can indicate an issue with BLE configuration. These issues were reported for production peripheral devices and we have not been able to able to reproduce them locally. I need help with following queries:

1. Can a softdevice stop advertising for any reason if the duration is set to infinite? We don't see any logs for BLE_GAP_EVT_ADV_SET_TERMINATED which can possibly indicate such a thing.
2. Can we land in a situation where peripheral is not able to prioritize processing of GAP events like connected, disconnected, terminated etc. and we are not able to make softdevice resume advertisement after these events?
3. Can there be an issue with peripheral radio which can cause it to stop advertisement for some reason? We are thinking of logging radio notifications to concretly capture any such issues, is it advisable to enable radio notifications for production devices, are there any best practices to leverage this feature? 

[karnram]

Please find below the required details for the HF crystal:

hf_crystal_datasheet.pdf

[karnram]

There seems to be some confusion with the capacitor value used in our peripheral today, I found another  set of values for C26 and C33. I will confirm the correct values in sometime.

 

[Einar Thorsrud]

Hi,

I think the HF crystal circuitry is the smoking gun here. From the datasheet I see that the crystal has a CL value of 8 pF, so your load caps (C26 and C33) should both be approximately 2 * 8 pF - 4 pF = 12 pF. 22 pF and 18 pF is too far off, so this crystal is not correctly loaded and is so far off that it is a likely explanation for what you are seeing.

Normally you can verify the crystal frequency indirectly by setting up a carrier (using for instance the radio test example), and verifying that the carrier is centered in the middle of the configured channel. If it is centered at room temperature, then you will have a good margin. However, if it is far off, which I expect in this case given the HF circuitry, the margin will be less, and with low temperatures the frequency might be offset by too much. I expect you will be able to measure a difference in frequency by chancing the temperature to (say) -20 °C.

(As a side note I recommend you consider sending us your designs for review and potential tuning in the future, as crystal loading is one of the things we routinely check on customer designs we are asked to review.)

Regarding which phones we have seen this with in the past I do not have a long list but it has typically been more low-end phones. That said, if the nRF frequency is too much of it could cause problems with any phone, and that may be the case here.

Regarding your FreeRTOS BLE task I do not know enough about your firmware to suggest anything there. However, based on what we know now, I think an issue with your HW is much more likely than this being a firmware issue, so I suggest looking properly into the hardware first.

Edit: I see you updated the post while I was writing. It will be very interesting to know what cap values you have on the devices that have failed in case you have several variants out in the field.

Einar

[karnram]

Hi Einar,

I reconfirmed with our team that we are only using 12pF-12pF configuration in the production. The change happened during our product design phase when we decided to use a different make of the crystal and had to change corresponding capacitor values. With this issue ruled out, could you provide your inputs on other possible things that might be causing discovery issues?

>> As a side note I recommend you consider sending us your designs for review and potential tuning in the future, as crystal loading is one of the things we routinely check on customer designs we are asked to review

What additional parts of design you want to review to better understand this issue? I can share those details.

>> Regarding which phones we have seen this with in the past I do not have a long list but it has typically been more low-end phones.

Are there specific BLE chipsets used in those low-end phones which cause such issues? 

Thanks

Ram

[Einar Thorsrud]

Hi Ram,

karnram said:

With this issue ruled out, could you provide your inputs on other possible things that might be causing discovery issues?

This is a difficult case. I have discussed with some collogues and searched though the case history, and generally there are two reasons we have seen for this symptom before (some phones not being able to detect advertisement packets):

• Too large frequency offset of the HF crystal oscillator
• Too large frequency offset in the BLE central (phone)
• A combination of the two above (which helps explain why this is seen more with some device combinations but not others)

With the updated load capacitor values of 12 pF, your HF clock circuitry looks good. However this should still be one of the major hypothesizes, given the behavior that has been observed. There could still be an HW issue, either in general, or with some specific devices. Is it possible for you to obtain one of the failing devices and test it in your lab or alternatively send it to us? I would like to test the frequency accuracy as described in this post. I think this is important, also in case it is not relevant, as in that case we would have been able to rule out one of the major hypotheses.

Your initial hypothesis that the nRF simply stops advertising is absolutely a possibility, but I do not see how the SoftDevice could stop advertising in itself. If this is the case, then it is likely that your firmware stops advertising or does not start it when it should.

karnram said:

What additional parts of design you want to review to better understand this issue? I can share those details.

My comment on this point was more regarding the load caps which seemed to be off at that time, which we would have spotted in a review. That is not relevant, and I think we have seen the relevant parts of your HW design for now.

karnram said:

Are there specific BLE chipsets used in those low-end phones which cause such issues? 

To be honest we do not have enough data to see a strong pattern or to blame a specific phone, but we have seen similar issues with Huawei P Smart (Kirin 659), Nokia 1 Plus (Mediatek MT6739WW), Alcatel 1x (Mediatek MT6739), Nokia 3 (Mediatek MT6737) and some "noname" Android devices. An interesting observation is that I have not found any reports of this with a high end phone. But we do not have enough data to draw any concussions.

Einar