We have an application that normally advertises continuously at 4Hz. We have observed that ADVS are no longer received from some devices after their temperature is raised to ~100C and the ADVerts are still not received when their temperature drops again to 25C. A power cycle recovers from this state.
Observations:
When we attach a debugger we find that our application is still in its normal/advertising state as expected. I.e. It has called
The main gecko event dispatch mecahnism appears to be functioning OK as we have an ISR that calls gecko_external_signal() at ~1Hz. The resulting gecko_evt_system_external_signal_id is still being dispatched and processed correctly by our application.
We are not currently adjusting the HFXO or LFXO xtals (CTUNE) for the temperature as measurements on prototypes indicated that they are still within BLE spec (just) at this temperature.
Are there any gecko events or state that we could monitor to get some insight into this problem?
Thanks
Bluetooth Low Energy
Discussion Forums
Answered
Answered
More test results...
- With the debugger permanently attached the problem could not be reproduced by heat cycling between 25C to 125C (5 cycles). However ...
- When the debugger was detached at ~ 110C the advertising stopped promptly. Re-attaching the debugger showed the application to be in the same state as previously observed, and remained in that state down to 25C. Ie. It has just stopped advertising without any obvious reason or event being raised.
- With the device now cooled to 25C, using the debugger to force the application to call gecko_cmd_le_gap_start_advertising() fixed the problem: It started advertising again, and continues to advertise after the debugger is detached.
So this seems to be pointing at an issue between sleep/wake & temperature (likely clock drift). Do you have any suggestions for confirming/diagnosing where the issue actually lies using debugger and/or firmware modifications? I want to get as close as possible to the root cause before unpotting the device to check that the xtals are within spec or not!
0
After measuring the XTALs at 110 C: HFXO = +35.6ppm, LFXO = -321ppm. So although both XTALs are within BLE spec. at 110 C they are moving apart/shifting in different directions as the temperature increases.
Could this cause the observed problem?
Is the LFXO frequency drift even an issue when there is no BLE connection?
My next step is to include temperature compensation logic to see if this prevents the problem by keeping both xtals closer to nominal. I would still want to be able to detect the problem from the application in case some future production/environment difference causes it to reooccur.
0
We also noticed that on the module BGM13P22 radio shuts off at approximately 108 dg C (reported by EMU->TEMP), while CPU was still working fine at 150 C. When temperature decreased back to normal values, radio still didn't work. Fortunately, for our project radio functionality was not necessary at high temperatures, but it had to automatically return into a working state at lower temperatures. We solved this issue by forcing the MCU to enter EM4H energy mode at 80 C and exit through reset at 60 C. This way radio "survives" through high temperature zone and a power cycle is not needed, just a regular reset.
0
Update...
I have now integrated temperature compensation logic for the LFXO and HFXO. At 110 C, LFXO is now -20ppm and HFXO is less than +1ppm on the device under test. Unfortunately this does not prevent the problem! So it seems there is something else in the sleep/wake logic that is sensitive to temperature.
Could someone from SiLabs please give some idea what might be going on in the gecko_wait_event() call stack to account for BLE advertising stopping when the core temperature reaches ~110 C?
(P.S. I did also notice that disabling sleep mode has a similar effect to attaching a debugger, i.e. BLE advertising continues OK to 125C, and beyond.)
0
More info...
Monitoring the power consumption shows that the BG13 stops waking up for Advertising Intervals when ~110C is reached. I.e. It seems the ADVertising task is being deliberately stopped, and it is not an RF output issue. This was already suspected as ADVertising does not restart when the temperature drops again.
0
More info...
Testing with another device we find the same problem occurs reliably at ~120C (reported ADC core temp). As before, attaching a debugger prevents the problem occurring as the temperature rises. Infact this sample device continued to advertise reliably to at least 144C (well beyond spec) as long as the debugger remained attached.
Also note that resetting the device already at 130C with the debugger attached restores normal operation/advertising for as long as the debugger remains attached.
0
This issue was related to how sleep is handled and the clocks get synced. It will be fixed in the next release.
Correct Answer
1
This issue was related to how sleep is handled and the clocks get synced. It will be fixed in the next release.
Was this fixed? Can't find anything in the release notes of the last SDKs.
0
@kamil
I was informed, and my own testing confirms that this problem was fixed in release 2.13.0. (I have not tested any later releases). As you noted, the release notes do not make this very clear [https://www.silabs.com/documents/public/release-notes/bt-software-release-notes-2.13.0.0.pdf]. My guess was that is was a part, or a side effect of Fix 358171 "a random advertising hang issue which was observed when the application optimization build option was disabled or the device was exposed to low temperature.".
@silabs
It would be reassuring for all to see an explicit confirmation/ammeded release note that this fix also addresses the high temperature case.
1
Thanks, @JohnC. Haven't yet tried anything past 2.12.4.
Advertising stops as temperature rises. How to fix/debug this problem?
Configuration: EFR32BG13P632F512IM32 (Industrial 125 C spec), SDK = Gecko v2.5.2, BT 2.11.2 Build 328
Problem:
We have an application that normally advertises continuously at 4Hz. We have observed that ADVS are no longer received from some devices after their temperature is raised to ~100C and the ADVerts are still not received when their temperature drops again to 25C. A power cycle recovers from this state.
Observations:
When we attach a debugger we find that our application is still in its normal/advertising state as expected. I.e. It has called
gecko_cmd_le_gap_start_advertising(0, le_gap_user_data, le_gap_connectable_scannable);
and has not called:
gecko_cmd_le_gap_stop_advertising(0);
The main gecko event dispatch mecahnism appears to be functioning OK as we have an ISR that calls gecko_external_signal() at ~1Hz. The resulting gecko_evt_system_external_signal_id is still being dispatched and processed correctly by our application.
We are not currently adjusting the HFXO or LFXO xtals (CTUNE) for the temperature as measurements on prototypes indicated that they are still within BLE spec (just) at this temperature.
Are there any gecko events or state that we could monitor to get some insight into this problem?
Thanks
More test results...
- With the debugger permanently attached the problem could not be reproduced by heat cycling between 25C to 125C (5 cycles). However ...
- When the debugger was detached at ~ 110C the advertising stopped promptly. Re-attaching the debugger showed the application to be in the same state as previously observed, and remained in that state down to 25C. Ie. It has just stopped advertising without any obvious reason or event being raised.
- With the device now cooled to 25C, using the debugger to force the application to call gecko_cmd_le_gap_start_advertising() fixed the problem: It started advertising again, and continues to advertise after the debugger is detached.
So this seems to be pointing at an issue between sleep/wake & temperature (likely clock drift). Do you have any suggestions for confirming/diagnosing where the issue actually lies using debugger and/or firmware modifications? I want to get as close as possible to the root cause before unpotting the device to check that the xtals are within spec or not!
After measuring the XTALs at 110 C: HFXO = +35.6ppm, LFXO = -321ppm. So although both XTALs are within BLE spec. at 110 C they are moving apart/shifting in different directions as the temperature increases.
Could this cause the observed problem?
Is the LFXO frequency drift even an issue when there is no BLE connection?
My next step is to include temperature compensation logic to see if this prevents the problem by keeping both xtals closer to nominal. I would still want to be able to detect the problem from the application in case some future production/environment difference causes it to reooccur.
Update...
I have now integrated temperature compensation logic for the LFXO and HFXO. At 110 C, LFXO is now -20ppm and HFXO is less than +1ppm on the device under test. Unfortunately this does not prevent the problem! So it seems there is something else in the sleep/wake logic that is sensitive to temperature.
Could someone from SiLabs please give some idea what might be going on in the gecko_wait_event() call stack to account for BLE advertising stopping when the core temperature reaches ~110 C?
(P.S. I did also notice that disabling sleep mode has a similar effect to attaching a debugger, i.e. BLE advertising continues OK to 125C, and beyond.)
More info...
Monitoring the power consumption shows that the BG13 stops waking up for Advertising Intervals when ~110C is reached. I.e. It seems the ADVertising task is being deliberately stopped, and it is not an RF output issue. This was already suspected as ADVertising does not restart when the temperature drops again.
More info...
Testing with another device we find the same problem occurs reliably at ~120C (reported ADC core temp). As before, attaching a debugger prevents the problem occurring as the temperature rises. Infact this sample device continued to advertise reliably to at least 144C (well beyond spec) as long as the debugger remained attached.
Also note that resetting the device already at 130C with the debugger attached restores normal operation/advertising for as long as the debugger remains attached.
Was this fixed? Can't find anything in the release notes of the last SDKs.
@kamil
I was informed, and my own testing confirms that this problem was fixed in release 2.13.0. (I have not tested any later releases). As you noted, the release notes do not make this very clear [https://www.silabs.com/documents/public/release-notes/bt-software-release-notes-2.13.0.0.pdf]. My guess was that is was a part, or a side effect of Fix 358171 "a random advertising hang issue which was observed when the application optimization build option was disabled or the device was exposed to low temperature.".
@silabs
It would be reassuring for all to see an explicit confirmation/ammeded release note that this fix also addresses the high temperature case.