Flashing Multiple Files for DFU OTA

[UVP]

Hello Everyone,

We wanted to program nRF52840 chip with Zigbee based application using Flash Runner device which we are using for our production programming,.

In Our application we have DFU OTA feature so as required we have to program 3 Files in the nRF chip (mbr, bootloader and client(application) file).

Now using Flash runner i can program the nRF chip and where the base application code works properly, However when i try to do  DFU OTA it gets stuck at 2.17%, 

However when i program the same with nRF utility and command line tools the DFU OTA is working properly.

So i am not able to understand what is the issue, is there any specifuic care to be taken regarding programming from nRF side ?

Also can we combine all the three files into one file using nRF utilty and then use it ?

Just FYI

Also I observe that there is sector erase before programming the client(application) so is this causing a issue because in flash runner the files get direclty dumped after intiall erase.

I am not sure whether it is right approach however as per my understanding I tried following steps for sector erase part,

1. Dumped mbr and bootloader file using Flash runner.

2. Dumped client(application) code using nRF utility (with sector erase).

But still my code gets stuck in DFU OTA.

I request to please suggest me if any possiblities on nRF side to solve the issue. In the mean time i am also in contact with the Flash runner team.

Thanks and Regards

Utkarash

[Edvin]

Hello Utkarash,

I am not familiar with the Flash Runner myself, but if you say that the behavior is different based on what you use to flash it, my first thought is that it may have to do with the device being reset between the 3 files when you program the device using the flash runner?

To verify this, you can try to flash the 3 files separately, in the same order that you do in the flash runner, and reset the device between each flash operation, and then see if it behaves the same.

That being said, a simple workaround can be to merge the 3 hex files prior to flashing them with Flash Runner. Assuming you have nrfjprog (nRF Command Line Tools) installed, you can use the command:

mergehex -m <file1.hex> <file2.hex> <file3.hex> -o <output_file.hex>

This will combine file 1, 2 and 3 into one file named "output_file.hex". You should call it without the "<" and ">".

Try that, and let me know if it doesn't work.

Best regards,

Edvin

[UVP]

Hello Edvin,

Thank you for the suggestion and help,

I tried the step you mentioned of merging the file, However again i am facing same issue,

That is even if i merge the file and dump the merged file through Flash runner, all the other features work propely however only the DFU OTA part fails.

Also when i dump the same merged file through nRF utility the code works fine.

I am currently looking at other possiblities with flash runner team, However i would always welcome any of your sugggestion from nRF side through which i can get out of this issue.

Once again thank you for all your support and suggestions

Regards 

Utkarash

[Edvin]

Hello Utkarash,

Have you tried flashing using the Flash Runner, and then read back the flash using:

nrfjprog --readcode my_flash_runner_dump.hex

And then try to the flash after you program using nrfjprog to program the same file, and then read it back:

nrfjprog --readcode my_nrfjprog_dump.hex

And compare the two dumps. (You can of course also compare it to the original merged .hex file, but reading it back will add the empty (0xFF) padding, so that it is easier to compare the two readouts using a diff tool, such as Meld (the one I personally use). 

If you want to, you can upload the dumps here, and I can have a look, but please be aware that this ticket is public.

Best regards,
Edvin

[UVP]

Hello Edvin,

Thank you for the suggestion and quick response,

As per your suggestion I read out the files and made the comparion of both the files, i.e., File dumped from Flash Runner and File dumped from nRF Ultility, using meld and I see that these files are not Identicall the last part of the file has differences.

And as per myunderstanding which is the bootloader related file.

If i am not wrong i guess that when i am Dumping the file using Flash runner some part of code is not dumped properly.

Also for double checking I made the comparision with both types of file, that is by dumping and reading the merged file as well as dumping and reading Multiple files.But for bothe the result is same

I am in contact with Flash Runner Team w. r. to the same, Once again thank you for all the suggestion and help If any more suggestion from your side are always wecomed

Thanks and regards 

Utkarash

[Edvin]

Hello Utkarash,

Can you see from what flash address the .hex files are different? If you don't want to upload the entire flash dump, perhaps a screenshot showing a line or two from where they differ? You can also change the public/private key for this, to not share sensitive information. It would be interesting to know whether it is the bootloader itself, or the bootloader settings that changes between the two flashing tools. 

BR,

Edvin

[UVP]

Hello Edvin,

Thank you for your feedback,

Please find the attcahed images as per your request, And thank you for understanding that i cannot share the whole file for comparison.

First address location where I can see the difference.

Second address location where I see the difference,

Third start address location where i see the difference,

Also i would like share with you one of my observation, in case you can add your suggestions if any.

In flash runner there were two options while programming, where one was Erase all memories, and other is earse UICR memory, So prior to this i was only trying out with Erase all memeories as this was the sucessfully use case for most of the chips.

But now i am working with both options of erasing all memory and UICR memory considering this may be the problem, 

You can add up you view or suggestion if any on the same.

Thanks and Regards 

Utkarash

[Edvin]

Hello Utkarash,

It was not that easy to guess based on these lines. Can you check (for each of the screenshots above) for a line starting with :02000004... 

For each of the lines, find the line starting with that above the line in the screenshot. What does that line say?

(the line starting with :02000004 indicates the flash area. It will probably say one of these:

:020000040000FA

:020000050001F9

:020000040002F8

:020000040003F7 

and so on ...

where 0000, 0001 or 0002 indicates whether the flash address is starting on 0x0000 0000, 0x0001 0000 or 0x0002 0000, and so on...

Either way, seeing that these looks like some sort of settings page, I would guess that they are bootloader settings or FDS pages (either for your application, or for the peer manager).

So can you please check these lines mentioned above for each of the screenshots, 1, 2 and 3?

In addition, Do you use FDS for anything custom in your application, or is it only the zigbee stack using the non-volatile memory?

Lastly, what SDK version do you use? nRF5 SDK for Thread and Zigbee, or NCS? If it is the first one, do you use the standard zigbee bootloader from the SDK? 

And is it the left or right that is the working flash? (the one with FFFFFFFF or the one with data in it?)

Best regards,

Edvin