ERROR: No CMD handler!

[Gerry]

Hi,

I added DFU functionality to my Mesh-client application as shown in your DFU-example.

At startup I get this log message:

nrf_mesh_dfu.c,  904, ERROR: No CMD handler!

coming from here:

uint32_t nrf_mesh_dfu_cmd_send(bl_cmd_t* p_cmd)
{
    if (m_cmd_handler == NULL)
    {
        __LOG(LOG_SRC_DFU, LOG_LEVEL_ERROR, "ERROR: No CMD handler!\n");
        return NRF_ERROR_NOT_SUPPORTED;
    }
...
}

Can someone please tell me, what I'm doing wrong here?

(using Mesh SDK 3.1.0 and SDK 15.2)

Regards

Gerry

[Edvin]

Hello Gerry,

Well, it seems like you are missing the CMD handler.

In the DFU example in the Mesh SDK, this is typically set in main()->initialize()->mesh_stack_init()->nrf_mesh_init()->nrf_mesh_dfu_init()->dfu_cmd_handler_set().

Does this get called in your project?

BR,

Edvin

[Gerry]

Hi Edvin

I found the place, thanks. Put a breakpoint there. The function is called (Line 643 of nrf_mesh_dfu.c). The return value is NRF_ERROR_NOT_SUPPORTED. Seems to be a problem with BOOTLOADERADDR(). Do I have to set the address in NRF_UICR->NRFFW[0] manually?

Using Segger Studio. Same message, when I program the device with my script:

cd pc-nrfutil-mesh_dfu
cd dfu
set /a "prior_version=%client_version%-1"
 (
   echo {
   echo     "bootloader_config": {
   echo        "bootloader_id": 1,
   echo        "bootloader_version": 1,
   echo        "company_id": 89,
   echo        "application_id": 1,
   echo        "application_version": %prior_version%
   echo    }
   echo }
 ) > bootloader_config_default.json
python device_page_generator.py -d nrf52840_xxAA -sd "s140_6.0.0" -o ../client.hex
cd ..
@echo:
nrfjprog --recover -f NRF52
REM use --verify to verify programming with --program
nrfjprog --eraseall
nrfjprog --program ..\..\Mesh_SDK\bin\softdevice\s140_nrf52_6.0.0_softdevice.hex --chiperase 
nrfjprog --program bootloader\mesh_bootloader_serial_gccarmemb_nrf52840_xxAA.hex 
nrfjprog --program ..\..\Source\connectivity_client\build\connectivity_client_Release\connectivity_client.hex 
nrfjprog --program client.hex 
nrfjprog --reset

Regards Gerry

[Gerry]

This returns:

nrfjprog --eraseall
Erasing user available code and UICR flash areas.
Applying system reset.

nrfjprog --program bootloader/mesh_bootloader_serial_gccarmemb_nrf52840_xxAA.hex --verify
Parsing hex file.
Reading flash area to program to guarantee it is erased.
Checking that the area to write is not protected.
Programming device.
Verifying programming.
Verified OK.

nrfjprog --memrd 0x10001014
0x10001014: 000F8000

Edit:

When I add the memrd to the end of my script (s. above) where also the softdevice and application is programmed, I also get 0x10001014: 000F8000

[Edvin]

This is the address that your project reads. NRF_UICR->NRFFW[0]:

https://www.nordicsemi.com/DocLib/Content/Product_Spec/nRF52840/latest/uicr?92#topic

Are you sure you are using the correct projects? And not mixing in some parts from nrf52832?

Your application, "connectivity_client", is it based on an nRF52832 or nRF52840 project?

BR,

Edvin

[Gerry]

I now added a log-message at program start:

__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "NRFFW[0]: %08X\n", NRF_UICR->NRFFW[0]);

Without programming the bootloader it outputs NRFFW[0]: FFFFFFFF

After programming everything with my script and then start the programm in Segger Studio i get:

NRFFW[0]: 000F8000

Seems to work like it should.

But why do I still get the log-message:

<t:      24749>, nrf_mesh_dfu.c,  904, ERROR: No CMD handler!

The project is based on the light switch example of Mesh SDK 1.0.0. We never worked with nRF52832, so this should not be an issue.

regards

Gerry

[Edvin]

Gerry said:

Without programming the bootloader it outputs NRFFW[0]: FFFFFFFF

 Yes. the address that it reads is written by the bootloader. The point of this is to check that the bootloader actually is present before starting to use it. 

I really (!) recommend you to move to Mesh SDK3.1.0 before you do too much. There are a lot of bugfixes since the first version.

Can you please start with the SDK3.1.0, and also, please the reply from my colleague, Hung, in this post.

Also, programming the chip using an IDE (such as Segger Embedded Studio) and having a bootloader that does CRC checking on the application has shown to be a bit tricky. I do not believe that your issue is related to this, but I recommend that you program the DK using nrfjprog when dealing with bootloaders. You can still monitor the log using J-Link RTT Viewer.

BR,

Edvin

[Gerry]

Thanks Edvin, this solved the problem.

Our project already is migrated to SDK 3.1.0

Following Hungs post and make the change to flashplacement.xml finally fixed the issue.

regards

Gerry