This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Mesh DFU dfu_cmd_handler_set always failing?

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 Confounded

Thank you in advance for your help Slight smile

Bye
Andrej

Parents
  • 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. 

Reply
  • 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. 

Children
  • 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 Slight smile

    ______

    Andrej

  • Hi Andrej, 

    Did you use SES to build the DFU project ? 

    If you did, could you try a quick patch to see if it fixes the issue for you? R&D told me about the bug that SES-built firmware will clear the RAM part of the bootloader and cause the CMD handler location to be NULL.

    In examples/dfu/flash_placement.xml, change line 32 from

      <MemorySegment name="RAM" start="$(RAM_PH_START)" size="$(RAM_PH_SIZE)">

    to

      <MemorySegment name="RAM" start="$(RAM_PH_START)" size="$(RAM_SIZE)">

     

    Please let me know if it fixes the issue. 

  • Hi Hung,

    this solution is working. Thanks for that.
    But I still have a massiv problem with the serial communication using SEGGER 6.16c on my linux machine. Disappointed

    It looks like this communication is only working by chance as it is almost always working on my windows machine.

    Is there a way to replace everything SEGGER<->UART related by external USB<->UART?

    Bye
    Andrej

  • Hi Andrej, 

    If you have your own UART port on your PC you don't have to use the SEGGER one. Just configure the firmware on the chip to use different UART pin and use those pins to connect to your USB-UART. 

    As far as I remember the communication were quite stable when we were at the training ?

     

  • Hi Hung,

    changing the pins for the bootloader will be hard without the source code. Disappointed

    The serial communication was not working all the time at the training. Once it worked we kept everything open and running. Once we disconnected something and tried to use it again we had the timeout issue again. Remember?

    Bye
    Andrej

Related