STM32WB55RCV6 BLE -- after hci_reset() no reply obtained from coprocessor running BLE stack

[EJD1962]

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.

After moving that code to a custom designed board, and booting the coprocessor software (that handles BLE wireless functions) the coprocessor seems to get to the WIRELESS_FW_RUNNING state ok, but then hangs when I try to run hci_reset(). I can see the command is sent in, but nothing comes back and the application processor hangs while waiting.

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 also loaded the FUS binary file. Both went to the correct locations, and I did press the "START WIRELESS" button. I believe the BLE stack is running because it issues the event WIRELESS_FW_RUNNING.

I am looking for tips on what might cause this problem, and any tips on how to debug it. 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.

One other final point, I have lingering doubts about the transmission network and filter, and antenna connection.  I currently doubt that even if antenna components are badly tuned that it could cause the hci_reset() to fail.  But I have read this problem might be attributable to antenna problems or power supply problems.   Thoughts?

Sincere Thanks in Advance!
--- Eric

[Lubos KOUDELKA]

Hello Eric,
as you're mentioning project is running on nucleo, but not on your PCB, would be good to check HW.  In AN5290 and AN5165 you can check guidance for HW design with RF.
Now, for the RF functionality is fundamental to have HSE, LSE is optional.

Please try to set in your project to use HSE/1024 as RF wakeup clock source. Please note stop mode cannot be used when HSE is used as RF wakeup clock source. In main.c look for:

PeriphClkInitStruct.RFWakeUpClockSelection = RCC_RFWKPCLKSOURCE_HSE_DIV1024;

 in app_conf.h:

  #define CFG_BLE_LS_SOURCE  (SHCI_C2_BLE_INIT_CFG_BLE_LS_NOCALIB | SHCI_C2_BLE_INIT_CFG_BLE_LS_MOD5MM_DEV | SHCI_C2_BLE_INIT_CFG_BLE_LS_CLK_HSE_1024)

 In general, if RF wakeup clock source is not accurate, you're missing connection interval -> you can see your device is advertising, but not able to connect to it.
Please verify also SBRV in security option bytes. This value is deciding, if FUS or wireless stack is running on CPU2. SBRV =0x3d000 -> FUS is running on CPU2. Lower value of SBRV mean wireless runs (after enabling CPU2 from CPU1).
Please let me know your outcome.

Best regards,
Lubos