- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
03-06-2017 04:16 PM
We've developed our own firmware that we plan to load onto Telegesis ETRX357 modules.
We'd like to be able to do so using the over-the-air mechanism. The R309 firmware has an "AT+PASSTHROUGH" command, which I believe implements a variant of Silicon Lab's proprietary OTA mechanism.
The firmware we built has the "Standalone Bootloader Client" plug-in configured, which implements the SiLabs OTA protocol.
But I suspect Telegesis modified the OTA mechanism in some way that is not compatible with the Standalone Bootloader Client:
- The AT+PASSTHROUGH command requires a password, but the SiLabs OTA mechanism has no concept of a device password.
- The SiLabs mechanism uses a token, MFG_BOOTLOAD_AES_KEY, in a challenge/response scheme to ensure only an authorized device can initiate the OTA bootloading process. But the Telegesis ETRX3xx modules don't have that token programmed. Somehow, AT+PASSTHROUGH works without it. They apparently either have some key compiled in, or the protocol is modified to not use one at all.
It seems that the AT+PASSTHROUGH mechanism will only work when the target device is running the Telegesis standalone bootloader and R3xx firmware. We still have the Telegesis bootloader, but I've already loaded the device with our firmware serially. At that point, it doesn't seem to work with AT+PASSTHROUGH anymore.
In my experiments, I've tried to initiate an AT+PASSTHROUGH connection to a module that already has our firmware loaded, but the connection is refused because we haven't set the MFG_BOOTLOAD_AES_KEY token. But I don't know what to set it to. I have no idea what the source device (where AT+PASSTHROUGH is running) will use.
So, to get down to brass tacks, I wondering if you could help me with any of the following:
- A .EBL file for the R3xx firmware, so I can restore our module to a state that should accept an AT+PASSTHROUGH load.
- Information about your modifications to the OTA mechanism and/or the appropriate security keys so that I can make our firmware accept an upload. (I have a feeling this is something you'd rather keep secret.)
- If I do set the MFG_BOOTLOAD_AES_KEY token on the source device, will the AT+PASSTHROUGH command start using it?
- If there's no way to make AT+PASSTHROUGH target a device that's already running non-Telegesis firmware, do you know if it would be possible to implement a SiLabs-compliant OTA bootload using something like the AT+SENDUCAST or AT+RDATAB commands on R3xx firmware? Or any of the raw commands on the CICIE firmware?
03-10-2017 04:13 AM
You can find more information about AT+PASSTHROUGH on here(please refer to 13.2):
Please find the R309 ebl file attached.
03-10-2017 12:18 PM
I don't see any attachment.
I have read that documentation, it doesn't really address my questions.
But I have learned the answer to my second question on my own. Apparently the R3xx firmware does respect the MFG_BOOTLOAD_AES_KEY token, if it is set. By setting the same value in that token on both the source (R3xx) device and target (where our custom firmware is loaded), then the authentication succeeds and the download will proceed.
Apparently the Standalone Bootloader Client plug-in ignores the password that the AT+PASSTHROUGH command sends. It only cares about the authentication done using the bootloader key.