nRF52840 combining ble_app_blinky + ble_app_buttonless_dfu

[fe-hadella]

I am working with an nRF52840 on a custom board. Our device has a number of sensor attached in various ways including spim, twim, uart. I've used the ble_app_blinky as a starting point, and have a app that is doing things periodically, but has integrated a number of custom ble services which interact with a ble app. For testing, I've been typically been using nRF Connect on an Android tablet. The app has morphed over a period of a few weeks, but is functional. However, I've also been using the open bootloader and usb to update the firmware.

Recently, I've adapted the ble_app_buttonless_dfu to work on our custom board. I've also adapted the secure_bootloader project for our board. Along these lines, I've been able to use the DFU tool in the nRF toolbox app for Android to update the device firmware.

The next step was to integrate the buttonless dfu into our previously working app. I've ran into some trouble, and need some advice on how to proceed.

I have made a few clones of the app so I can experiment, and describe the behavior I am seeing. It appears much of the base code in ble_app_blinky and ble_app_buttonless_dfu is similar. The primary difference I see is the advertising mechanism. I have one version using the advertising scheme from the buttonless dfu app. When I run this version, after the  advertising_start() function, the app will report:

<error> app: Fatal error
<warning> app: System reset

and then reboot. This process repeats continually.

A second clone of the app uses the advertising scheme from the ble_app_blinky project. The calls are very different as are the data structures. When I run the app in this case, it gets through all the initialization code, and appears to run correctly. However, when I try to "connect" using a nrf connect, the app will immediately report the same fatal error and reset. The app will run just fine right until I try to connect.

The sdk_config.h files for each project is based on the base project's files, but have been modified to make the code run. The ble_app_blinky version is much more complex. I've attempted to use that one as the starting point, and have added the missing parts so the project compiles and runs. This is the place I've usually needed to edit to make things work in other projects.

I also made a third clone, but this time used the buttonless_dfu's sdk_config.h as the starting point, and added the missing content from the ble_app_blinky's config file. This project is currently failing much earlier. I have code which uses a button to trigger some code. The call to ble_lbs_init() is causing immediate failure and reboot.

Sorry for the long message, but been stumped on making any progress on this.

[fe-hadella]

Any thoughts on the output I sent?

In the meantime, I've started a new fw project this time starting from the `ble_app_buttonless_dfu`. At this point, I've added all the drivers and services the other app had. So far, it seems to work fine, meaning it doesn't fault when someone tries to connect to it. I've been able to do a number of updates with this project. However, I have a few questions based on observations.

I've noticed that if I enable a timer and have some periodic function being run, I've had issues with the app disconnecting very often when I connect. If I make just one change and don't start the timer, connections are stable for a long time. In our end app, this is remote field sensor which will do tasks at a minimum of 60 second intervals. This will be in cold conditions, so I had a timer which would run every 1 second to make sure the temp was ok. I will likely use interrupts instead of a timer to control this heater controller, but I would like to know why using an app_timer would cause issue with connectivity.

In the `ble_dfu_evt_handler()` function, should I use the BLE_DFU_EVT_BOOTLOADER_ENTER_PREPARE case to stop any timers or shutdown things like drivers before the update starts? In one case where I had a 1 s timed activity, the app would lose connectivity before the update would start due to the timer issue I described above.

On the old firmware I started the ticket from, I had a number of functions being called in the main loop. I've noticed that in this new app, I've made the main loop very simple.

for (;;)

{

   idle_state_handle();

}

Could this possibly explain the connect issue from before? In that firmware, there was some logic and various function calls beyond the `idle_state_handle()`.

[Vidar Berg]

Hello,

fe-hadella said:

Any thoughts on the output I sent?

I see you were getting a NRF_ERROR_NO_MEM error at line 1149 & 1154 in main.c, but I can't tell what function call you have (or had) at this line in your project, and it's important to know which as there are several SDK/Softdevice calls that may potentially return this error.

fe-hadella said:

I've noticed that if I enable a timer and have some periodic function being run, I've had issues with the app disconnecting very often when I connect. If I make just one change and don't start the timer, connections are stable for a long time. In our end app, this is remote field sensor which will do tasks at a minimum of 60 second intervals. This will be in cold conditions, so I had a timer which would run every 1 second to make sure the temp was ok. I will likely use interrupts instead of a timer to control this heater controller, but I would like to know why using an app_timer would cause issue with connectivity.

 Sudden disconnects are usually caused by runtime errors which invoke the app_error_fault_handler(). If you haven't already, could you please try debugging the app while the disconnect occurs to see if the program becomes stuck somewhere?

fe-hadella said:

In the `ble_dfu_evt_handler()` function, should I use the BLE_DFU_EVT_BOOTLOADER_ENTER_PREPARE case to stop any timers or shutdown things like drivers before the update starts? In one case where I had a 1 s timed activity, the app would lose connectivity before the update would start due to the timer issue I described above.

This depends a bit on your application. For many applications it may be ok to just let the app_shutdown_handler() enter DFU right away, while others may require a more "graceful" shutdown. Note that the Device is reset before entering the Bootloader anyway the application state prior to DFU should not impact the update process.

fe-hadella said:

Could this possibly explain the connect issue from before? In that firmware, there was some logic and various function calls beyond the `idle_state_handle()`.

It's not a problem in itself to have much of the application logic placed in the main loop. Maybe the NRF_ERROR_NO_MEM error was returned from the main loop earlier.?

Best regards,

Vidar