Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
I'm currently integrating the BCM4343W, integrated in the Type 1DX, with a STM32L4A6. I'm trying to validate the Bluetooth Low Energy interface on our board. Note that I've done this test using a Nucleo board and the Type 1DX dev kit successfully before, now the objective is to get it to work on our custom board.
I'm getting the following error when running ble_hello_sensor or ble_hello_client:
00:01:00.113000 GKI_exception 65524 getbuf: out of buffers
Note that I've been able to use the WiFi successfully on this custom board.
I have been probing the BLE UART interface between the STM32 and the Type 1DX, and I've noticed that the STM32 asserts its RTS but the Type 1DX doesn't reply with CTS, which sounds like a part of the problem.
Could the fact that the Type 1DX doesn't assert the CTS line lead to having the logs shown above or is it another issue?
The BLE UART interface has with flow_control enabled by default. So if the Type 1DX didn't reply with CTS, normally we could infer from it that its buffer was full, which is consistent to the line "GKI_exception 65524 getbuf: out of buffers".
In summary, I think you did run out of buffers so WICED was telling you "getbuf: out of buffers" and that's why the Type 1DX didn't assert the CTS line because of the lack of buffer.
I suggest you look into the buffer allocation and usage. And this is a frequently encountered problem, like this below: