2022-10-28 08:53 AM
Hi community,
I have devices with own firmware in which I use also the BLE_OTA app with slight modifications to upload updates to my own firmware. Initially I used the app from ST to update the firmware. Then I created a tool in Python for Windows, Linux and macOS to update the firmware. This worked relatively up to a certain point. Before a month, I started creating an application in Bluetooth Web API to do firmware updates. In my first tests, I noticed that it was quite common for the BLE_OTA application to crash for unknown reasons when uploading firmware. In my case, FUS and BLE Stack were version 1.2.0. I did tests on the original version (without my modifications) of BLE_OTA and the same thing. Further on in the BLE_OTA code I ran Watchdog (IWDG) which saves the situation a bit, because at least now I don't have to disconnect power and reconnect as the problem occurs. I'm also doing tests with the tracer running via USB, but I can't catch where the problem lies because the tracer only works on certain levels of code. As further tests I also went back to my tool in Python and the original application from ST thinking that there is a problem with the BLE Web API. The problem is also occurring for my application in Python and I am having problems uploading firmware from the original ST application (I have tested on several of my devices and on a Nucleo with STM32WB55RG - MB1355C) same thing.
Unable to cope with this problem I uploaded the latest BLE Stack v1.14.1. Evidently this stack together with BLE_OTA allows uploading frames up to 245 bytes which speeds up uploading almost 300kB of firmware. On the new BLE Stack so far the problem has only occurred in my case 2 times, such that BLE_OTA stopped and that IWDG had to pick it up. Seemingly better, but the problem still occurs. My application runs on mbed-os and with BLE Stack version 1.14.1 BLE does not start. I described this in another thread. However, going back to the issue of BLE_OTA application hanging, I have questions: