• State Suggested Answer
  • +1 person also asked this people also asked this
  • Replies 25 replies
  • Answers 1 answer
  • Subscribers 75 subscribers
  • Views 6558 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 242891
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Buttonless DFU with bonding

Dani

Good afternoon,

I first devoloped my app based on the nRF52840 (SDK 15.2; S140 V.6.1.0) and it was perfectly working with or without bonds.

After that, and following what it is shown in this link (https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/getting-started-with-nordics-secure-dfu-bootloader), I implemented Buttonless DFU funcntionality without bonds, and it was working fine. Now, I have tried to go ahead and doing the same DFU process with bonds, but application gets stuck when initializing DFU service: it gets stopped at 'ble_dfu_buttonless_init' function, when calling 'ble_dfu_buttonless_backend_init', and the result is 0x0008 (NRF_ERROR_INVALID_STATE). In order to test DFU with bonds, I have carried out the required modifications according to information specified in the link above:

Do you know which can be the reason of such error?

Best regards,

Dani.

Parents
  • 0

    Now, the application is working but when carrying out DFU process, it does not work --> when using 'nRF Connect' desktop application, I get the following message:

    Any suggestion?

    Best regards,

    Dani

  • 0 in reply to Dani

    I found I was getting this message because device was in debug mode. Now, it is not in debug mode but I'm getting a different message:

    Trying to guess which is the problem....

  • 0 in reply to Einar Thorsrud

    Hi Einar,

    In my application, at which point should I call 'pm_local_database_has_changed'?

    Regards,

    Dani

  • 0 in reply to Dani

    Hi dani,

    You can for instance call pm_local_database_has_changed() when you get the PM_EVT_BONDED_PEER_CONNECTED event, but the timing is not critical since it is buffered ant sent when the peer connects if called "too" early. See API doc for pm_local_database_has_changed() for details.

    (Ideally, you should only call pm_local_database_has_changed() the first time the bonded peer connects after a DFU, though the only consequence of calling every time is that the center will perform service discovery every time, which may not be a problem). 

  • 0 in reply to Einar Thorsrud

    Hi Einar,

    I have implemented what you have suggested:

    /**@brief Function for handling Peer Manager events.
 *
 * @param[in] p_evt  Peer Manager event.
 */
static void pm_evt_handler(pm_evt_t const * p_evt)
{
    pm_conn_sec_config_t config;
	
	pm_handler_on_pm_evt(p_evt);
    pm_handler_flash_clean(p_evt);

    switch (p_evt->evt_id)
    {
        case PM_EVT_PEERS_DELETE_SUCCEEDED:
            advertising_start();
            break;
				
		case PM_EVT_CONN_SEC_CONFIG_REQ:
			config.allow_repairing = true;
			pm_conn_sec_config_reply(p_evt->conn_handle, &config);
			break;
				
		case PM_EVT_BONDED_PEER_CONNECTED:
			pm_local_database_has_changed();
			break;

        default:
            break;
    }
}

    And the result is the same.

    I'm using SDK 15.2.0. I do not know if there is any issue related with this and with also what is commented in this thread (https://devzone.nordicsemi.com/f/nordic-q-a/46633/peer-manager-silently-drop-service-changed-indications-if-an-att-mtu-exchange-was-happening/204968#204968)

    Best regards,

    Dani

  • 0 in reply to Dani

    Hi Dani,

    I did not remember that issue, but yes, this could very well be the problem. You can check if the same thing happens in your case using a sniffer, or simply implement the fix as suggested by Vidar in that thread (which you should do anyway).

    With the that fixed I cannot think of any likely reasons for this issue, but if you are still stuck, there are a few things worth doing:

    • Could it be that the phone has cached the services form before you added service changed characteristic to both the bootloader and application (if ever)? If so, then you should remove the bonding information and toggle BLE off and on on the phone to clear it's cache. Then fully erase the nRF and program the bootloader and application again. In this case, the phone should be aware of the issue
    • If still not sure if the phone could have cached something from before service changed characteristic was added, you could change the MAC address of the nRF (remember to do so both in app and bootloader in that case), or simply test with a new phone.
    • If the above also doe snot work, then it would be useful with a sniffer trace to see what is actually happening on-air (is the service change indication sent, ...?)

    Einar

  • 0 in reply to Einar Thorsrud

    Hi Einar,

    Some new information for you:

    Before implementing fix suggested by Vidar, I have directly gone to first point you have suggested in last answer: now, nRFToolbox is crashing but I have succeeded with nRF Connect application. After DFU update, the situation was the same (only DFU services were observed) but after selecting and connecting again to the bonded device, all application services appear again after going to options and selecting 'Refresh Services'.

    Dani.

Reply
  • 0 in reply to Einar Thorsrud

    Hi Einar,

    Some new information for you:

    Before implementing fix suggested by Vidar, I have directly gone to first point you have suggested in last answer: now, nRFToolbox is crashing but I have succeeded with nRF Connect application. After DFU update, the situation was the same (only DFU services were observed) but after selecting and connecting again to the bonded device, all application services appear again after going to options and selecting 'Refresh Services'.

    Dani.

Children
Related
Terms of service