cancel
Showing results for 
Search instead for 
Did you mean: 

Upgrade BLE stack to v1.6.0 and bricked STM32WB

lukasz2
Associate III

Hello,

I am trying to upgrade BLE stack to version 1.6.0 and there is strange issue.

I can upgrade the stack through SWI/ST-LINK.

The problem is with upgrading the stack over the air.

I have no problems with older versions.

STM32WB configuration: FUS 1.1.0, BLE stack 1.5.0, BLE OTA, BLE_HeartRate_ota.

I use android smartphone with ST BLE Sensor App.

When I am trying to upgrade the stack I got the information on the phone "download completed". The STM32WB resets and after this it is bricked. Even through SWI/ST-LINK I can not connect to the microcontroller.

Anyone tries to do it and deals with the same isssue?

Best Regards

9 REPLIES 9
Remi QUINTIN
ST Employee

Assuming you are using a Nucleo board, can you connect via the USB port?

Can you download all the option bytes?

lukasz2
Associate III

I am using my own hardware, but I can connect st-link. I can download all the option bytes but when should I do it? Before the upgrade attempt to v1.6.0? Because after upgrade attempt the stm32wb is dead.

For more, the problem is with BLE_Ota from cube version 1.3.0. If I use BLE_Ota from cube v 1.6.0 the stm32wb is alive after the upgrade process.

BLE_Ota is the only part of the software that can not be upgraded over the air and this is the next problem.

Remi QUINTIN
ST Employee

Download all the option bytes before the upgrade to understand the initial status and after to understand what may have been wrong.

Issue also a log of the sequence of commands you send to the device so that we can see the upgrade sequence with the possible error messages.

lukasz2
Associate III

OK, I will try to prepare this information. But now I have to check again what happened. Because of before the weekend I had six "dead" devices, but now from these six devices I have four "alive" and two "dead". I mean I can connect through ST-LINK.

Remi QUINTIN
ST Employee

We just discover the reason for such issue.

The problem has been understood and it is not coming from the FUS, neither from the the BLE stack itself but more matters from the way ST BLE Sensor application is downloading the stack Over The Air, especially from the size of the .bin to download and from the BLE OTA app.

The ST BLE Sensor is using 20 bytes paylaod packets. To match this constraint, 4 extra bytes are added by the application to the BLE stack binary.

But this is generating an extra access in the flash memory with rotten data remaining from the previous access.

The BLE stack is always starting with a specific code sequence that helps the FUS discovers the start of the stack when it is loaded in Flash memory.

These extra 4 bytes disturb the FUS that do not detect the start of the BLE stack properly. Hence the error.

This will be corrected in the next version of the CubeWB FW package

If you test with STM32WB_BLE Toolbox, it is not the case, and there is no issue.

So to correct it for the short term, there are two possibilities

  • Use STM32 Toolbox or their own dev to avoid the 4 extra bytes (0x00)
  • Use the attached files where we added more bytes to avoid the duplication of the last bytes – to be used only for OTA. rename it .bin instead of .txt

Hi Remi,

do you know when the next version CubeWB will be released?

Remi QUINTIN
ST Employee

CubeWB FW package V1.7.0 is already online since a few weeks. V1.8.0 should come soon and is currently under final test.

lukasz2
Associate III

I know that v1.7.0 is online. I am waiting for v1.8.0.

Do you know the changelog to v1.8.0 and can you share it before release? I want to check if the current changes will resolve my problems.

lukasz2
Associate III

Or even can you share the test v1.8.0 to me?