DFU OTA nrftoolbox does not automatically reconnect when initiating dfu from application

[Mike]

Hi,

I am developing some DFU OTA firmware for nRF51822, QFAAH0 (v3 silicon, 256kB ROM, 16kB flash), on a custom board, using SD110v8. Both my application and bootloader were adapted from the Keil pack examples.

I am experiencing a funny behaviour using the android nrftoolbox app to perform dfu. The dfu is initiated from the application (not the bootloader).

I believe, the standard procedure is as follows, nrftoolbox tells the device to restart and enter bootloader mode, the device will restart in bootloader and re-advertise itself. nrftoolbox will reconnect to the device which is now in bootloader to continue the update.

My problem is, when I have my own bootloader and application programmed, after I press the UPLOAD button in nrftoolbox, the device will restart itself (enters bootloader mode). However the app does not reconnect to the device, instead it gets stuck in "Connecting..." and eventually timeout. Since now the device is in bootloader, I can press the UPLOAD button again and the dfu will continue without any further issues.

After a bit of debugging, I also discovered that, if I use the sample bootloader + my own application, the dfu process has no issues.

At first glance, this may be an issue in my own bootloader, however, after commenting out almost all of my modifications to the bootloader (so it is pretty much identical to the sample bootloader), nrftoolbox still cannot reconnect once the device is in bootloader mode. Additionally, I can still perform dfu using my bootloader, so the bootloader is PROBABLY working fine. The only problem is nrftoolbox does not reconnect to it, if i initiated dfu from the application.

My question is, how does nrftoolbox handle reconnection to the device when the dfu process is initiated from the application. I suspect that with my own bootloader + application, nrftoolbox cant identify the correct device to reconnect to and continue with the dfu.

Thanks in advance, Mike

[Hung Bui]

Hi Mike,

I suspect that you didn't configured your project to have NoInit RAM section to preserve the peer data from application when switching to bootloader. You can quickly check this by checking the Bluetooth address of your DFU bootloader after it switch from application to bootloader. If it's not the same as your application's but your application address +1, then it's most likely the issue I suspecting.

Configuration for dfu_ble_svc.c needed:

[Mike]

Hi Hung, I have followed your instructions to debug. Indeed, the dfu_ble_get_peer_data() fails. I also looked at the RAW Memory data. For the default bootloader, I see the memory at address 0x3F80 onwards changes when the device restarts from the application. Whereas for my own bootloader, the data at 0x3F80 onwards stays the same (doesnt change at all). This suggests that when using my own bootloader, the peer data is not written to the RAM.

However, my question is, I am using the same application for both cases, why would it only work with one particular bootloader?

Another question I have is, how does the application decide where to put the peer data? As the NoInit RAM section is not set up for the application. So how does the application know that starting from 0x3F80 is the NoInit area?

Thanks a lot. Mike

EDIT: I did a big of debugging on the application side. In particular, where the dfu_app_peer_data_set() is called. I noticed that the value in RAM doesnt get changed at all when this function is called. I added a bit of direct memory manipulation code with pointers, these code however changes the data in the RAM no problem. Please see the code below:

        err_code = dfu_ble_svc_set_peer_data(&m_peer_data); 
                                 // the previous line didnt change anything in the RAM at 0x20003F80
        APP_ERROR_CHECK(err_code);
		
		uint8_t *ptr;
		ptr = (uint8_t*)0x20003F80;
		for (int i=0; i<6; i++) {
			*ptr = (uint8_t) m_peer_data.addr.addr[i];
			ptr++;				
		}
                                 // after the above line, the data in the RAM is changed accordingly