Issue with merge file when uploaded over BLE dfu

[BIPIN]

Hi,

I have developed two different application on nRF51822 with two different location. One is start from 0x1D000 with max size of 16 KB and another start from 0x21000 with max size of 60 KB. I have merge two hex file generated from these two application using mergehex. my first application jump on second application depending on some condition.

When i download this merge file using nRFgo studio then it works fine. Application 1 jump on application2 successfully.

But When i upload this merge file over BLE DFU using nRF Toolbox, then only Application 1 work ok but it doesn't jump on Application 2.

when I have checked from keil memory window during debug then i found that nRF Toolbox has uploaded merge file without filling gap by 0xFF in between hex file1 and 2.

Is any solution is available to fill used space by 0xFF for hex file with max size?

Thanks Bipin Patel

[Wojtek]

What is the difference between gap filled with 0xFF or filled with garbage bytes? Shouldn't your app just jump to specific address? I would search for the problem elsewhere.

[BIPIN]

Hi Wojtek,

Actually I know problem and it is with nRF Toolbox. when i pass merge hex file to toolbox for DFU it doesn't fill 0xff into space between end of first hex file and start on next hex file. so memory location of second hex file going to change in nordic flash. So only first application execute not second.

So is that any way so i can fill 0xff for remaining space in hex file?

Thanks Bipin Patel

[Wojtek]

So, do i understand correctly? you have one hex file that starts with (just for example) 0x0000 and size 0x1000, and other one that starts on 0x2000 with size 0x1000. So in bin file there should be: 0x0000-0x1000(app1), 0x1000-0x2000 (0xFFs), 0x2000-0x1000 (app2) but you have bin that looks like 0-0x1000(app1), 0x1000-0x2000 (app2) which is wrong, right?

Have you tried generating bin file in nrfutils? Maybe try preparing .bin file manually? (just add proper amount of 0xFFs in some hex editor?) I think it is problem with your .bin file generator, not nrf toolbox itself. There may also be (i don't know - haven't checked that) bug in nrfutils if you are using it to generate .bin. When generating file for use with bootloader, it cuts out part of bin which is responsible for UICR register which is quite far in memory, just after lots of 0xFFs. I think this feature MAY be problem here.

[BIPIN]

Hi Wojtek,

you are right. Same thing happens as you have describe. Problem is with nrf toolbox utility which doesn't padd 0xFF in gap and gives me firmware without padding of 0xFF over ble. I am using .hex file, not .bin file so adding 0xFF manually is some what difficult.

Can i use bin file instead of hex file in nrf toolbox for DFU?

Is any other sollution?

Thanks Bipin Patel

[bjorn-spockeli]

We have been unable to reproduce the behavior you described with nrf toolbox on both Android and iOS. For test we made an image with two data sections; 0x18000-0x1D500 and 0x29000 - 0x29400. The padding in-between was kept. Have you verified that the binary image in the distribution zip does in fact include the necessary byte padding?