Skip to main content
LSpad.1
Associate III
Jun 4, 2020 2:04 PM UTC
Solved

STM32WB55 BLE: aci_gap_create_connection return error 0x41

Hi,

i have a system with 4 demoboard STM32WB55NUCLEO and 3 STM32WB55DONGLE. One nucleo is a P2P Client, the other 6 are P2P Server. I have modified the examples P2PClient and P2PServer for:

  • direct advertise the client from the 6 servers
  • pair with PASSKEY ENTRY method
  • handle up to 8 connections

What happens: the connection manager that i created in the client connects and pair the servers one by one. The connection, pairing and communication work fine.

When I reboot a server, the client retreive an EVT_DISCONN_COMPLETE in which the state of the connection "i" is reset to APP_BLE_IDLE. When the connection manager relaunch the aci_gap_create_connection to reconnect the server, the return is the error 0x41, that is not in the standard return values of the function.

What is the mistake? Do i have to call some particular function in the EVT_DISCONN_COMPLETE for reset some status? What does mean that error code?

Thanks you in advance

Lorenzo

This topic has been closed for replies.
LSpad.1
LSpad.1Best answer
Associate III
Jun 11, 2020 7:06 AM UTC

After that I tryed to connect 8 devices but right now the BLE Stack full does not support more than 6 master connection. The error i retreived calling the connect function is the same 0x41 that i was retreiving disconnecting and reconnecting.

So I think that the previous problem is a bug of the stack: if you have 6 connection (the maximum) and a connection disconnects and the user core send another connection request the stack thinks that it is full of connection and does not accept it.

1 reply

LSpad.1
LSpad.1AuthorBest answer
Associate III
Jun 11, 2020 7:06 AM UTC

After that I tryed to connect 8 devices but right now the BLE Stack full does not support more than 6 master connection. The error i retreived calling the connect function is the same 0x41 that i was retreiving disconnecting and reconnecting.

So I think that the previous problem is a bug of the stack: if you have 6 connection (the maximum) and a connection disconnects and the user core send another connection request the stack thinks that it is full of connection and does not accept it.