OTA firmware built using Cube 1.23 not compatible with earlier installed BLE_Ota bootloaders

[Adrian Adamson]

This is a big problem for me, as I have thousands of products out there using the older BLE_OTA bootloaders, bootloaders which themselves are not updatable by OTA.   I have a custom phone app for iOS and Android that interfaces with these products and provides OTA updates.

I was about to release an update to the product firmware via my phone app that incorporates several important fixes, but in regression testing this firmware, I found that older units could not successfully perform OTA updates using my new firmware (though units programmed with the updated bootloader could).   I tried many combinations to see what worked and what doesn't work, before narrowing the problem down:

FUS	Bootloader	Stack	Stack location	Firmware Git hash	Result + notes
0	1.23 plus			b87d60	Worked like normal the second time.
1.2.0.0	1.20.0	1.20.0.2	0x805A000	b87d60	No STM_OTA when commanded
1.2.0.0	1.20.0	1.22.0.2	0x805C000	b87d60	No STM_OTA when commanded
1.2.0.0	1.23 plus	1.22.0.2	0x805C000	b87d60	Worked.  OTA did not revert stack to 1.20.0
1.2.0.0	1.23 plus	1.20.0	0x805A000	b87d60	Worked, but afterward it says the stack is 1.22.
1.2.0.0	1.23 plus	1.20.0	0x805A000	b87d60	Deleted stack then reprogrammed and started stack.  OTA worked.  FUS info says stack is 1.22.0 after OTA
1.2.0.0	1.23 plus	1.20.0		b87d60	Re-deleted stack, loaded 1.20, re-confirmed 1.20 still there.  Did OTA successfully.  OTA definitely updated stack to 1.22
1.2	1.20.0	1.20.0	0x805A000	6b9a52a	firmware from 9/8 after 1.23 cube updates, but without OTA characteristic.  No response to OTA request
1.2	1.20.0	1.20.0	0x805A000	abc61fb	Firmware before 1.23 cube update.   OTA working.   Result is an update to 1.22 stack and firmware b87d60 and the app thinking the SN is 0 until forget and re-advertise
1.2.0.0	1.20.0	1.20.0.2	0x805A000	b87d60	No STM_OTA when commanded

The last firmware that can perform OTA updates using BLE_OTA bootloaders from Cube 1.20 or older was what I made using Cube 1.22.   The firmware I built after updating to Cube 1.23 had the following symptom when used with a previously installed BLE_Ota bootloader:    I could initiate an OTA update from my app, and it rebooted into the bootloader, but then the bootloader would get stuck without advertising the usual STM_OTA, apparently before erasing anything.   A power cycle of the device would recover operation using the current firmware and BLE stack.  This is the "No STM_OTA when commanded" result in the table above.

[TDK]

What is the full part number of the chip you are using? STM32WB encompasses too much.

[Adrian Adamson]

STM32WB55CEU.    I think I am also going to have this problem with another product that uses STM32WB55RGV.

I suspect that most if not all of this problem is coming from the fact that the release notes for 1.23 wireless binaries say that you need to upgrade the FUS to 2.1 in order to load the 1.23 version of the stack.   My phone app cannot currently do this.  When I was experimenting with this when 1.23 came out, I was unsuccessful in using the new FUS but I don't remember the details.   This might be too big of a hurdle to make it worth continuing to keep up with future cube upgrades for these 2 products.

[Adrian Adamson]

I'm working on new firmware built from the 1.22 Cube that incorporates the other git commits that I have made in the last 3 months and I'm hoping it will be able to perform further OTA updates.

[TDK]

> the release notes for 1.23 wireless binaries say that you need to upgrade the FUS to 2.1 in order to load the 1.23 version of the stack

It seems like that exactly describe the issue you're facing. I don't think upgrading the wireless binary without upgrading FUS is a viable strategy.

[Adrian Adamson · Accepted solution]

My current strategy is to leave the FUS at 1.2.0.0, leave the BLE stack at 1.22.02, and figure out what I need to do differently in the firmware to allow the OTA to happen.

Update:  I realized that 6b9a52a was not a good test case for whether building my app from the STMCube 1.23 repository update matters, because that commit was missing the BLE OTA enabled flag, so it wasn't going to work regardless.   I made a new build that started from the commit with the 1.23 cube update but cherry picked other commits, and that build can successfully perform an OTA.  The change that I needed to leave out is disabling the LSE crystal.   I would have thought that the BLE_Ota bootloader from the the Cube 1.20 would configure the LSE as it needs to, but for some reason, disabling the LSE in my own application carries over somehow into the BLE_Ota bootloader.

Bottom line though, is that firmware using the 1.23 Cube repository CAN be compatible with the 1.20 BLE_Ota bootloader, so my title is now wrong.