Crash at disconnect + RTT Viewer weird behavior

RE: Crash at disconnect + RTT Viewer weird behavior

Vidar Berg — Wed, 04 Nov 2020 08:51:07 GMT

The PM_EVT_CONN_SEC_FAILED event signals the application that a bonding or link encryption procedure has failed, but you have to check the event data (error code) to find the reason for the failure. Is PM_LOG_ENABLED set to '1' in your project? That should make the PM log the error code like this:

<info> peer_manager_handler: Connection security failed: role: Peripheral, conn_handle: 0x0, procedure: Encryption, error: 4102

Also, I don't think it's related to the failure, but .io_caps should be set BLE_GAP_IO_CAPS_NONE when you are not setting the 'mitm' flag.

RE: Crash at disconnect + RTT Viewer weird behavior

genzy9 — Tue, 03 Nov 2020 09:34:51 GMT

You right. I just put a flag to true when DISCONNECT event is received and it will be handle in my main loop, seems to work for now, we will investigate later.

But the problem might be on our UART so not sure it's all related to the nrf52 chip.

Yes I did not change the default behavior. I am fine with rebooting in case of an error.

Let's consider the previous issue as solved for now.

Could you help me to solve the PM_EVT_CONN_SEC_FAILED ? What does it mean?

I set no security settings from Android side (all default) and from the nrf chip in the pm :

    // Security parameters to be used for all security procedures.
    sec_param.bond           = SEC_PARAM_BOND;
    sec_param.mitm           = 0;
    sec_param.io_caps        = BLE_GAP_IO_CAPS_DISPLAY_ONLY;
    sec_param.oob            = 0;
    sec_param.min_key_size   = 7;
    sec_param.max_key_size   = 16;
    sec_param.kdist_own.enc  = 1;
    sec_param.kdist_own.id   = 1;
    sec_param.kdist_peer.enc = 1;
    sec_param.kdist_peer.id  = 1;

RE: Crash at disconnect + RTT Viewer weird behavior

Vidar Berg — Mon, 02 Nov 2020 12:57:25 GMT

Hi,

It's generally good practice to keep the processing time inside interrupts short, but I'm not sure how it relates to the crash you mentioned. It's also a bit strange that it seems to work ok as long as you are debug mode (note: chip enters debug mode when you start viewing RTT messages). Have you kept the default error handling in your app (see Error module)? This is usually the only place where the app may trigger a reboot.