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

[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

[UVP]

Hello Edvin,

Sorry i forgot to mention the addresses in the last mail,

Edvin said:

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

First difference is after address  :02000004000EEC, For given below image

and rest all differences are after address :02000004000FEB, For given below images,

Edvin said:

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?

We are using nRF5_SDK_for_Thread_and_Zigbee_v4.1.0. Yes we are using standard DFU OTA zigbee bootloader example as reference.

Edvin said:

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

The right side of the comparison is working, That is code programmed using nRF command line tool.

[Edvin]

Ok, so the addresses of these are:

1: 0x000EF000

2: 0x000F7000

3: 0x000F3000

Neither of these are in the bootloader area, which is from 0xF8000 and up.

Do you use any custom flash storage in your application?

It looks like all of the addresses holds the same data, but in different addresses. What I am not sure of is that these addresses are quite far away from one another. I wouldn't think that the zigbee stack would use flash spanding that far. 

After programming the chip using the two programming methods, can you try to read back the flash without resetting the device? Does all of these turn into 0xFFFFFFFF then? And if so, is the flash identical in those cases?

Best regards,

Edvin

[UVP]

Hello Edvin,

Thank you for all your support and help,

Your suggestion and quick response have helped me a lot to solve my problem

I would like tro inform you that i was able to program the chip using Flash Runner and also my OTA part is working properly,

Though i have done some basic tests I think that now the issue is resolved.

Once again thank a lot for all your help and suggestions.

Thanks and Regards

Utkarash