Mesh DFU dfu_cmd_handler_set always failing?

[a.wallwitz]

Hi @ll,

I'm still trying to get the Mesh DFU example up and running. I'm following the guide in the documentation. (Mesh Version 2.0.0: it's the same in 2.0.1 so don't worry about the version)

Setup: Everything flashed (Softdevice 6.0.0, Bootloader, DevicePage and DFU example application)

Once I try to send a dfu packet the device throws this error:
<t:     452185>, nrf_mesh_dfu.c,  901, ERROR: No CMD handler!

Looking at the code I found something that looks strange to me:
nrf_mesh_dfu.c in mesh/dfu/src

uint32_t nrf_mesh_dfu_init(void)
{
    uint32_t error_code;
#if !defined(HOST)
    error_code = dfu_cmd_handler_set(*((bl_if_cmd_handler_t*) (DEVICE_DATA_RAM_END_GET() - sizeof(bl_if_cmd_handler_t))));
    if (error_code != NRF_SUCCESS)
    {
        m_transfer_state.state = NRF_MESH_DFU_STATE_INITIALIZED;
        return NRF_ERROR_NOT_SUPPORTED;
    }

This part calls dfu_cmd_handler_set with an address that is in the range of RAM (for the nRF52 about 0x2000xxxx)

But the function it self does/checks this:
nrf_mesh_dfu.c in mesh/dfu/src

static uint32_t dfu_cmd_handler_set(bl_if_cmd_handler_t handler)
{
    if (handler == NULL)
    {
        return NRF_ERROR_NULL;
    }
    if (BOOTLOADERADDR() == 0xFFFFFFFF)
    {
        /* No bootloader present. */
        return NRF_ERROR_NOT_SUPPORTED;
    }
    if (((uint32_t) handler >= DEVICE_FLASH_END_GET()) ||
        ((uint32_t) handler < BOOTLOADERADDR()))
    {
        /* out of bounds. */
        return NRF_ERROR_INVALID_ADDR;
    }

So it compares the address it gets with a FLASH address? Speaking about address in the range of 0x00000000-0x00080000.

So this will always return NRF_ERROR_INVALID_ADDR in case there is a bootloader address in NRF_UICR->NRFFW[0]? Otherwise it will always return NRF_ERROR_INVALID_ADDR?

Maybe I got something wrong

Thank you in advance for your help

Bye
Andrej

[a.wallwitz]

Short update:
The handler-address seems to be
handler = 0x2618F which is inside the application, not in the bootloader.

Unfortunately the bootloader is not available as source to check what is placed at RAM when

[Giang]

Hi , I'm also running that example . But I follow : http://infocenter.nordicsemi.com/index.jsp . When I run to step 4 : 

dfu$ python device_page_generator.py -d nrf52832_xxAA -sd "s132_5.0.0"

I get this error : 

Did you encounter this error? If yes, can you give me the solution. Thank!!!

[a.wallwitz]

https://devzone.nordicsemi.com/f/nordic-q-a/34378/mesh-dfu-example-not-working-no-serial-communication-for-linux-and-more

Check the first part of the ticket. This is how I fixed this problem you have ;)

[Hung Bui]

Hi Andrej, 

 

My understanding is that the bootloader should write the address of the dfu_cmd_handler (that is located inside the bootloader) in to the last address in RAM. dfu_cmd_handler_set() will check if the address is located inside bootloader flash area or not. I'm not sure how in your case it ends up in the application. 

Do you have the same problem when you test on Windows machine ? Have you managed to perform any DFU update using Windows ? If you do, we can focus on the incompatibility on Linux. I will try to get the team to have a look on the issue. 

[a.wallwitz]

Hi Hung,

so I redownloaded the Mesh SDK2.0.1 and compiled the DFU-App-example (just to be sure that I did not mess up something)

I rebuilded the device page and flashed everything (Softdevice 6.0.0, Bootloader (gccarmemb_serial_nrf52832_xxAA), device_page and dfu_app - in that order). Then the reset of the board and the example boots.

But I still get this "No CMD handler!" ERROR from nrf_mesh_dfu.c line 901.

Looks like the bootloader is not compatible with softdevice 6.0.0 or it is broken to me?

Could you please verify that this guide (except for replacing "sd_5.0.0" by "sd_6.0.0"): http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.meshsdk.v2.0.1/md_doc_getting_started_dfu_quick_start.html
Is still vaild for SDK 2.0.1 including all files included in SDK 2.0.1? Like bootloader, device_page_generator etc.?

FYI: I get the exact same error on my windows machine as it is not a serial issue but a "memory-address-to-ram-write"-issue within the bootloader as far as we can tell now, I guess.

Thank you for your help and I hope to hear from you soon once this is verified

______

Andrej