k_sem_take failed with err -11

[OldSix]

I used STM32f767 as the BLE host to compile the central demo, and the execution program encountered a similar error.

cmd：west build -b nucleo_f767zi samples/bluetooth/centra

l

[Vidar Berg]

Hello,

The assertion you got indicates that there is a communication issue between the host and controller. Could you please provide a bit more details about your setup? For instance, what Bluetooth controller you are using and how you have it connected to your host. 

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/connectivity/bluetooth/bluetooth-arch.html#bluetooth-stack-architecture 

Best regards,

Vidar

[OldSix]

Vidar, 

The controller is the chip of our company (there is no problem using other host tests).
The host and controller use uart for communication, I am using uart2 port.
The TX and RX pins of the host are cross-connected with the TX and RX pins that control it.
I do not use uart_ Rts and uart_ Cts, I think it's OK to use only TX and RX.
But I'm not sure whether there is a problem with my serial port configuration. Here is my configuration.

     

Best regards，

OldSix

[Vidar Berg]

Are you able to get debug logs from the controller as well? It would be helpful to know if it is receiving any HCI commands at all.

Also, what chip do you use on the controller side?

[OldSix]

After commenting this part of code, I can grab Bluetooth data on the uart tx pin, but this method may be wrong because it still crashes and the controller does not respond. The controller chip is involved in product confidentiality. I can't tell you the model for the time being. Please forgive me.

This is the crash stack，it's driving me crazy.

[Vidar Berg]

Yes, I was asking if it was possible to debug or get debug logs from the controller chip. I would also need to know if you are using a Nordic nRF chip or another third-party IC for the controller.

[OldSix]

I used third-party IC for the controller.I can't get debug log from controller. It is possible that the controller has enabled hardware flow control, resulting in the inability to receive the uart data of the host. But I don't think this should be the reason of the above code to crash.

[Vidar Berg]

Like I mentioned earlier, the assert indicates that there is a communication issue between the devices. If you can't debug the controller, then I suggest you probe the signals with a logic analyzer/scope to see what is being transmitted and received. 

For reliable communication, HW flow control may be necessary depending on the controller implementation and the UART host driver.