I'd like to enter OTA DFU mode activated by GPIO (a button).
Apologize if this is a silly beginner question but the nomenclature here is a bit confusing for a beginner... bootloaders, apploaders, updaters... so please be gentle.
The board is 4103A with EFR32BG12P332F1024GL125 on a PCB4001.
Created a new bootloader project from template bootloader-storage-internal-single-lzma + GPIO plugin and debugger plugin to see messages.
This works fine with "soc empty" main firmware. I can activate OTA from the SiLabs android app, it reboots in OTA mode properly.
But when I press the button, the bootloader prints:
Slot: 00000000
Verify fail
This is OK because I have not written any update OTA, and the slot is empty.
Then it reboots and keeps looping like so until the button is released. Then it starts in the normal (not OTA) mode.
But I need the MCU to restart in OTA mode, just like if gecko_cmd_system_reset(2) were called.
How to achieve this from a bootloader?
Thanks,
-- dd
Bluetooth Low Energy
Discussion Forums
Unanswered
You could check the gpio state in the boot event of your main app. Then if the button is pressed, call gecko_cmd_system_reset(2)
0
Is this the only option? What if the main app has been already partially overwritten by failed OTA update attempt?
What if the bootloader validates the main app and finds it wrong?
-- dd
0
As far as I know, after a failed OTA update attempt the device will automatically stay in DFU mode. In other words, if your own app is corrupted (due to interrupted OTA upload) then the device will automatically reboot into AppLoader and stay there so that you can try to run the update again. Need someone from Silicon Labs to confirm this, though...
You can test it quite easily yourself: take your update image (application.gbl) and cut a random slice from the end. Then run OTA update with this truncated image. I expect that the target device will stay in DFU mode.
Another simple test would be to reset the development kit during the OTA upload. Again, after the reboot my expectation is that the device will stay in DFU mode.
0
Thank you Tyler, will test it when I get to work.
If you're correct, this means that the OTA uploader (apploader?)... which, from bootloader's view, is part of the application - keeps another internal flag, besides the reset flags in btl_resetinfo.h , to select whether stay in DFU mode or jump to the user app.
My question is, how to set this flag directly from the bootloader.
Another question - in which demo project or app. note we can find example how a bootloader (uploader? apploader?) can check the gbl file's version (downgrade protection) and product ID/characteristics.
Assume I have two incompatible device models and want to prevent running firmware for a wrong model, even if the file download was successful and passed integrity check (CRC?)
-- dd
0
Good questions, this is something that needs to be confirmed by the silicon labs folks. *Ping*
0
> how a bootloader (uploader? apploader?) can check the gbl file's version
This feature should be in plugin "Core/Application update version check", in file btl_parser_app_version.check.c.
But this file does not exist in the SDK installation. In all recent versions. So one mistery less.
OTA bootloader entry activated by GPIO
I'd like to enter OTA DFU mode activated by GPIO (a button).
Apologize if this is a silly beginner question but the nomenclature here is a bit confusing for a beginner... bootloaders, apploaders, updaters... so please be gentle.
The board is 4103A with EFR32BG12P332F1024GL125 on a PCB4001.
Created a new bootloader project from template bootloader-storage-internal-single-lzma + GPIO plugin and debugger plugin to see messages.
This works fine with "soc empty" main firmware. I can activate OTA from the SiLabs android app, it reboots in OTA mode properly.
But when I press the button, the bootloader prints:
Slot: 00000000
Verify fail
This is OK because I have not written any update OTA, and the slot is empty.
Then it reboots and keeps looping like so until the button is released. Then it starts in the normal (not OTA) mode.
But I need the MCU to restart in OTA mode, just like if gecko_cmd_system_reset(2) were called.
How to achieve this from a bootloader?
Thanks,
-- dd
Is this the only option? What if the main app has been already partially overwritten by failed OTA update attempt?
What if the bootloader validates the main app and finds it wrong?
-- dd
As far as I know, after a failed OTA update attempt the device will automatically stay in DFU mode. In other words, if your own app is corrupted (due to interrupted OTA upload) then the device will automatically reboot into AppLoader and stay there so that you can try to run the update again. Need someone from Silicon Labs to confirm this, though...
You can test it quite easily yourself: take your update image (application.gbl) and cut a random slice from the end. Then run OTA update with this truncated image. I expect that the target device will stay in DFU mode.
Another simple test would be to reset the development kit during the OTA upload. Again, after the reboot my expectation is that the device will stay in DFU mode.
Thank you Tyler, will test it when I get to work.
If you're correct, this means that the OTA uploader (apploader?)... which, from bootloader's view, is part of the application - keeps another internal flag, besides the reset flags in btl_resetinfo.h , to select whether stay in DFU mode or jump to the user app.
My question is, how to set this flag directly from the bootloader.
Another question - in which demo project or app. note we can find example how a bootloader (uploader? apploader?) can check the gbl file's version (downgrade protection) and product ID/characteristics.
Assume I have two incompatible device models and want to prevent running firmware for a wrong model, even if the file download was successful and passed integrity check (CRC?)
-- dd
> how a bootloader (uploader? apploader?) can check the gbl file's version
This feature should be in plugin "Core/Application update version check", in file btl_parser_app_version.check.c.
But this file does not exist in the SDK installation. In all recent versions. So one mistery less.
-- dd
Ping?