cancel
Showing results for 
Search instead for 
Did you mean: 

WB5M & OTA

JayBeavers
Associate

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).

1 REPLY 1
JayBeavers
Associate

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