Information held in softdevice

[suke]

Hello.
I have one multirole device and one peripheral device. Both are nRF53832, SDK version is 15.3 and softdevice is s132 6.1.1.
Multirole devices connect to phones as well as peripheral devices.
First, the multirole device connects to the phone. The phone app can then allow the multirole device to connect to a peripheral device. At this time, the multirole device operates concurrently as a central and a peripheral.

It usually works fine. However, the multirole device failed only once. I am in trouble because there is no reproducibility.

With the phone connected to the multirole device, the multirole device begins to connect to the peripheral device. At that time, pairing was not completed normally, and it became impossible to pair from the phone to the multirole device.

It's the same when I restart the power supply, and my iPhone gets "connected failed" when I try to connect to a multirole device.

Even if I rewrite the application program of nRF52832, the error continues, but when I rewrite the soft device, it returns to the normal state.
After that, it works normally.

・ Question
Do you have any information in the memory area of ​​the softdevice?

Thank you in advance.

[Vidar Berg]

Hello,

The Softdevice does not store any persistent data to flash, only the application can to that. When you re-program the Softdevice, are you sure you are not deleting other parts of the memory like the "FDS area" where the BLE bonding information is kept?

Best regards,

Vidar

[suke]

Vidar-san
Thank you for your response.
I have reprogrammed the Aplication program and soft device using nRF go studio. I don't know if I deleted the FDS area etc.
How can I check it?
If I reprogrammed softdevice in nRF go studio and deleted other memory areas such as FDS, I think that is the cause of this bug.

Is it possible that the pairing will not succeed due to the FDS area where the bonding information is stored? When I request a connection from my iPhone, the dialog "connect failed" is displayed immediately and pairing is not possible.
This has happened only once. It is working normally. Since it is not reproducible, I would like to clarify the cause even a little.

[Vidar Berg]

I think one explanation could be that the bonding information for some reason got deleted from the iphone, but not on the peripheral. This will cause the iphone to send a new pairing request on the next request, which the peripheral will likely reject (see https://devzone.nordicsemi.com/f/nordic-q-a/51965/pairing-and-bonding-after-deleting-synchronization).  To verify this you can delete the bonding information on the iphone, then try to re-connect again.

[suke]

Vidar-san

Thank you for your reply.
My multirole device is coded so that it will not refuse pairing when it receives a new pairing request from the iPhone.

case PM_EVT_CONN_SEC_CONFIG_REQ:
{
	pm_peer_delete(p_evt->evt_id);
	pm_conn_sec_config_t conn_sec_config = {.allow_repairing = true};
	pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config);
} break;

Therefore, when I erase only the iPhone bonding information and connect it to the multirole device again, these can pair without problems.

The strange thing is that when the iPhone makes a pairing request to a multirole device, it fails no matter how many times it tries. Even if I erased the bonding information or restarted the iPhone, it was not fixed, but it was fixed by reprogramming the soft device.

I am in trouble because this problem cannot be reproduced. The clue is that it was fixed by rewriting the soft device.

[Vidar Berg]

suke said:

The strange thing is that when the iPhone makes a pairing request to a multirole device, it fails no matter how many times it tries. Even if I erased the bonding information or restarted the iPhone, it was not fixed, but it was fixed by reprogramming the soft device.

I am in trouble because this problem cannot be reproduced. The clue is that it was fixed by rewriting the soft device.

 I'm afraid you will need to reproduce this again in order to find the root cause. It does not make sense that the problem goes away if you just re-program the Softdevice parts in the memory. The debug log may include more information as to why the connection fails.