nrf52832 mesh bricks after OTA update

RE: nrf52832 mesh bricks after OTA update

Mr Sunshine — Fri, 17 Jul 2020 10:30:13 GMT

thank you for your time, I'll create a new ticket.

Have a great holiday.

RE: nrf52832 mesh bricks after OTA update

Edvin — Fri, 17 Jul 2020 10:12:43 GMT

I will leave for vacation today, so if the new problem is not related to the flash manager, I suggest you create a new ticket with a title that describes the issue.

BR,

Edvin

RE: nrf52832 mesh bricks after OTA update

Edvin — Fri, 17 Jul 2020 10:12:03 GMT

When you do a BL + SD + APP update, you can generate this in one packet, but the process will be split in two. First it will update BL + SD in one go, because the bootloader requires that it always has a compatible SoftDevice.

When this is done, you can see that the device will reset briefly, and nrfutil/nRF Connect will reconnect to the device, and then perform the APP update.

What sort of issue do you see?

Try to only use one --sd-req (the old softdevice, that is already present on the nRF), and then you need to set the --sd-id to the new softdevice version.

But please describe what issue you have? Does the DFU complete? Are you talking about the flash_manager issue, or something else?

RE: nrf52832 mesh bricks after OTA update

Mr Sunshine — Fri, 17 Jul 2020 09:09:55 GMT

I have altered the DFU_APP_DATA_RESERVED to be CODE_PAGE_SIZE * 5 as you suggested, and I set the NRF_DFU_SINGLE_BANK_APP_UPDATES back to 0. The problem seems to be gone if I do a OTA update for first the bootloader and after the application, so thank you for that.

The issue isn't solved if I do an OTA update with a zip file that combines the bootloader, application, and softdevice altogether. It seems that I I use a combined zip that probably the application will be updated first instead of the bootloader. Might it be that I make a mistake when generating a new zip? The code I use is:

 nrfutil pkg generate new_DFU.zip --hw-version 52 --sd-req 0xA8,0xAF --sd-id 0 --softdevice softdevice.hex --bootloader-version 0 --bootloader bootloader.hex --key-file key_node.pem --application-version 0 --application application.hex

RE: nrf52832 mesh bricks after OTA update

Edvin — Thu, 16 Jul 2020 11:57:39 GMT

I see that in SDK15.0.0, the variable is called DFU_APP_DATA_RESERVED, and is defined in nrf_dfu_types.h.

Yes, NRF_DFU_SINGLE_BANK_APP_UPDATES set to 1 may prevent the issue to some degree, but if the application is big enough, the bootloader would start writing over your DFU area instead of throwing an error saying that the app is too big, so I would recommend you set the DFU_APP_DATA_RESERVED correctly.

The reason NRF_DFU_SINGLE_BANK_APP_UPDATES 1 works is that the bootloader will not try to use dual bank, meaning it will delete the application and store the application in the direct placement at first. In this case, it meant that the bootloader didn't use the area of the FDS pages. When it tried to use dual bank, it stored the application in the flash after the original application, because it thought it had space, since the flash manager pages was not protected by DFU_APP_DATA_RESERVED.

Dual bank is better if possible, because then you have a rollback in case something goes wrong during DFU (power loss). If not, the fallback after that would be that the device will start advertising as DfuTarg instead of running the previous application. No crisis, but it is a nice-to-have feature.

So the conclusion is: Set DFU_APP_DATA_RESERVED to protect your flash manager pages. It is a good safety to have, preventing bricked devices, like the update you currently had lead to (if you didn't have a programmer).

Best regards,

Edvin

RE: nrf52832 mesh bricks after OTA update

Mr Sunshine — Thu, 16 Jul 2020 07:44:12 GMT

I might have found a solution. I altered in the sdk_config.h the NRF_DFU_SINGLE_BANK_APP_UPDATES variable from 0 to 1 and updated the bootlader separately through the DFU. After that the application update seems to function without the issues. Is single bank mode a wise way to go?

About your questions to the value of some variables, I'm afraid that what you are doing is primarily treating the symptoms instead of the cause. I think that during the OTA update the bootlader overwrites some of the configuration data which will cause the errors.

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/260172"]What is your DFU_APP_DATA_RESERVED defined as in sdk_config.h in your bootloader? [/quote]

the sdk_config.h in the bootloader doesn't seem to have a DFU_APP_DATA_RESERVED, and I don't see anything similar in the file. I'm using the SDK 15.0.0. this version might lack it.

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/260172"]I your case this size should reflect the distance from the bootloader area 0x70000 to the start of your flash manager (0x6B000), so try setting it to 20480 (or alternatively, 5*CODE_PAGE_SIZE).[/quote]

How can I Alter this size withoud the DFU_APP_DATA_RESERVED in the sdk_config.h?

RE: nrf52832 mesh bricks after OTA update

Edvin — Wed, 15 Jul 2020 13:45:26 GMT

Which of the checks in:

static inline bool metadata_is_valid(const flash_manager_metadata_t * p_metadata)
{
    return (p_metadata->metadata_len != 0xFF &&
            p_metadata->metadata_len >= 8 &&
            p_metadata->page_index != 0xFF &&
            p_metadata->pages_in_area != 0xFF);
}

is it that returns false?

And a difficult question: What flash area is it looking at? To answer this, you need to check where is flash_manager_add() called from in the case where it fails? add_flash_manager(), init_flash_storage() or build_flash_area()? And what is manager_config in that case?

In case:

static void add_flash_manager(void)
{

    static fm_mem_listener_t flash_add_mem_available_struct = {
        .callback = flash_manager_mem_available,
        .p_args = add_flash_manager
    };
    flash_manager_config_t manager_config;
    manager_config.write_complete_cb = flash_write_complete;
    manager_config.invalidate_complete_cb = flash_invalidate_complete;
    manager_config.remove_complete_cb = flash_remove_complete;
    manager_config.min_available_space = WORD_SIZE;
#ifdef ACCESS_FLASH_AREA_LOCATION
    manager_config.p_area = (const flash_manager_page_t *) ACCESS_FLASH_AREA_LOCATION;
#else
    manager_config.p_area = (const flash_manager_page_t *) (((const uint8_t *) dsm_flash_area_get()) - (ACCESS_FLASH_PAGE_COUNT * PAGE_SIZE));
#endif
    manager_config.page_count = ACCESS_FLASH_PAGE_COUNT;
    m_flash_not_ready = true;
    uint32_t status = flash_manager_add(&m_flash_manager, &manager_config);
    if (NRF_SUCCESS != status)
    {
        flash_manager_mem_listener_register(&flash_add_mem_available_struct);
    }
    else
    {
        m_flash_not_ready = false;
    }
}

What is dsm_flash_get()? What address is it pointing to?

In case:

static void build_flash_area(void)
{
    bool success = false;
    flash_manager_config_t manager_config;
    manager_config.write_complete_cb      = flash_write_complete;
    manager_config.invalidate_complete_cb = flash_invalidate_complete;
    manager_config.remove_complete_cb     = flash_remove_complete;
    manager_config.min_available_space    = 0;
    manager_config.p_area = dsm_flash_area_get();
    manager_config.page_count = DSM_FLASH_PAGE_COUNT;

    /* Lock the bearer event handler to ensure that we don't enter and leave the BUILDING state
     * between adding and checking. */
    bearer_event_critical_section_begin();
    if (flash_manager_add(&m_flash_manager, &manager_config) == NRF_SUCCESS)
    {
        /* If we have to build the flash manager, it means that it's new, and there's no metainfo. */
        if (m_flash_manager.internal.state == FM_STATE_BUILDING)
        {
            success = flash_store_metainfo();
        }
        else
        {
            success = true;
        }
    }
    bearer_event_critical_section_end();

    if (success)
    {
        m_flash_is_available = true;
    }
    else
    {
        /* Register the listener and wait for some memory to be freed up before we retry. */
        static fm_mem_listener_t mem_listener = {.callback = flash_mem_listener_callback,
                                                 .p_args = build_flash_area};
        flash_manager_mem_listener_register(&mem_listener);
    }
}

What is: manager_config.p_area = dsm_flash_area_get(); ?

In case:

static void init_flash_storage(void)
{
    flash_manager_config_t config;
    memset(&config, 0, sizeof(config));
    config.min_available_space = 0;
    config.p_area = net_state_flash_area_get();
    config.page_count = NET_FLASH_PAGE_COUNT;
    config.write_complete_cb = flash_write_complete;

    if (flash_manager_add(&m_flash_manager, &config) != NRF_SUCCESS)
    {
        static fm_mem_listener_t mem_listener = {.callback = flash_mem_available,
                                                 .p_args = init_flash_storage};
        flash_manager_mem_listener_register(&mem_listener);
    }
}

What is:

config.p_area = net_state_flash_area_get(); ?

In case you are curious, the net_state_flash_area_get() fetches the bootloader address:

net_state_flash_area_get() -> flash_manager_recovery_page_get() -> flash_manager_defrag_recovery_page_get() -> mp_recovery_area,

which is set in flash_manager_defrag_init():

mp_recovery_area = p_flash_end - FLASH_MANAGER_RECOVERY_PAGE_OFFSET_PAGES - 1; /* pointer arithmetic */

where p_flash_end is:

p_flash_end = (flash_manager_recovery_area_t *) (BOOTLOADERADDR() - PAGE_SIZE);

Which was why I asked for that earlier.

So, what area is it trying to initialize the flash manager on, and which of the checks is it that fails, and what is currently in the flash where you are trying to use?

As for the application .hex file, it has start address 0x26000 and end address 0x4545F, so it is 0x1F45F large (rounded up to 0x20000)

Your screenshot from nRF Connect programmer:

The previous application stops at 0x4BD58 (effectively 0x4C000), and the Flash manager starts at 0x6B000. This means that the free space between the two is 0x6B000-0x4C000 = 0x1F000. But since you are using a BLE bootloader, that should be fine (not background). However, you may want to check that your bootloader saves the correct amount of flash for FDS (flash manager).

What is your DFU_APP_DATA_RESERVED defined as in sdk_config.h in your bootloader? Depending on what SDK version you use, it may have different, but similar name.

I your case this size should reflect the distance from the bootloader area 0x70000 to the start of your flash manager (0x6B000), so try setting it to 20480 (or alternatively, 5*CODE_PAGE_SIZE).

BR,

Edvin

RE: nrf52832 mesh bricks after OTA update

Mr Sunshine — Wed, 15 Jul 2020 10:06:10 GMT

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/260075"] I can give you the zip file so that you can reproduce this through the nRF tools app.[/quote]

I use the nRF toolbox app on android.

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/260075"]And for the new_flash.hex, I was thinking only of the hex file that is generated when you compile the application that you use to generate the DFU image later.[/quote]

I use the new_DFU.zip file given in my previous message for DFU updates. I can give you the application file without the bootloader and softdevice if that is what you mean.

devzone.nordicsemi.com/.../6180.application.hex

in addition (I made a edit in my last message) I went deeper into the flash_area_is_valid() code and I see that the error occurs at p_area[0] of the struct "&p_manager->config.p_area[i].metadata".

RE: nrf52832 mesh bricks after OTA update

Edvin — Wed, 15 Jul 2020 09:12:22 GMT

[quote user="mr sunshine "]Don't you mean .dat file? the generated DFU zip file only includes .dat files and I don't see .bat files. I can give you the zip file so that you can reproduce this through the nRF tools app.[/quote]

No, I meant a script that will perform the DFU when I run it. This way, if I compile the application, and run the script, it would take a DK and start transferring the image. How do you normally perform the DFU?

And for the new_flash.hex, I was thinking only of the hex file that is generated when you compile the application that you use to generate the DFU image later.

BR,

Edvin

RE: nrf52832 mesh bricks after OTA update

Mr Sunshine — Tue, 14 Jul 2020 10:05:10 GMT

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/259859"]Could you send the old application .hex file and the new one, and I can check. [/quote]

Currently I'm stuck so I'll give you the hex files:

devzone.nordicsemi.com/.../flash_5F00_new.hex devzone.nordicsemi.com/.../flash_5F00_old.hex

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/259859"]Did you come any further as to why the flash_area_is_valid() returns false? [/quote]

Sorry wan't able to. I didn't had acces to the J-link, and have to do other work activities. If I look at the flash_area_is_valid() then I see that this goes deeper into scructs.

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/259859"]If not, is there any way for me to reproduce this? Preferably, a .bat script to perform the DFU is welcome, so I don't need to set it up from scratch. It will be faster for both of us[/quote]

Don't you mean .dat file? the generated DFU zip file only includes .dat files and I don't see .bat files. I can give you the zip file so that you can reproduce this through the nRF tools app.

devzone.nordicsemi.com/.../new_5F00_DFU.zip

EDIT:

the new DFU will not continuously reboot because I altered the code that It will ignore the first errors at the start of the program. But if you debug it you can see errors occurring during boot. I altered this for debug purposes.

In addition I went deeper into the flash_area_is_valid() code and can confirm that the error occurs at p_area[0].

RE: nrf52832 mesh bricks after OTA update

Edvin — Tue, 14 Jul 2020 09:31:08 GMT

The size of the nRF52832 is 512kb flash, so I don't think your application is 939kB. The .hex file may be, but this is not translatable to the application size. Could you send the old application .hex file and the new one, and I can check. That is, the old one I can see from your screenshot. If you don't want to send the .hex file, drag and drop the new one to the File Memory layout to the right, and do the same measurement (start and end flash addresses).

Did you come any further as to why the flash_area_is_valid() returns false? If not, is there any way for me to reproduce this? Preferably, a .bat script to perform the DFU is welcome, so I don't need to set it up from scratch. It will be faster for both of us 🙂

Best regards,

Edvin

RE: nrf52832 mesh bricks after OTA update

Mr Sunshine — Tue, 14 Jul 2020 08:16:11 GMT

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/259742"]That is correct. But when you hover your mouse over the different fields. What is the end address of your application, and what is the start address of your FDS (the three green lines)?[/quote]

I made the following images, I hope that these are clear enough:

for some clarification, the following colors are according to nRF Connect:

first black is undefined
second black is "MBR Paramters"
red is "bootloader"
all of green is the "Application"
blue is "Softdevice"
orange is "MBR or Application"

It seems as if the DFU update overwrites some spaces of the Application.

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/259742"]And finally, what is the size of the application that you are updating to?[/quote]

if I look at the .hex file used to flash the original program the size is 939 KB. The new one, although not being flashed, is 864 KB. Reason why the new one is smaller is due to it being on Release configuration while toe original was on debug configuration. I don't know where I have to look to when looking for the file size for the DFU.

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/259742"]If the application image is too big to fit, perhaps it starts eating into the FDS pages. If so, you need to have a temporary middle application:[/quote]

I find this quite odd, current configuration of the devices I use is through a mesh with multiple nodes and one NUS to connect too with a Smart Device. This NUS is bigger in size than the nodes but doesn't show any issues during and after the OTA update while the nodes does. So if the image is too big than this should have surely shown on the NUS, but it currently doesn't. The NUS uses the same nrf52832 chip.

RE: nrf52832 mesh bricks after OTA update

Edvin — Mon, 13 Jul 2020 15:23:38 GMT

[quote user="mr sunshine "]I don't know what it is for, it was like this during development. I assumed it was the free space required for updates. All I know is that red is bootloader, black is bootloader settings, green is application and blue is soft device.[/quote]

That is correct. But when you hover your mouse over the different fields. What is the end address of your application, and what is the start address of your FDS (the three green lines)?

And finally, what is the size of the application that you are updating to?

If the application image is too big to fit, perhaps it starts eating into the FDS pages. If so, you need to have a temporary middle application:

Original application -> DFU -> middle application -> DFU -> final application

where the middle application is very reduced, much like the DFU example in the SDK.

Best regards,

Edvin

RE: nrf52832 mesh bricks after OTA update

Mr Sunshine — Mon, 13 Jul 2020 10:22:32 GMT

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/259651"]Have you tried to flash the new application manually? Does that work?[/quote]

Flashing manually will fix the problem yes. But I want to update it through DFU. Currently some customers of us already have this product, so we don't want to call these back for a update if an OTA update is also possible.

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/259651"]What is the free space (the grey area) in your screenshot to the left? [/quote]

I don't know what it is for, it was like this during development. I assumed it was the free space required for updates. All I know is that red is bootloader, black is bootloader settings, green is application and blue is soft device.

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/259651"]Have you tried to port the application to a later SDK version? Is it reproducible there?[/quote]

I have in the past but failed. Porting to another SDK isn't easily done, and from the experience it's probably easier to redo the project if I want to change the SDK.

I will respond later about flash_area_is_valid().

RE: nrf52832 mesh bricks after OTA update

Edvin — Mon, 13 Jul 2020 09:31:33 GMT

Have you tried to flash the new application manually? Does that work?

What is the free space (the grey area) in your screenshot to the left? Do you have the addresses? And what is the size of your new application? does it fit within that grey space?

Are you able to debug after the DFU?

[quote user="mr sunshine "]how can I easily check this? It becomes quite a maze if I dig deeper in the function. [/quote]

Try to set a breakpoint in flash_area_is_valid(). Try to step a bit, and set new breakpoints to find out why the flash_area_is_valid() returns false.

Is metadata_is_valid() returning false? What is your page_count? Does it assert in any of these?

NRF_MESH_ASSERT(p_manager->config.p_area[i].metadata.page_index == i);
NRF_MESH_ASSERT(p_manager->config.p_area[i].metadata.pages_in_area == p_manager->config.page_count);

Which of these checks is it that fails?

Remember that you may need to turn off optimization in order to debug this properly.

Have you tried to port the application to a later SDK version? Is it reproducible there?

RE: nrf52832 mesh bricks after OTA update

Mr Sunshine — Mon, 13 Jul 2020 07:23:38 GMT

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/259473"]Please try to check why the flash_area_is_valid()[/quote]

how can I easily check this? It becomes quite a maze if I dig deeper in the function.

In addition I have scanned the memory with nRF Connect and see this happening. Might this help to figure out the issue? What you see is one is made before the update which shows a blank space, and the other is after the update which shows almost no blank space.

RE: nrf52832 mesh bricks after OTA update

Edvin — Fri, 10 Jul 2020 14:03:37 GMT

Not that I can tell. Please try to check why the flash_area_is_valid() returns false, and what address it is trying to check, what is present there, and what it is expecting.

I am sorry for pushing this over on you, but we are very short staffed due to summer holidays in Norway, so in order to give some pointers to everyone, I can't spend too much time digging. These are the action points that I would investigate if I were to find out why it is not working.

Best regards,

Edvin

RE: nrf52832 mesh bricks after OTA update

Mr Sunshine — Fri, 10 Jul 2020 09:18:58 GMT

thanks for your extended explanation.

I did some debugging and I got the following:

BOOTLOADERADDR() = 0x70000

p_flash_end = 454656

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/259356"]You are using the Mesh SDK 2.1.1. Was the previous application also from the same SDK version, or did you do a version upgrade?[/quote]

The update is in the same SDK version. One thing that might be interesting is that the new application is on Release configuration, while the old one was in Debug.

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/259356"]Please make sure that you start with a completely clean flash (nrfjprog --eraseall) before you flash your bootloader,[/quote]

Don't worry about that. when I test a new DFU I clear and flash the original application to the device.

In addition I have tried to also update the softdevice and bootloader through the DFU to see if that solves the issue, but it still seems to get errors. I currently use this code to generate the package, did I miss something?

nrfutil pkg generate package_to_generate.zip --hw-version 52 --sd-req 0xA8,0xAF --sd-id 0 --softdevice softdevice.hex --bootloader-version 0 --bootloader bootloader.hex --key-file ./key_file.pem --application-version 0 --application application.hex

RE: nrf52832 mesh bricks after OTA update

Edvin — Fri, 10 Jul 2020 08:12:53 GMT

Sorry. I was a bit short in my previous reply.

I meant the call to BOOTLOADERADDR() in your mesh application project. it is found in flash_manager_defrag.c.

This is a macro that checks whether or not there is a bootloader present in flash.

In your case, you know that there indeed is a bootloader in the flash, but if this check returns false, then the mesh application will try to use the flash in the bootloader area to store the network data, while it actually should have tried to use the flash below the bootloader instead.

So after performing the OTA DFU, can you please try to set a breakpoint on line 591 in flash_manager_defrag.c:

bool flash_manager_defrag_init(void)
{
#ifdef FLASH_MANAGER_RECOVERY_PAGE
    mp_recovery_area = (flash_manager_recovery_area_t *) FLASH_MANAGER_RECOVERY_PAGE;
#else
    flash_manager_recovery_area_t * p_flash_end;
    if (BOOTLOADERADDR() != BLANK_FLASH_WORD &&     //<-- line 591
        BOOTLOADERADDR() != 0)
    {
        ...

and do some debugging to see what p_flash_end ends up being after these checks.

BOOTLOADERADDR() is a macro:

#define BOOTLOADERADDR() (NRF_UICR->NRFFW[0])

So it reads the UICR register for the bootloader address.

Please make sure that you start with a completely clean flash (nrfjprog --eraseall) before you flash your bootloader, softdevice and application, so that you don't have anything old data in the flash from previous testing. The flash should not be corrupted after a DFU.

You are using the Mesh SDK 2.1.1. Was the previous application also from the same SDK version, or did you do a version upgrade?

BR,

Edvin

RE: nrf52832 mesh bricks after OTA update

Mr Sunshine — Thu, 09 Jul 2020 15:08:37 GMT

hello Edvin,

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/259250"]This means that you are using a BLE bootloader, and not the mesh bootloader, right?[/quote]

Yes it uses BLE for updates. The system can be set in a separate DFU mode when using.

[quote userid="26071" url="~/f/nordic-q-a/63523/nrf52832-mesh-bricks-after-ota-update/259250"]When you have programmed the bootloader and performed the OTA DFU (or alternatively you can generate and flash bootloader settings using "nrfutil settings generate (--help)" if it is tedious to do this every time). What is the return value of BOOTLOADERADDR() in flash_manager_defrag.c. Is it 0xFFFFFFFF or the actual bootloader address?[/quote]

I don't really understand what you are saying. Where is this "flash_manager_defrag.c" is this a separate file?

I have generated the bootloader settings file if you are interested in that, but I cannot see this BOOTLOADERADDR() you are mentioning in this file. below the contents of the bootloader settings file:

:020000040007F3
:10E00000445500E70100000000000000000000008F
:10E01000000000000000000020F40100C4627BB397
:10E0200001000000000000000000000000000000EF
:10E0300000000000000000000000000000000000E0
:10E0400000000000000000000000000000000000D0
:0CE05000000000000000000000000000C4
:10F00000445500E70100000000000000000000007F
:10F01000000000000000000020F40100C4627BB387
:10F0200001000000000000000000000000000000DF
:10F0300000000000000000000000000000000000D0
:10F0400000000000000000000000000000000000C0
:0CF05000000000000000000000000000B4
:00000001FF

I hope this helps.

RE: nrf52832 mesh bricks after OTA update

Edvin — Thu, 09 Jul 2020 14:36:51 GMT

Hello,

[quote user=""]After an OTA update (with use of the nRF toolbox app) the nrf52832[/quote]

This means that you are using a BLE bootloader, and not the mesh bootloader, right?

I don't remember what combination, but I remember that there was one Mesh SDK that used a version of the nRF5 "normal BLE" SDK where this combination was not compatible with one another. The reason was that the nRF5 SDK used a new method of storing the bootloader address, which the Mesh SDK didn't check for.

When you have programmed the bootloader and performed the OTA DFU (or alternatively you can generate and flash bootloader settings using "nrfutil settings generate (--help)" if it is tedious to do this every time). What is the return value of BOOTLOADERADDR() in flash_manager_defrag.c. Is it 0xFFFFFFFF or the actual bootloader address?

BR,

Edvin