No HCI response to aci_gap_set_discoverable

[jhecht]

Hello!

I am having issues with firmwares on the P-Nucleo-WB55. I started from blank code from CubeMX using AzureRTOS/ThreadX with an added layer of CMSIS and took inspiration from the HeartRateFreeRTOS sample (as it uses CMSIS too). I am currently using the BLE/ZigBee FF dynamic firmware as the project will include communication with ZB devices later on. The ZB stack is not initialized.

I refactored some of the code from the sample and have been able to see all the proper exchanges on the SHCI/HCI layers being successful: getting the firmware version, enabling the C2, resetting HCI, setting the default PHY, configuring various settings (public address, IR/ER, TX power level), enabling GATT then GAP, updating the device name and appearance, setting the IO capabilities and the authentication requirements.

Starting advertisement begins with `aci_gap_set_not_discoverable`, which fails (error 0xC/not allowed) as expected as the device is not discoverable by default.
The next call is to `aci_gap_set_discoverable`, which stops in `hci_send_req` at `hci_cmd_resp_wait` waiting for a response from C2.
After I added some logs, I can see that HCI packets were successfully sent to the C2, but that none were ever read back.
Following other posts in this forum, I also tried to look whether the C2 was in hardfault by reading the shared RAM; it seemed to be working properly.

What could be the cause of this issue? Is there some documentation on how the firmware should behave when they get erroneous HCI frames? Is there any way to get more detailed errors from the C2 so that I can understand what went wrong in my code?

[STTwo-32]

Hello @jhecht 

In this case, the pending task will be blocked forever but you will be still able to schedule those that do not send ACI/HCI command. Could you please check if CPU2 is in hardfault or not (check if there is the hardfault keyword 0x1170FD0F at 0x20030000). Also, you have to verify that the errata 2.2.29 of the ES0394.

Best Regards.

STTwo-32

[jhecht]

Hello,

That is correct, any task not requiring the use of ACI/HCI were still scheduled by the RTOS. However, we are still at the beginning of the project and my task at hand was to make BLE work, and we didn't have much business logic behind it at all.

I did check, and CPU2 was not in hardfault (no hardfault marker at 0x10000000/0x20030000).
Regarding errata 2.2.29 from ES0394, I will check. However I doubt it is relevant as CPU2 was not in hardfault.

Since I posted the original message, I have been able to precise the issue a bit:

• The issue only happens when we use `stm32wb5x_BLE_Zigbee_FFD_dynamic_fw.bin` (version 1.20.0), and not `stm32wb5x_BLE_Stack_full_fw.bin` (also version 1.20.0)
• The issue appeared on my firmware as well as on the BLE HeartRate, BLE HeartRateFreeRTOS and BLE AT Server examples, both in the prebuilt binaries and those I built.

Maybe the issue is related to the lack of initialization of the ZigBee stack? Currently the project I am working on does not have any ZigBee functionality, but will have some later on, which is why I used the BLE+ZigBee firmware in the first place.

[STTwo-32]

Hello @jhecht 

The stm32wb5x_BLE_Zigbee_FFD_dynamic_fw.bin is dedicated for concurrent mode BLE/Zigbee. So, you don't have to use it for an application that has only one mode (BLE, Zigbee, thread...). So, I suggest using the stm32wb5x_BLE_Stack_full_fw.bin for this part. Then you can use a Stack for concurrent mode when you implement the two modes simultaneal. 

Best Regards.

STTwo-32

[jhecht]

Yeah I know it's not needed, but working on hardware that's as close as possible to what will be used at the end of the project is usually a good way to catch some bugs or issues in advance; that was my thought processe on using the BLE+ZigBee dual mode firmware.

Do you know if it this is expected behavior from that firmware? Is there any place where I can find more information and what the actual expected behavior of each firmware is?

[STTwo-32 · Accepted solution]

There should be no issue for using the concurrent stack for a BLE application. But it should be a good idea to use the BLE stack when working on a BLE application. Also, could you try a BLE/Zigbee example with the Concurrent Stack and check if you have an issue.

You can find more data on that referring to the AN5289.

Best Regards.

STTwo-32