2024-09-11 12:29 PM
Hello,
I have developed a custom board around the WB5M and I am working on adding OTA support to it using the sample code from CubeWB -> Projects -> NUCLEO-WV15CC -> Applications -> BLE -> BLE_Ota.
I have modified this code to use CMake (following the pattern of my app firmware which is customized from a template CubeMX / CMake application) and then made the changes to the sample app to use stm32wbxx_hal_driver and CMSIS_device_wb with STM32WB5Mxx defined. I have turned off CFG_LED_SUPPORTED and CFG_BUTTON_SUPPORTED since there is no BSP associated with my custom board.
So far the code compiles, flashes, and seems to be trivially working -- e.g. I can use a BLE app to see advertisements for BLECore with Local Name STM_OTA with the manufacturing data in the advertisement. I can connect/disconnect to the device, though no services are advertised (I believe this is 'normal' OTA behavior?). I have not yet connected an OTA app to attempt a firmware flash. I do see the occasional hard fault when I pause/resume my Ozone debugger, but the firmware seems to be stable if I don't pause/resume.
My firmware is larger than the sample binaries hex files (43k for Nucleo WB15, 42k for Nucleo WB55, 87k for my hex file). I am using toolchain CMake / GCC 13.3.rel1 with debug (-g3 -O0) so I expect there to be differences in outcome. When I load my .elf file into CubeProgrammer, I see size == 0x783A and when I browse the memory footprint it extends out to 0x08007830. My only current code customization is a substitute Error_Handler() which flashes a red LED on my custom board.
So, my question is I assume I need to change the loading address of my app firmware from 0x08007000 to 0x08008000 to accommodate the fact that my ble_ota.elf is a bit larger than the prebuilt ble_ota_reference.hex. When I open up the ble_ota_reference.hex in CubeProgrammer it is *much* smaller, with size == 0x3CF0 and an ending address of 0x08003CE0.
As I understand it, this will require me to modify CFG_APP_START_SECTOR_INDEX from 14 to 15. And I also want to confirm that this change is "enough" especially given that the size difference between my binary is pretty large -- 0x783A vs 0x3CF0.
I have also tried a release build with -g0 -Os and this produces output of size 0x3FC5 which is closer to the ble_ota_reference size. My preference is to use a debug build as I wish to expand the OTA code to also support per-device provisioning via new characteristic(s) (e.g. serial number, factory configuration settings).
2024-09-12 10:04 AM
What I don't understand about the OTA design is that the reference firmware has a size of 0x3CF0 and looks like it only needs the reserved flash space of 0x08000000...0x08003CE0, but the location of the application is set to 0x08007000 which leaves 0x08004000...0x08006FFF unused. I *think* this is just a 'conservative' setting so if someone recompiles the firmware and it grows in size, there won't be an immediate flash overlap problem, but I want to be sure there isn't something I'm missing.
I want to modify the OTA firmware, both to add some additional features and to enable debugging, but I want to make sure I'm calculating a new app location correctly, so I want to ensure I understand the design principal by which the OTA firmware works fully.
Thanks in advance for your help,
- Jay
2024-10-14 08:16 AM - edited 2024-10-14 08:19 AM
Hello @JayBeavers
Could you give more details and specify exactly your needs. You can also refer to the AN5247 for more details about the OTA on a STM32WB.
Best Regards.
STTwo-32
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.