Hi there,
I'm developing a custom application for FUOTA (Firmware Update Over The Air), targeting an STM32WB55-Nucleo devboard. I’m referencing AN5247 and AN5289 and using the BLE_OTA example from STM (open source code in new page). My user application is located at 0x0800 7000.
Description of the Issue
When I perform the update using ST BLE ToolBox-1.4.2 or ST BLE Sensor Classic, the update is performed OK:
- The system reboots into the user application, and the firmware runs as expected.
- I can successfully trigger a reboot into the OTA application from the user app.
However, when I use my custom update application (a business requirement), the OTA does not send the Indicate message nor perform the reset:
- It does not perform a reboot and stays in the OTA mode.
- If I perform a system reset while in OTA mode, the contents of the user application are removed (the Flash beyond 0x0800 7000 is erased).
- (Please see the diagram below for the step where I'm stuck):
I get to this step
What I am Doing
- I write to the Base Address Characteristic with payload {0x02,0x00,0x70,0x00}
(START user application file upload, with address offset +0x7000). - I send the data 20 bytes at a time.
- I transmit a Base Address Characteristic with payload {0x07} to signal the file upload finished.
Inspection of Flash Memory
If I inspect the Flash memory after an unsuccessful update using my custom firmware update app:
- I can see the contents of the Flash are correct and match the .bin that was uploaded.
- I can see the magic keyword address and the magic keyword are present and correct.
BLE Sniffing Results
Using STM's Android apps (BLE Sensor Classic), the system behaves as expected:
- The "File Upload Complete" message is sent (note here that the STM application defines the service UUID, but not the characteristic UUID):
- Then OTA responds with the Indicate message and reboots into the user application:
With my custom app:
- I send the same data and the "File Upload Complete" message (using the service and characteristic UUID's specific in AN5247 rev. 7), but the system does not respond:
What I Have Tried
- Sending the "File Upload Complete" message with either no address field / 1 byte / 2 bytes in the address field.
- Sending a "0x02: File Upload Complete" message followed by a "0x00: STOP all upload" message.
- Ensuring all the data is word-aligned.
- Updating to the latest BLE stack (stm32wb5x_BLE_Stack_full_fw) to v1.20.0.
- Inserting various delays between the final data packet and the "File Upload Complete" packet.
- Removing the VTOR assignment in my firmware's system_stm32wbxx.c file.
- Ensured that the user application clocks the RF System Wakeup from the LSE.
- Confirmed the magic keyword (0x9444 8A29) is being written by my application to the correct location (0x0800 7140) and the linker script reflects this.
- Run the BLE_OTA in debug mode and see it enters the OTAS_STM_UPLOAD_FINISHED state of the OTAS_STM_Notification function when I send the "File Upload Complete" message.
- This confirms that the OTA BLE receives the "File Upload Complete" message.
- However, the OTA exits OTAS_STM_Notification, and the calling OTAS_Event_Handler function will have a return_value of IDLE when I send the "File Upload Complete" message from my custom application.
If I perform the update using the STM32 Android applications mentioned above, then it works just fine.
So I don't think the issue I'm missing something obvious, but I can't see it?
Any help would be appreciated, let me know if there's any additional information that would be useful.
Thanks!
I had a similar problem. Whenever the firmware is updated through OTA loader, the firmware file was successfully transferred but the system just got stuck after then. Even if the the system is restarted, the previous firmware is remaining.
After getting through some struggles, what I found and checked was...
(1) When the flash is entirely formatted (but excepting memory for CPU2 (e.g. after 0x080CB000)) and a fresh OTA loader was installed, the initial application firmware update was successful through OTA . But once any of application firmware was updated, the firmware update through OTA never works. This implies any remaining code other than OTA loader and CPU2 may cause the problem.
(2) In the STM32 BLE Toolbox app, before reboot the device to put into OTA mode, you can specified how much of sectors is going to be erased in the "Custom" tab. If an entire free area (e.g. Sector 7 to 191, total 185 sectors starting from Sector 7) are erased, it was found that any OTA firmware could be successfully and normally updated. I guess this number of sector will be model(memory size)-sensitive. If total number of sector exceeds this value, the device cannot be found in the toolbox because codes in CPU2 sector are deleted.
I am not sure this could solve your problem as well, but please give it a try.
