Skip to main content
LSpad.1
LSpad.1
Associate III
June 4, 2020
Solved

STM32WB55 BLE: aci_gap_create_connection return error 0x41

  • June 4, 2020
  • 1 reply
  • 1089 views

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.
Best answer by LSpad.1

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.1AuthorAnswer
Associate III
June 11, 2020

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.

Terms & ConditionsAccessibility statement