After DFU update, device fail to initialize mesh stack configuration

RE: After DFU update, device fail to initialize mesh stack configuration

tesc — Tue, 20 Aug 2024 12:31:55 GMT

Hi,

This error indicates that a Flash page used by Flash manager is corrupted. This may happen in a few different situations:

It may happen if the flash configuration differs between the old and the new application. This could be that the flash area locations differ between the two versions of the application, or that the defragmentation recovery page is located at a different flash page.

It may happen if the new application is larger than the old one, and the new application overwrites parts of flash pages previously used by flash manager. Those pages could have been outside of the application flash before, but now are inside the application flash space and therefore now holds part of the applicaiton instead.

It may happen if during the firmware transfer, the bank for receiving the new applicaiton overlaps with pages used by the flash manager.

If I recall correctly it could also happen if the bootloader itslef is updated, but for some reason the new bootloader is larger than the previous one. However this should not normally happen and so this is less likely to be the cause of the error that you see.

Regards,
Terje

RE: After DFU update, device fail to initialize mesh stack configuration

Danish_Riaz — Wed, 14 Aug 2024 16:37:55 GMT

Hi Terje

addr2line shows assertion is trigger from file flash_manager.c line number 255.

Please find attached image:

Regards,

Danish Riaz

RE: After DFU update, device fail to initialize mesh stack configuration

tesc — Wed, 14 Aug 2024 13:27:12 GMT

Hi,

In order for the files to contain proper debug information, you must build the project as Debug:

Then you should be able to use addr2line to get the exact file and line of the assert, like this:

addr2line.exe -e light_lightness_server_nrf52833_xxAA_s113_7.2.0.elf 0x2AC42

With the current files, without proper debug info, you only get the file name, and a question mark indicating addr2line does not know what is the line number:

flash_manager.c:?

Please note that for a rebuild, the address of the assert will most likely differ, so you will have to do another test to see at what address the assert now happens, and use addr2line to figure out what file and line number correspond to that new address.

If you have difficulties using addr2line, please make sure to do a DEBUG build of the project, and resend the files and provide the new assert address for me to have another look.

Regards,
Terje

RE: After DFU update, device fail to initialize mesh stack configuration

Danish_Riaz — Tue, 13 Aug 2024 17:07:13 GMT

Hi Terje

Please find attached files.

devzone.nordicsemi.com/.../debug_5F00_files.zip

The code works fine without DFU update, mesh stack initialization fails only when we apply DFU update. And I am following steps as given nrf5SDK for mesh "Configuring and performing DFU over Mesh".

Regards: Danish Riaz

RE: After DFU update, device fail to initialize mesh stack configuration

tesc — Tue, 13 Aug 2024 15:09:39 GMT

Hi,

You should see under "Output Files" in the side bar several files that are generated when you build the project. In particular the .map file and the .elf file are useful, for seeing where things are laid out in the binary. Can you share those two files?

If you don't want to share those files in an open case, then please provide the files in a private case and refer to this case.

Regards,
Terje

RE: After DFU update, device fail to initialize mesh stack configuration

Danish_Riaz — Mon, 12 Aug 2024 17:39:27 GMT

Hi Terje

I have debug and take logs.

This image indicates that at this point device execution without essertion.

But after this it return following essersion:

Let me know if there is any further necessary logs needed.

Thanks & Regards: Danish Riaz

RE: After DFU update, device fail to initialize mesh stack configuration

tesc — Mon, 12 Aug 2024 14:01:54 GMT

Hi,

The assert happens on address 0x0002AC42. You will need to either use a tool such as addr2line, or to investigate the .map file (part of the output files of your build), in order to figure out what instructions (file and line of code) lead to the assert. This mapping will be different for different toolchains and for different modifications to the application. It would be best if you reproduce the issue with a debug build, with debug symbols available, and possibly also if you do a debug session in order to get the exact location and/or a full stack trace.

Regards,
Terje