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

[Edvin]

Hello,

No, you shouldn't write to this address yourself. This address is written by the bootloader itself. If you program the bootloader (found in SDK_for Mesh\bin\bootloader\gccarmemb\<your suitable bootloader>.hex) this value will contain the correct data.

Can you try this?

Best regards,

Edvin

[Gerry]

Hi,
I think, this should be done on line 22 of my script:

nrfjprog --program bootloader\mesh_bootloader_serial_gccarmemb_nrf52840_xxAA.hex

The CMD output of my script looks as follows:

Wrote device page for nrf52840_xxAA with the s140_6.0.0 SoftDevice to ../client.hex.
Recovering device. This operation might take 30s.
Erasing user code and UICR flash areas.
Erasing user available code and UICR flash areas.
Applying system reset.
Parsing hex file.
Erasing user available code and UICR flash areas.
Applying system reset.
Checking that the area to write is not protected.
Programming device.
Parsing hex file.
Reading flash area to program to guarantee it is erased.
Checking that the area to write is not protected.
Programming device.
Parsing hex file.
Reading flash area to program to guarantee it is erased.
Checking that the area to write is not protected.
Programming device.
Parsing hex file.
Reading flash area to program to guarantee it is erased.
Checking that the area to write is not protected.
Programming device.
Applying system reset.
Run.

The RTT-output, when the program starts:

 0> <t:          0>, main.c,   44, ___ Connectivity start client _________
 0> <t:          0>, mesh.c,  649, rom_base   26101
 0> <t:          0>, mesh.c,  650, rom_end    43A90
 0> <t:          0>, mesh.c,  651, rom_length 1D98F
 0> <t:          0>, mesh.c,  652, bank_addr   44000
 0> <t:       8223>, mesh.c,  673, Initializing mesh stack
 0> <t:       8705>, mesh.c,  696, Initializing and adding models
 0> <t:       8707>, mesh.c,  361, Setting up access layer and models
 0> <t:      18344>, nrf_mesh_dfu.c,  904, ERROR: No CMD handler!
 0> <t:      18690>, flash.c,  113, Read settings from flash
 0> <t:      18692>, flash.c,  115, provisioned_devices: 0
 0> <t:      18695>, flash.c,  116, next_unprov_address: 500
 0> <t:      18697>, flash.c,  117, next_unprov_index: 0
 0> <t:      18699>, flash.c,  118, node_count: 0
 0> <t:      18701>, flash.c,  119, network key: E.....4D
 0> <t:      18793>, main.c,   53, ___ Connectivity client initialized ___
 
 So still "ERROR: No CMD handler!" Can you see, what's going wrong here?
 
 Regards
    Gerry

[Edvin]

Hello,

Can you please try to add --verify on the end of all your nrfjprog --program commands in your script?

Also, can you do a flashdump after programming your nRF?

You can use:

nrfjprog --readcode my_flash_dump.txt

And upload it here?

BR,

Edvin

[Gerry]

Hi Edvin

Yes shure. Here the CMD-log I got and attached the flash dump:

Recovering device. This operation might take 30s.
Erasing user code and UICR flash areas.
Erasing user available code and UICR flash areas.
Applying system reset.
Parsing hex file.
Erasing user available code and UICR flash areas.
Applying system reset.
Checking that the area to write is not protected.
Programming device.
Verifying programming.
Verified OK.
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.
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.
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.
Reading flash.
Storing data in 'my_flash_dump.txt'.
Applying system reset.
Run.

Regards Gerry

my_flash_dump.txt

[Edvin]

I don't understand this. Can you try to write this in cmd:

nrfjprog --eraseall
nrfjprog --program mesh_bootloader_serial_gccarmemb_nrf52840_xxAA.hex --verify
nrfjprog --memrd 0x10001014

What does it say?

[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