STM32WB55 ScanRequest stucks in hci_cmd_resp_wait forever after couple of hours of test

[TGUCL.1]

Hi everyone

I have ported p2pClient project to a custom board and kept it running for hew hours.

I`m using the STM32Cube_FW_WB_V1.7.0 ilbraries and and imported system workbench project.

Eveyrthing seems to be working but after 4 hours board was not responsive.

There was no BLE server present during my test and below is the call stack where I got into this loop. It`s interesting that normally there is a timeout associated with the call

  hci_cmd_resp_wait(HCI_TL_DEFAULT_TIMEOUT); //33seconds but I don`t see this being used anywhere.

 

Some backround on the application

I`m running a bacnet task in the main loop which collects sensor data from LPUART (buffered in thread context) and another sensor data received from p2pServer project but during the test p2pServer wasn`t present as I mentioned above.

Does this look familiar , has anyone experienced this before ?

Thanks

[OCatt.1]

Any answers regarding a resolution to this issue?

[Christophe Arnal]

Hello,

1/ HCI_TL_DEFAULT_TIMEOUT is not used and is there for legacy reason. It has no interest in the application.

2/ You are not receiving the response from CPU2 to the command aci_gap_start_general_discovery_proc(). Either the CPU2 is in error or the response has been posted on IPCC but for any reason, CPU1 does not receive it.

I would check if you are getting a IPCC interrupt in response of the command. There are some MSCs in the annexe of the AN5289 that show the flow of API and mechanism involved when sending a command to the CPU2.

3/ Although I believe this is not the root cause, the bacnet task shall be registered to the Sequencer and there shall be no other function in the While(1) loop.

The only case where this implementation could be working fine is when the CPU is kept in RUN mode (ie no call to low power in UTIL_SEQ_Idle() )

Regards.