I have two custom breakout boards with 3172 stamp modules on them that I’ve been doing some development with. I’m using the Arduino environment with the RUI3 BSP, and the devices are setup for OTA with a RAK7268 (V2) gateway. I set the APPEUI, APPKEY, etc., on the boards using the WisToolBox utility, and everything works exactly as I would expect. If I have made a code change and re-uploaded it to the boards, the LoRa settings on these two boards persist.
I now have a third board - identical to the the other two - but it behaves differently. Uploading new code to this board (exactly the same as the other two), the APPEUI, APPKEY, and DEVEUI get zeroed out every time. If I manually reset them after the upload, things work fine. And the settings persist if power is removed. But I’m perplexed as to why this 3172 behaves differently to the others? Having to go through this exercise everytime I make a code change is a pain.
Up to this point, everything was at RUI_4.0.6_RAK3172-E. I upgraded to 4.1.0 for giggles, but the head-scratcher persists. What am I missing/not understanding?
As I understand it, on the third unit. The OTAA parameters always goes to zero when you upload anything. Then you have to use WisToolBox again to input these OTAA parameters then perform a reset.
I agree that this is strange since you are uploading the same code.
It is good that you update to 4.1.0. I am just thinking there could be some corruption on handling the internal flash. Will it be possible for you to full erase the flash of RAK3172 using STM32CubeProgrammer then upload the hex file of the latest firwmare 4.1.0 using STM32CubeProgrammer?
I have the STMCubeProgrammer software. My board design only provides access to the 3172 via UART. All of my communication with the thing is via USB and the ubiquitous FTDI FT232RL to make it just show up like a serial device on a COM port. The STM software may be looking to control pins I have not brought out to the interface beyond RX/TX. If you have a link that might shed some light on how to procede with this arrangement, that would be helpful. I haven’t spent a lot of time looking at the STM toolset thus far, as everything has just worked as expected within the stuff I’m familiar with (Arduino/BSP).
Thanks for your help.
Addendum: I realize that, on my board design, I didn’t bother to bring out the BOOT0 pin from the 3172. My gut tells me that I really need this for what we’re trying to do, here. Will rectify.
Apologies for the almost immediate double post - I just wanted to confirm that I tack-soldered a piece of 30 guage kynar wirewrap wire onto the BOOT0 pin of the stamp so that I could control it, and then proceded to do the full erase/reprogramming using the STMCubeProgrammer as instructed.
THIS CORRECTED THE ISSUE.
The suspect device now holds its configuration through multiple re-programmings.
Thanks for your help!
(Note to self - bring out BOOT0 on next PCB revision )
)