There is a known issue in the version 0xC0 and 0xBF, which is not present in the previous versions.
If you use DeepSleep before you Join the LoRaWAN network, it will not be able to join the network. This is only with deep sleep, and only when used before LoRaWAN_Join. Instead of deep sleep (modeDeepSleep), you can use regular sleep (modeSleep), which will take more current in sleep.
Is this any deep sleep or just in the SleepConfig_t structure? For example, deep sleep mode is also an option in coreConfiguration.Idle.Mode and is part of the enumeration WaitMode_e, which is used in several API functions.
Do I need to avoid all deep sleep options in all structures and functions?
No, only if using LoRaWAN_Sleep with DeepSleep before Join. You can test.
I’ve done some testing, and I found another problem with LoRaWAN_Sleep using DeepSleep. It appears that, if Vdd is less than about 2.3V, the processor doesn’t return to my code from LoRaWAN_Sleep. I believe that, once the sleep interval is complete, the processor goes active, but doesn’t return to the calling program.
I have not been able to verify this with the debugger, since the debugger powers the module with more than 2.3V. I am relying on debug messages my code sends out the UART. I’ll try to rig up something to debug the module using external power only.
Here’s a little more information. I tried external power around 2.1V, but could never get the bad behavior to occur. I suspect that the regulated external power supply was too “stiff” to allow whatever disturbance to occur.
So, I put little print messages inside the LoRaWAN_Sleep function. See screenshot below.
I then charged up the supercapacitor to around 2.5, reset the micro, and let it run powered only by the capacitor. Below is a screenshot of messages received from the micro. The current measurement has not been calibrated, but the VDD measurements are correct. Also, mode 2 is deep sleep.
Note that the micro did not recover from deep sleep at VDD = 2.167V. The last little message received was “2”, so it appears that the micro is stuck waiting for an interrupt from the M0+ core.
Do you think this is related to the known bug? I never had this problem with stack BA.
Hi Paul, apologies for the delay.
I tried external power around 2.1V, but could never get the bad behavior to occur.
This may signal that there is a spike in voltage, and not an issue in the stack. The expternal power supply can handle the spike and deliver the current that is needed, but the capacitor cannot.
What I suggest is to measure the voltage with an oscilloscope when you are conducting your test in order to see if the voltage drops too much.
I agree that a momentary voltage dip might have something to do with this. I can see evidence of a dip (scope triggers), but can’t actually capture it (scope displays flat line). But I still think there’s a problem with deep sleep (after joining). Here’s why:
- This problem never occurred with the old (BA) stack.
- It does not occur when using “regular” sleep mode in the new stack (BF), regardless of the amount of charge on the capacitor.
it is difficult to recreate. We can only investigate once we are able to reproduce the issue.
Can you investigate further with the oscilloscope? Use more precise time scale?