Upon testing how a RAK3172 responds to power glitches or cycling and having a 10uf on power plane, I have found that:
Many times the ENCKEY loses value and becomes 0000000000000000. For P2P operation the other P2P settings seem to endure.
but sometimes an even more serious thing happens…
The device becomes unresponsive: AT Command response and the loaded program stop.
The firmware must be reloaded via a process to get the device active again…
Using STM32CP Uart mode…Boot Mode…Full Chip Erase… then Load RAK3172_v1.0.4_Boot+App_20220218.hex , then Load RAK3172-E_latest.bin then I can load my custom firmware again…working.
However, changing to a 100uf cap. appears to much lessen the device from becoming unresponsive, but the ENCKEY can still lose setting but also much less frequently.
Also found that keeping Reset low during sustained power cycling prevents the above symptoms. So as long as the Reset pin is kept low during power glitches, I have not seen this issue.
Any ideas to fully protect the device without external brownout circuit?
Is there a way to have longer on-chip reset and brownout delay?
Regards
Thank you for informing us on the issue you found. I will report this to the team.
For the P2P ENCKEY, are you just using our basic P2P code example?
Does uploading RAK3172-E_latest.hex using STM32CubeProgrammer doesn’t work for you? I am surprised you still need to upload the legacy 1.0.4.hex firmware.
Can you describe you scenario of power glitches? Is it because of your power source or your current hardware setup?
After using only firmware RAK3172-E_latest.hex does indeed work.
However, full chip erase must be performed first.
I am using a modified version of your P2P example with encryption enabled.
I know that the decryption is not working at this point in 3.53 but I am just getting the data.BufferSize as an indicator that my receiver did receive a valid payload. i.e data.BufferSize = 3 for OK.
I just need a simple notification from a push button.
if (rx_done == true) {
rx_done = false;
if (buf_cnt == 3){
Serial.println("Button Pressed");
digitalWrite(PA1,HIGH);
delay(1000);
digitalWrite(PA1,LOW);
}
}
My power glitches are purposely induced to see how the device responds.
Disconnecting and reconnecting the + wire. 3 to 8 times second…
Since loading RAK3172-E_latest.hex after full chip erase. I have not been able to cause the device to stop responding by this random power cycling. I’ve tried many times.
However, the enckey setting has been cleared. A work around for me is that I am now saving the enckey setting in Flash via a Custom AT Command thanks to @beegee’s idea. That setting is loaded into enckey on reboot.
So, I am much more confident with how RAK3172 RUI3 is now working.
Thank you very much for giving the details. There are few improvements that is being done on the encryption of LoRa P2P mode. I already reported this issue and put a high priority.