STM32WB55 - Stuck waiting for FLASH_FLAG_CFGBSY during OTA update & running FreeRTOS

[chris24]

Hi Everyone,

I'm using the P-NUCLEO-WB55 board and seeing an an issue when attempting an OTA firmware using the STBLESensorClassic mobile app running on iOS device. Execution is blocked waiting for the "FLASH_FLAG_CFGBSY"  to clear in FLASH_WaitForLastOperation() in stm32wbxx_hal_flash.c. Please see screenshot below of call stack and location. 

 

Setup

CubeIDE v1.14.1

STM32Cube_FW_WB_V1.21.0

ST BLE Sensor Classic 4.20.1

 

Background

If I use the out of the box OTA example "BLE_Ota" on the P-NUCLEO-WB55 board the OTA update works fine.  However, this example uses the sequencer which is not representative of our end application. We are using FreeRTOS in our end application. In an effort to create an application that is somewhat representative of our end application I've combined/merged the "BLE_Ota" & "BLE_HeartRateFreeRTOS" examples into a single project. With this merged project running on the P-NUCLEO-WB55 board the issue is reproducible. I've attached the project to this thread. The BLE_HeartRateFreeRTOS uses timer 17 for the FreeRTOS time source unlike the BLE_Ota/sequencer example which uses systick. 

 

There are some old posts about similar issues like this one https://forums.freertos.org/t/stm32wb55-flash-sr-cfgbsy-never-clears-when-using-freertos-and-tim1/12300/15 that refer to interrupts firing before the timer instance is initialized. Their solution was to add a NULL guard around the  HAL_TIM_IRQHandler(). I've tried this but the issue persists.

 

I appreciate any input you can provide.

 

Thanks,

 

 

[STTwo-32]

Hello @chris24 and welcome to the ST Community.

I suggest you to ensure that your project migration was fine. You can use the attached guide for help.

Also, please use the last STM32CubeIDE V1.17.0 and try using other mobile app such as the last version of the ST BLE Toolbox or the https://github.com/stm32-hotspot/STM32WB-Web-Bluetooth-App-Interfaces

Best Regards.

STTwo-32

[chris24]

Hi @STTwo-32 ,

 

Thank you for the quick reply.

 

Yes I am familiar with the document you shared and confirmed the project migration follows the instructions in that document. However, the issue still persists. Also, the issue exists with latest version of BLE Toolbox.

 

Thanks,

Chris

[chris24]

Hi @STTwo-32 ,

 

I marked this post as a solution as resolved by accident. Can you please reopen it as its not resolved?

 

Is there any update on this? This issue is reproducible using the P-NUCLEO-WB55 board with the BLE_Ota example running FREERTOS instead of the sequencer as per instructions in Seq_to_FreeRTOS_over_cmsis_os2.docx.

 

Thanks,

Chris 

[OliM]

Unexpected FLASH_FLAG_CFGBSY is with a 99,9% chance a null pointer error somewhere in your code. Multiple colleagues have managed to get this on STM32WB. As soon as you try to write to such a pointer, the controller actually tries to write to flash (since zero is the start of flash if you have boot from flash active) and fails because it wasn't unlocked -> FLASH_FLAG_CFGBSY is set until the next reset.

(this is WBxx specific behavior, e.g. on U5 it is a secure exception, and L0 just ignores it)

[chris24]

Hi @OliM ,

 

Thanks for the response. That explanation makes sense however, I put a watchpoint/data breakpoint at address 0x0 unlocked the flash and repeated the test but the breakpoint never gets hit. Am I missing something? 

 

Since this issue is reproducible with the BLE_Ota example + FreeRTOS port (as per Seq_to_FreeRTOS_over_cmsis_os2.docx) perhaps your colleagues have encountered this specific issue?

 

Thanks,

Chris

[chris24]

Hi @OliM,

 

Is there any update on this? It is reproducible using the two ST examples.

 

Thanks,

Chris

[GuilhemG]

Any update on this issue ? I have the exact same one...

[Christophe Arnal]

Hello,

In 99.99% of the case, this issue is met when the Firmware writes any data in the Flash Area.

In almost 90% of those cases, this is due to null pointer which leads the CPU to write at address 0x00.

However, the write at any address of the Flash (not only 0x00) would provide the same result.

I am not sure how much easy it is to set a breakpoint on any write in range address of the flash.

As far as I know, the MPU could be used to help on this.

I would suggest two way to investigate on this :

1/ If the issue occurs on the very first value you try to write in Flash during FOTA processing, then set the MPU to generate a fault on any write in any part of the flash because that means something has been written in Flash whereas not expected at all.

2/ If the issue occurs after some writing in the Flash during the FOTA processing, then set the MPU to generate a fault on any write in the Flash except the download area. In that case, you may miss some unwanted write in the download slot out of the FOTA processing.

 

In any case, I would strongly recommend to focus on something wrong in the Firmware since so far, I don't think I have seen any other reason whether this has been reported by either customers or internally from ST team.

It should be related to an address in SRAM you need to write to, that has been corrupted and is unexpectedly replaced by an address in the FLASH range. So, instead of updating your variable/buffer, you attempt to write in Flash.

You may have a look as well if some error (especially alignment) are raised in FLASH_SR register. It does not strictly prove anything but if there are alignment error, this would reinforce the idea that the Firmware somewhere is writing in the Flash memory instead of SRAM. This could be of course the case even though no error are raised.

Regards.

 

 

[GuilhemG]

Thanks Christophe, I’ve made some progress on this topic over the past few days. I realized that I had disabled the IWDG initialization call in debug mode, but not the periodic refresh calls. As a result, the refresh was being called on an uninitialized hiwdg (0x00000000?). That was most likely the issue.

I haven’t encountered the problem again since making that change. I hope that was truly the root cause! Time will tell…