STM32WB55RCV6 stuck in FUS_FW_RUNNING state, wont enter WIRELESS_FW_RUNNING, how to debug?

[ejd1962-questat]

I am using a STM32WB55RCV6 for a BLE project.  I did initial development on the NUCLEO-WB55RG development board and it works ok. Ignoring all other functions, the basic feature I am trying to see work is BLE advertising. 

However, when I move that code to a custom designed board the coprocessor software (that handles BLE wireless functions) seems to be stuck in the FUS state, and never emits the WIRELESS_FW_RUNNING event.  This indicates the coprocessor has not entered the WIRELESS state, so it is not ready to issue advertisements, etc. 

I have confirmed the initialization function is called on the Custom board, as it is in the Nucleo board. 

I have checked key clocks on the Custom board as configured by MX and they seem functionally equivalent to the Nucleo board, namely a SYSCLK of 32 MHz on both, and a RF Timeout clock of 31.25 KHz  (compared to the Nucleo board which has a RF timeout clock of 32.768 KHz).  My assumption is the minor difference in frequency of the RF timeout clock does not matter. 

Note I am using the coprocessor binaries for the full BLE stack. (Not Extended).   This stack is identical for the Nucleo board and the Custom board. 

I am looking for tips on what might cause the coprocessor firmware to get stuck in the FUS state.   Also what else should I be looking for.   Lastly, any tips on how to debug this.  I have read about turning on debug logging but I am unclear if this will emit debug statements from the coprocessor or just from the main application processor. 

Sincere Thanks in Advance!
--- Eric 

[STTwo-32 · Accepted solution]

Hello @ejd1962-questat 

The STM32WB55RCV6 is using the same .bin files for FUS and Stack as the NUCLEO-WB55RG. But the install address is not the same between both MCU. So, please update the stack and FUS using the last version of the .bin files available on the STM32CubeWB V1.21.0. Use the starting Address for the upload of the .bin files mentioned in this table:

Finally, after uploading the Stack and FUS, don't forget to start your Wireless stack using the "Start as Wireless" button: 

Best Regards.

STTwo-32

[ejd1962-questat]

I will try this out and report back.  Many Thanks!  -- Eric 

[ejd1962-questat]

I followed the advice given above and I now receive the WIRELESS_FW_RUNNING event, so that was a great help! *

From the notes above I learned I needed to use the WIRELESS tab on the PROG tool (a small wireless antenna pattern is shown on the icon, which is on the left, at bottom).   In this tab, you can enter the name of 2 binary files to load into flash.  One for the firmware update service, FUS (stm32wb5x_FUS_fw.bin, loaded to 0x0803_c000 ) , and one for the BLE wireless service, WIRELESS ( stm32wb5x_BLE_Stack_full_fw.bin, loaded to 0x0801_c000) .   Each has their own base address embedded in the binary.  After loading both binary files, stay on the same tab, and look over on the right hand side to see info about the FUS version, and below that is a button to START WIRELESS.  You must press that button, instructing the firmware to start the WIRELESS service first, not the FUS service. 

* I am not yet home free, since although I now do get the WIRELESS_FW_RUNNING event, I am immediately hanging the next time I try to issue a hci command because I do not get a response and I wait forever.  In particular, I issue hci_reset(), which calls hci_send_req(), which then waits for a response using hci_cmd_resp_wait(), and the response never comes.      Any suggestions on this issue?