• State Verified Answer
  • Replies 8 replies
  • Subscribers 74 subscribers
  • Views 1487 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 253974
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ERROR_INVALID_DATA (135) during 'Configuring and performing DFU over Mesh' v4.2.0

benedev

I've been trying to transfer a DFU update via serial, and I have gotten error 135 each time.

A colleague of mine got it working this january, with v3.1.0. Now, the same scripts don't work on my machine, with my nrfutil Installation. I am using the current commit of the mesh_dfu branch of the nrfutil tool.

This is my console output:

C:\_SVN\01_FuMu_SOM_TestPCB\BLE Mesh DFU Update 4.2>nrfutil --verbose dfu serial -pkg blinky_update.zip -p COM11 -b 115200 -fc --mesh
Upgrading target on COM11 with DFU package C:\_SVN\01_FuMu_SOM_TestPCB\BLE Mesh DFU Update 4.2\blinky_update.zip. Flow control is enabled.
Flushing com-port...
Opened com-port
Starting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, application size: 2180
Sending DFU start packet, afterwards we wait for the flash on target to be initialized before continuing.
1: PC -> target: 0502aabbccdd
target -> PC: 0582aabbccdd
Got echo response
Sending DFU init packet
Sending ready packet
1: PC -> target: 1378fdff040f4da6184559000000010002000000
target -> PC: 03847800
1: PC -> target: 1378fdff040f4da6184559000000010002000000
target -> PC: 03847800
Sending start packet
1: PC -> target: 1478fcff00004da61845ffffffff2102000000000c
target -> PC: 03847887
2: PC -> target: 1478fcff00004da61845ffffffff2102000000000c
target -> PC: 03847887
3: PC -> target: 1478fcff00004da61845ffffffff2102000000000c
target -> PC: 03847887
4: PC -> target: 1478fcff00004da61845ffffffff2102000000000c
target -> PC: 03847887
5: PC -> target: 1478fcff00004da61845ffffffff2102000000000c
target -> PC: 03847887
6: PC -> target: 1478fcff00004da61845ffffffff2102000000000c
target -> PC: 03847887
7: PC -> target: 1478fcff00004da61845ffffffff2102000000000c
target -> PC: 03847887
8: PC -> target: 1478fcff00004da61845ffffffff2102000000000c
target -> PC: 03847887
9: PC -> target: 1478fcff00004da61845ffffffff2102000000000c
target -> PC: 03847887
10: PC -> target: 1478fcff00004da61845ffffffff2102000000000c
target -> PC: 03847887


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

Possible causes:
- bootloader, SoftDevice or application on target does not match the requirements in the DFU package.
- baud rate or flow control is not the same as in the target bootloader.
- target is not in DFU mode. If using the SDK examples, press Button 4 and RESET and release both to enter DFU mode.
- if the error is ERROR_BUSY at the beginning of the DFU process,increase the value of PAGE_ERASE_TIME_MAX by few milliseconds.
Closing serial port...

After flashing the DFU example, this is the output on the RTT Viewer, the nothing is output while trying to send the update:

00> <t:          2>, main.c,  222, ----- Bluetooth Mesh DFU Example -----
00> <t:      12732>, ble_softdevice_support.c,  171, sd_ble_enable: app_ram_base should be adjusted to 0x200018F8
00> <t:      13257>, serial_handler_prov.c,  267, Generating encryption keypair...
00> <t:      18033>, main.c,  228, Initialization complete!
00> <t:      22743>, main.c,  249, Enabling serial interface...
00> <t:      22746>, mesh_app_utils.c,   66, Device UUID (raw): B792232387B44786B0B95873ECE2BB8A
00> <t:      22750>, mesh_app_utils.c,   67, Device UUID : B7922323-87B4-4786-B0B9-5873ECE2BB8A
00> <t:      22759>, nrf_mesh_dfu.c,  554,   RADIO TX! SLOT 0, count 15, interval: periodic, handle: FFFE
00> <t:      22763>, nrf_mesh_dfu.c,  593,   SERIAL TX (type: 65534)
00> <t:      22771>, main.c,  257, DFU example started!
00> <t:      23920>, nrf_mesh_dfu.c,  418,   New firmware!
00> <t:      23923>, main.c,  119, Requesting DFU transfer with bank at 0x00047000
00> <t:      23926>, nrf_mesh_dfu.c,  554,   RADIO TX! SLOT 0, count 3, interval: periodic, handle: FFFD
00> <t:      23930>, nrf_mesh_dfu.c,  565, Killing a TX slot prematurely (repeats done: 1).
00> <t:      23934>, nrf_mesh_dfu.c,  593,   SERIAL TX (type: 65533)

Seems fishy to me, that it immediately seems to receive packets, even though I havent started the update yet?

Parents
  • 0

    Hi Benedev, 

    Please let us know your script to create the .zip file and the device page. 
    Also please let us know the nrfutil version you are using. 
    Seems like the DFU target kept rejecting the first packet from the DFU master. 
    Please try to test again without any signing keys. 

  • 0 in reply to Hung Bui

    Hi Hung Bui.

    I am using the following commands to create the .zip file and the device page:

    nrfutil dfu genpkg --application blinky_nrf52833_xxAA_s113_7.0.1.hex --company-id 89 --application-id 1 --application-version 2 --sd-req 0xFFFE --mesh blinky_update.zip 
python tools/dfu/device_page_generator.py -d nrf52833_xxAA -sd "s113_7.0.1"

    I am using nrfutil version 0.3.0.0I already tried without any signing keys.

    Thank you for your help.

  • +1 in reply to benedev

    Hi benedev, 
     I just tested here and it seemed to work fine for me on the nRF52833. Could you try to test with the following files ? Please do a chip erase before the test.
    If you still have an issue with the files, I think you may want to check the hardware. Do you use the nRF52833 DK ? Could you try testing UART communication  ? 

    Mesh.zip

  • 0 in reply to Hung Bui

    Hi Hung Bui,

    it worked! Thank you. However, to gain some deeper understanding to help me in the future, I would be thankful for some additional insight:

    I was able to narrow down the cause of the problem, because I noticed that you included dfu_nrf52832_xxAA_s132_7.0.1.hex
    which worked, but confused me a bit, so I tried it with
    dfu_nrf52833_xxAA_s113_7.0.1.hex
    which produced the same error 135 again.

    How is this possible?

    • I am using the nrf52833 chip, but the DFU version for the nrf52832 chip works
    • I am using the S113 softdevice, but the DFU version using the S132 softdevice works

    I also noticed that you sent me a different bootloader:

    • Before: mesh_bootloader_serial_gccarmemb_nrf52833_xxAA.hex
    • Now: mesh_bootloader_serial_armcc_nrf52833_xxAA.hex

    Both work. What is the difference?

  • +1 in reply to benedev

    Hi Benedev, 


    It's my mistake I supposed to send you the dfu_nrf52833_xxAA_s113_7.0.1.hex. 

    Could you please try again with the file I attached here: 

    dfu_nrf52833_xxAA_s113_7.0.1.hex

    If this works for you, then there must be something wrong in the project/SDK you have. I would suggest to try to build using a fresh SDK copy. 

    The difference between mesh_bootloader_serial_gccarmemb_nrf52833_xxAA and mesh_bootloader_serial_armcc_nrf52833_xxAA is the different compiler gcc vs armcc (Keil). They should both work the same. 

  • 0 in reply to Hung Bui

    Hi Hung Bui,

    thank you, it worked your file, and it also worked after I redownloaded the SDK and rebuilt the DFU example. Very weird, I didn't knowingly change anything. Anyway, I now have a working DFU Mesh example and I can start including it in my project, thank you very much!

Reply Children
No Data
Related
Terms of service