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

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

R. Kawajiri — Thu, 12 Nov 2015 23:56:41 GMT

Hi, I am working with gcc. Could you tell me how to configure similar one with gcc?

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

Spirit — Fri, 02 Oct 2015 22:18:05 GMT

@Mike I have an identical problem from your very firs post. I configured Zero Initialized Data to IRAM2 as @Hung Bui said, but the problem still persist :( Could you plesase send me your code?

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

Mike — Sun, 24 May 2015 07:24:44 GMT

Hi Hung, your solution worked. Thank you so much for your help! -Mike

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

Hung Bui — Thu, 21 May 2015 13:51:05 GMT

@Mike: Looking at your code, I haven't seen the dfu_ble_svc.c file's option has been configured with Zero Initialized Data to IRAM2. As shown in my answer above.

After configured that, I managed to use your bootloader to update with bonding re-encrypted (hrs with dfu application).

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

Mike — Wed, 20 May 2015 12:08:08 GMT

Hi Hung, I have created a case on mypage. The project is setup for my custom board, but it should load just fine on the new pca10028 dev board too.

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

Hung Bui — Tue, 12 May 2015 09:31:20 GMT

@Mike: sorry for that late response, I was on vacation.

"how does the application decide where to put the peer data?": The application doesn't do the work to put data to the No-int area, it's the SVC call dfu_ble_svc_set_peer_data() that will jump to dfu_ble_set_peer_data in the bootloader code. In side that dfu_ble_set_peer_data() it will copy the data from source (m_peer_data from application) to destination (no-init area).

I'm not sure why the SVC call didn't work or it couldn't modify the No-init RAM area. If possible please send me your bootloader project file, I can try to reproduce the issue here.

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

Mike — Thu, 07 May 2015 15:43:07 GMT

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

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

Hung Bui — Thu, 07 May 2015 12:09:10 GMT

@Mike: You can follow this instruction to set bootloader in debug mode.

When running in debug mode, you can add a break point at dfu_transport_update_start() in bootloader.c to see what will be executed when you jump from application to bootloader. Most likely the dfu_ble_get_peer_data() has returned fail. Then you can check if the peer_data is set properly in your application by adding breakpoint at dfu_app_peer_data_set() in application and dfu_ble_set_peer_data() in bootloader

You should also check if dfu_ble_svc.c file's option has been set with Memory Assignment to Zero Initialized Data (IRAM2).

I would suggest you to use the no pack SDK's zip version instead of basing on the pack. It's easier to modify without using pack.

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

Mike — Wed, 06 May 2015 16:20:36 GMT

Hi Hung, I think I finally fully understand what you mentioned earlier, regarding the address +1 issue. I did a bit of debugging and found that the MAC address agrees exactly for each of the 5 steps you talked about, if im using the default codes. In particular, in step 4, the advertising name is actually n/a and the MAC address is A (not A+1).

So this means, in my own bootloader, somehow the reset didnt work as expected. Would you have any suggestion in where to look for potential causes for the A+1 issue in Step 4? I'm certain that the NoInit button is ticked for the last 0x80 bytes of RAM. And my RAM layout is as follows:

IRAM1 0x20002000 0x1F80
IRAM2 0x20003F80 0x0080 NoInit

Also, FYI, the reason why I did my own DFU bootloader is I wanted to have both BLE and Serial, hence I have separated out many .c and .h files from the PACK, these are:

bootloader.c
bootloader_settings_arm.c
bootloader_util_arm.c
dfu_dual_bank.c
dfu_init_template.c
dfu_transport_ble.c
dfu_transport_serial.c
hci_mem_pool.c
hci_slip.c
hci_transport.c

All other required source files are from the Keil PACKS.

Thanks a lot for your time again. Mike.

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

Hung Bui — Wed, 06 May 2015 15:30:24 GMT

@Mike: It's based on the MAC address.

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

Mike — Wed, 06 May 2015 13:59:43 GMT

Hi Hung, Just a quick question first, how does nrftoolbox decide which device to in step 5? does it go by the MAC address? advertising name? or something else.

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

Hung Bui — Wed, 06 May 2015 12:52:49 GMT

@Mike: If the default address (application's address) is A. The correct behaviour should be:

First run of the bootloader , the address should be A+1
After DFU the dfu_test_app_hrm.zip, the address should be A , and the normal application running
After the master connect and discovery service and trigger another DFU.
The central disconnect and the bootloader start with address A, start directed advertising
The central automatically connect to the device and do DFU.

The bootloader should start with address A+1 , only when it is started from power on or from reset not from application (button less).

In your case it advertise with address A+1 at step 4 and 5, which is quite strange. Which master device did you use ? Have you tried with our Master Control Panel on PC ?

Explanation on why we change the address can be found here.

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

Mike — Wed, 06 May 2015 12:34:14 GMT

Hi Hung,

Thanks for the prompt reply.

Firstly, if the bootloader address is the +1 of the application, does that mean its the correct behaviour? Also, does it matter which one is even which one is odd?

As you mentioned, the Bluetooth MAC address in bootloader is +1 of the application. When using both my own bootloader or the sample bootloader.

At the same time, I used the sample code, "dfu_dual_bank_ble_..." from the packs on my development board pca10028. The application I used is the hrm.zip file in the bootloader example's folder. The same behaviour is replicated, the bootloader address is +1 of the application.

Pretty much in all the test scenarios, I have the +1 address happening. The only time when automatic reconnection doesnt work is when using my own bootloader.

Cheers, Mike

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

Hung Bui — Wed, 06 May 2015 11:38:32 GMT

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: