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

ERROR_INVALID_DATA at mesh DFU

Hi 

I try to implement DFU to our application using Mesh_SDK 2.0.1 and 
nRF5_SDK_15.0.0 

When I use the DFU-Example everything works fine. I then implemented the 
DFU-code from the example to our client application to be able to update it 
(without provisioning of servers at the moment). 

To program the device I use: 

cd pc-nrfutil-mesh_dfu 
nrfutil dfu genpkg --application 
../../Source/connectivity_client/build/connectivity_client_Debug/connectivit 
y_client.hex --company-id 0x00000059 --application-id 1 
--application-version 1 --sd-req 0x00A9 --mesh client.zip 
cd dfu 
python device_page_generator.py -d nrf52840_xxAA -sd "s140_6.0.0" -o 
../client.hex 
cd .. 
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_Debug/connectivit 
y_client.hex 
nrfjprog --program client.hex 
nrfjprog --reset 

For DFU I use: 


cd pc-nrfutil-mesh_dfu 
nrfutil dfu genpkg --application 
../../Source/connectivity_client/build/connectivity_client_Debug/connectivit 
y_client.hex --company-id 0x00000059 --application-id 1 
--application-version 2 --sd-req 0x00A9 --mesh client.zip 
cd dfu 
python device_page_generator.py -d nrf52840_xxAA -sd "s140_6.0.0" -o 
../client.hex 
cd .. 
nrfutil --verbose dfu serial -pkg client.zip -p COM19 -b 115200 -fc --mesh 

This seems to work in the beginning, but then throws an error: 

Flushing com-port... 

Opened com-port 

Starting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, 
application size: 131356 

Sending DFU start packet, afterwards we wait for the flash on target to be 
initialized before continuing. 
PC -> target: 0502aabbccdd 
target -> PC: 0582aabbccdd 
Got echo response 
Sending DFU init packet 
PC -> target: 1378fdff040fc9d339f459000000010005000000 
target -> PC: 16a6045900000001000500000059000000010001000000 
target -> PC: 03847800 
PC -> target: 1378fdff040fc9d339f459000000010005000000 
target -> PC: 03847800 
PC -> target: 1478fcff0000c9d339f4ffffffff4780000000000c 
target -> PC: 03847800 
Sending firmware file 

[------------------------------------] 1% 00:11:50PC -> target: 
1978fcff0100c9d339f400f0032059620200896202008b620200 
target -> PC: 03847883 
PC -> target: 1978fcff0100c9d339f400f0032059620200896202008b620200 
target -> PC: 03847887 
PC -> target: 1978fcff0100c9d339f400f0032059620200896202008b620200 
target -> PC: 03847887 
PC -> target: 1978fcff0100c9d339f400f0032059620200896202008b620200 
target -> PC: 03847887 
PC -> target: 1978fcff0100c9d339f400f0032059620200896202008b620200 
target -> PC: 03847887 


Failed to upgrade target. Error is: Device returned status code 
ERROR_INVALID_DATA (135) on a DFU data packet. 


What could be the problem here? 

Kind regards 



Gerry 

  • Setting --i to 500 did not solve my Problem.

  • It's not a long term solution anyway. I guess we'll have to wait for nordic support

  • Hi,

    I am very sorry for the delay, it looked like you had found a workaround but now I realize it did not work for you all.

    You can try to increase SEND_START_DFU_WAIT_TIME in dfu_transport_mesh.py. (In the python source for nrfutil mesh branch.) Try setting it to 3.0 first, and increase it even a bit more if that is not sufficient. The larger the application, the more you might have to increase it.

    Regards,
    Terje

  • Hi, 

    Changing SEND_START_DFU_WAIT_TIME to 3.0 helped to ged rid of the "crash on start package". It now returns with ERROR_INVALID_PARAMETER after a while as you can see below. Further increasing of SEND_START_DFU_WAIT_TIME doesn't help.

    Flow control is enabled.
    Flushing com-port...
    Opened com-port
    Starting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, application size: 137740
    Sending DFU start packet, afterwards we wait for the flash on target to be initialized before continuing.
    PC -> target: 0502aabbccdd
    target -> PC: 0582aabbccdd
    Got echo response
    Sending DFU init packet
    PC -> target: 1378fdff040fea3cfb2759000000010002000000
    target -> PC: 16a6045900000001000200000059000000010001000000
    target -> PC: 03847800
    PC -> target: 1378fdff040fea3cfb2759000000010002000000
    target -> PC: 03847800
    PC -> target: 1478fcff0000ea3cfb27ffffffff8386000000000c
    PC -> target: 1478fcff0000ea3cfb27ffffffff8386000000000c
    target -> PC: 0da2010459000000010002000000
    target -> PC: 03847800
    Sending firmware file
      [------------------------------------]    1%  00:13:09PC -> target: 1978fcff0100ea3cfb2700f0032059620200896202008b620200
    PC -> target: 1978fcff0100ea3cfb2700f0032059620200896202008b620200
    target -> PC: 03847887
    PC -> target: 1978fcff0100ea3cfb2700f0032059620200896202008b620200
    target -> PC: 03840082
    PC -> target: 1978fcff0100ea3cfb2700f0032059620200896202008b620200
    PC -> target: 1978fcff0100ea3cfb2700f0032059620200896202008b620200

    Failed to upgrade target. Error is: Device returned status code ERROR_INVALID_DATA (135) on a DFU data packet.
    Can you see, what's going wrong here?
    Kind regards 
    Gerry
  • Hi,

    It looks from the log like you run the standalone bootloader. That one returns fewer status messages, which may make it a bit hard to figure out.

    The first error message is NRF_INVALID_STATE (0x83, or in decimal 133). I talked to our mesh guys, and when you get NRF_INVALID_STATE after having sent the first data packet, it (usually) means there is not enough available space for the new download so it cannot begin. The bootloader then jumps back to the previous stage (you will see that after the NRF_INVALID_STATE return message the first 1978fc... messages from target to PC are repeated, and the target is back in that state.

    Regards,
    Terje

Related