I wanted the chip to keep its default DevEUI (like on the sticker)
I have not reset the chip using the reset command, and I did not update the FW.
AFTER seeing this issue, I did update the firmware to the latest version (released on the 25th)
I then set all of the config settings. AppEUI, DevEUI, AppKEY, Work Mode, Region.
The problem still randomly reoccures.
Any idea what may be going on?
Might it be a power issue? The power is coming from a 3.6v battery directly (within the upper range that the datasheet shows).
This is a custom board.
If you need, I can send the schematics.
Is there a way to do it in a more private way though?
Could this be a problem I have caused with a bad connections or something?
I found by re-setting the settings everytime, I am able to work-around the issue.
But this costs time, power. (and possibly write cycles?)
Yes, the RST pin is currently Floating. I have made designed like that before using the RAK3172, I was under the impression that there is an internal pullup. is the not correct?
I have just experienced the same issue as described in this thread.
The software version on the 3172 module is:
AT+VER=RUI_4.0.0_RAK3172-E
I left the module running overnight, re-programmed it this morning and I now see the following after running the AT commands:
AT+DEVEUI=?, AT+APPEUI=? and AT+APPKEY=?
I get the following response:
AT+DEVEUI=0000000000000000 OK AT+APPEUI=0000000000000000 OK AT+APPKEY=00000000000000000000000000000000 OK
Fortunately I made a copy of these values so hopefully I can re-load them.
The reset circuitry looks like this:
Thanks in advance for any help you can offer.
Update - I have successfully reloaded the IDs/keys and established a network connection with uplink data been received. I am still concerned that this may randomly occur when the board is installed. Is there any information regarding cause and mitigation?
This is slightly confusing - is that commit for a library for v4.0.2 or was the wrong tag used?
I just want to use the prebuilt v4.0.6 hex file from the repo.
Thanks again.
Neil.
There were two main issues. First was a timer overflow which caused the modules to hang. Second was an NMI triggered by fluctuating power supply which caused the modules to hang. Both are solved in V4.0.6
(3) LoRaWAN mode does not have this problem. Encryption is handled by the LoRaWAN stack with either the keys received during OTAA join or with the keys set with AT command (or API call) for ABP.