Hi–
We’ve been working to integrate your RAK11720 LoRa SoC with one of our devices. One of the requirements is to support receiving OTA firmware updates via LoRa and then update the RAK11720 with the new firmware.
Using the RUI3/Arduino serial loader could in some circumstances end up leaving the RAK11720 in an unusable state, where the update failed and/or installed a buggy firmware which would leave the RUI3/Arduino bootloader no longer available for use.
We understood this from the start of this project, so designed our board to have access the BOOT pin (pin 21) and RESET pins (pin 22) of the RAK11720 so we could perform firmware updates using the Ambiq SBL bootloader. This is the same method outline in the YouTube video “How to Recover RAK11720 Module on Faulty Custom Firmware and Not Responding to AT Commands” on the RAKWireless YouTube channel: https://www.youtube.com/watch?v=N9ABRh8VyA0
The video is also linked to from the RAKWireless linked in page: https://www.linkedin.com/posts/rakwireless_how-to-recover-rak11720-module-on-faulty-activity-7098257876778983425-yInv
and mentioned on your forums:
https://forum.rakwireless.com/t/failed-to-enter-bootload-phase/10041
However I could not get the “bootloader recovery” procedure to work using the BOOT/RESET pins and the “Burn Bootloader” command from the ArduinoIDE. Holding the BOOT pin high while resetting the RAK1170 did not seem to have any effect at all. There are few different people in the thread above that seem to have the same issue, and I have not seen any posts from anyone who seems to have succesfully got this work. Programming/recovery via the JTAG/JLink connector does work, and I have succesfully recovered from a failed firmware using this method. This method however would not work via OTA in the field.
Analysis & what I believe the problem is
Looking further into this and the Ambiq Apollo3 documentation, it appears that in order for the Ambiq SBL to function the “Flash OTP 0 Customer Info Space (Info0)” must be configured correctly on the Apollo3/RAK11720 flash.
When I read the INFO0 block from the RAK11720 using JLink the first 4 hex words, which are supposed to be a signature to mark the INFO0 block as valid, are as follows:
00000000: 4860a588 …H 00000004: 49100634 4..I 00000008: 020a8458 X... 0000000c: a4080860 …
However when looking at the AmbiqSDK utility to generate an INFO0 block, the correct signature words are documented as:
00000000: 48eaad88 …H
00000004: c9705737 7Wp.
00000008: 0a6b8458 X.k.
0000000c: e41a9d74 t…
See the file “create_info0.py” from the RAK Apollo3 github repository:
https://github.com/RAKWireless/RAK-APOLLO3-RUI/blob/2af4ff38da9835a70ffafbba736399560ac0c6d7/security/apollo3_scripts/am_defines.py#L176
I have succesfully re-written the INFO0 block using JTAG/JLink and making those changes does make the BOOT/RESET pin combination work to allow using the “Burn Bootloader” command from ArduinoIDE as documented in the YouTube video, which will further allow us to use the same mechanism to perform OTA firmware updates.
It’s possible that I’m missing something, but it does appear to me that the INFO0 block is just not set correctly at RAK before shipment.
Question: We would prefer to not have to re-program the INFO0 on every RAK11720 we purchase from RAK as our production department doesn’t currently have the correct JLink hardware (or licenses) for this-- Is it intentional that the INFO0 block isn’t programmed w/what I believe are the correct signature words at the RAK factory? Can we expect this to be fixed for future shipments? The four I currently have available to me have the same issue w/the signature.
Any thoughts on this matter would be appreciated.