In the serial example, how to use the command JumpToBootloader() to enter dfu mode.

[Leo Lin]

Hi Nordic,

I want to send JumpToBootloader() command to nrf52832 module to make it enter dfu mode and update.

But I got the following error, can you tell me what is the right way.

error : ERROR_REHECTED.

I have successfully updated FW with this command (use button four to enter dfu mode)

nrfutil dfu serial -pkg xxxx.zip -p /dev/ttyACM0

But now I need to use JumpToBootloader() to enter dfu mode.

Another question is to use the nrfutil tool to update the FW, is it necessary to let the nrf52832 module enter the dfu mode first. Right?

My environment is

Operating System: Ubuntu18.04

nRF5 SDK for Mesh v5.0.0

nRF5 SDK v17.0.2

SoftDevice : SoftDevice S132 version 7.2.0

python version: Python 3.6.9

board: PCA10040.

Thanks in advance.

Leo Lin.

[ovrebekk]

Hi Leo

Which example are you running on the nRF device when you try to use PyACI to update your application?

The mesh stack has its own DFU mechanism, which is completely separate from the normal DFU in the SDK. 

The mesh DFU is described here, and is a unique DFU solution designed to handle DFU in a distributed way that slowly sends an update over the mesh network without having to stop the application in the mean time. This is very different from the normal DFU that requires you to suspend the application, but will run much faster. 

The PyACI tool will not work with the standard nRF5 SDK DFU mechanism, and requires the right mesh example to be flashed into the device. 

Best regards
Torbjørn

[Leo Lin]

Hi Ovrebekk,

Thanks you for your reply.

I use this example nRF5-SDK-for-Mesh/examples/serial/serial_nrf52832_xxAA_s132_7_2_0.emProject.

My goal is to use this example to update the FW of nRF52832 (including bootloader, softdevice and application) through DFU over serial interface.

Q1- Can this example use mesh DFU over serial interface to update FW?

Q2- If I want to use the nrfutil tool through serial interface to update the nrf52832 module, the nrf52832 module must first enter the dfu mode, whether it is normal dfu or mesh dfu. right?

Q3- Error of mesh DFU example.

OK, in order to understand mesh DFU, I did this example "Configuring and performing DFU over Mesh", but I encountered the following problems during the step of "Transferring the DFU archive over serial with nRF Util"

Can you help me to solve this problem? 

Here are my steps, 

Among them, I skipped step 5 "Flash the first application on all devices" because I couldn't find the file build/examples/dfu/dfu_nrf52832_xxAA_s132_7.2.0.hex and I saw the instructions of Note, so I skipped this step, I don't know if there will be a problem.

### gen private key
leo@leo-work:~/Nordic_bluetooth_52832/nRF5-SDK-for-Mesh$ nrfutil keys --gen-key private_key.txt
leo@leo-work:~/Nordic_bluetooth_52832/nRF5-SDK-for-Mesh$ cat private_key.txt
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEILXfxLpB931VNYw8nD3YTEKeucq0YMU4JyHUHWSGftTQoAoGCCqGSM49
AwEHoUQDQgAE+KhRYcdMjpsfdyYNo0c3rY4XxYj7YjQ9vlZTP2NAKauWj7YUU40Y
VriixdEk88IX78T0K9ZzRZ50JWFTfngp6A==
-----END EC PRIVATE KEY-----

### gen public key
leo@leo-work:~/Nordic_bluetooth_52832/nRF5-SDK-for-Mesh$ nrfutil keys --show-vk hex private_key.txt 
Verification key Qx: f8a85161c74c8e9b1f77260da34737ad8e17c588fb62343dbe56533f634029ab
Verification key Qy: 968fb614538d1856b8a2c5d124f3c217efc4f42bd673459e742561537e7829e8

### copy Qx and Qy to bootloader_config_default.json
leo@leo-work:~/Nordic_bluetooth_52832/nRF5-SDK-for-Mesh$ vim tools/dfu/bootloader_config_default.json
leo@leo-work:~/Nordic_bluetooth_52832/nRF5-SDK-for-Mesh$ cat tools/dfu/bootloader_config_default.json
{
    "bootloader_config": {
        "bootloader_id": 1,
        "bootloader_version": 1,
        "company_id": 89,
        "application_id": 1,
        "application_version": 1,
        "public_key":
        "f8a85161c74c8e9b1f77260da34737ad8e17c588fb62343dbe56533f634029ab968fb614538d1856b8a2c5d124f3c217efc4f42bd673459e742561537e7829e8"
    }
}

### Step 1: Generate a DFU file with nRF Util
leo@leo-work:~/Nordic_bluetooth_52832/nRF5-SDK-for-Mesh$ nrfutil dfu genpkg --application bin/blinky/blinky_nrf52832_xxAA_s132_7.2.0.hex --company-id 0x00000089 --application-id 1 --application-version 2 --key-file private_key.txt --sd-req 0x00CB --mesh dfu_test.zip
Key file was given, setting DFU version to 0.8
Zip created at dfu_test.zip

### Step 2: Generate a HEX version of device page
leo@leo-work:~/Nordic_bluetooth_52832/nRF5-SDK-for-Mesh/tools/dfu$ python device_page_generator.py -d nrf52832_xxAA -sd "s132_7.2.0"
Wrote device page for nrf52832_xxAA with the s132_7.2.0 SoftDevice to bin/device_page_nrf52832_xxAA_s132_7.2.0.hex.

### Step 3: Erase chip memory and flash SoftDevice on all devices
leo@leo-work:~/Nordic_bluetooth_52832/nRF5-SDK-for-Mesh$ nrfjprog --program bin/softdevice/s132_nrf52_7.2.0_softdevice.hex --chiperase
Parsing image file.
Applying system reset.
Verified OK.

### Step 4: Flash the serial bootloader on all devices
leo@leo-work:~/Nordic_bluetooth_52832/nRF5-SDK-for-Mesh$ nrfjprog --program bin/bootloader/gccarmemb/mesh_bootloader_serial_gccarmemb_nrf52832_xxAA.hex 
Parsing image file.
Applying system reset.
Verified OK.

### Step 6: Flash the device page on all devices and reset the device
leo@leo-work:~/Nordic_bluetooth_52832/nRF5-SDK-for-Mesh$ nrfjprog --program tools/dfu/bin/device_page_nrf52832_xxAA_s132_7.2.0.hex 
Parsing image file.
Applying system reset.
Verified OK.

leo@leo-work:~/Nordic_bluetooth_52832/nRF5-SDK-for-Mesh$ nrfjprog --reset
Applying system reset.
Run.

### Transferring the DFU archive over serial with nRF Util
leo@leo-work:~/Nordic_bluetooth_52832/nRF5-SDK-for-Mesh$ ls /dev/ttyACM1 
/dev/ttyACM1
leo@leo-work:~/Nordic_bluetooth_52832/nRF5-SDK-for-Mesh$ nrfutil dfu serial -pkg dfu_test.zip -p /dev/ttyACM1 -b 115200 -fc --mesh
Upgrading target on /dev/ttyACM1 with DFU package /home/leo/Nordic_bluetooth_52832/nRF5-SDK-for-Mesh/dfu_test.zip. Flow control is enabled.


Failed to upgrade target. Error is: Device returned status code ERROR_INVALID_PARAMETER (133) 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.

My environment is as follows:

One computer and one NRF52832-DK are connected with usb cable.

Operating System: Ubuntu18.04

nRF5 SDK for Mesh v5.0.0

nRF5 SDK v17.0.2

SoftDevice : SoftDevice S132 version 7.2.0

board: PCA10040.

Python version: Python 2.7.17 and Python 3.6.9

nrfutil tool version: 0.3.0.0

nrfjprog version: 10.15.0 external

Thanks in advance.

Leo Lin.

[Elfving]

Hey Leo!

Leo Lin said:

My goal is to use this example to update the FW of nRF52832 (including bootloader, softdevice and application) through DFU over serial interface.

Sure, that can be done. Take a look at the DFU example for more info about this.

Leo Lin said:

Q1- Can this example use mesh DFU over serial interface to update FW?

Here I am a little bit more uncertain about what you are looking for. At one point you do get to upload the FW using serial with Mesh DFU, though the rest happens over the mesh network itself. 

Leo Lin said:

Q2- If I want to use the nrfutil tool through serial interface to update the nrf52832 module, the nrf52832 module must first enter the dfu mode, whether it is normal dfu or mesh dfu. right?

A bit uncertain about what you mean here as well. Using nrfutil and entering DFU mode is necessary with normal DFU, and the steps for Mesh DFU are a bit more complex as you might have seen in its documentation. 

Leo Lin said:

Q3- Error of mesh DFU example.

I see. I'll look into that and get back to you. Though are you sure that the proprietary Mesh DFU solution is what you are looking for? I got the impression that normal DFU might be sufficient for you as well.

Best regards,

Elfving

[Leo Lin]

Hi Elfving,

Thank you for your reply

Elfving said:

Sure, that can be done. Take a look at the DFU example for more info about this. (men spørsmålet er om den har plass til alt det da, da den isåfall må ha enda en partisjon?)

See this example? But are nomal DFU and mesh DFU independent? The example I used is this and it is placed in the nRF5-SDK-for-Mesh folder. Can I use this example with normal DFU?

Elfving said:

Here I am a little bit more uncertain about what you are looking for. At one point you do get to upload the FW using serial with Mesh DFU, though the rest happens over the mesh network itself. 

Yes, I have successfully used Mesh DFU example to update the Application FW, but the bootloader and softdevice update have not been successful yet. 
However, the transmission speed through serial seems to be a bit slow. It takes more than one hour for me to update an APP FW with a data size of 321KB... Is this normal?

Elfving said:

A bit uncertain about what you mean here as well. Using nrfutil and entering DFU mode is necessary with normal DFU, and the steps for Mesh DFU are a bit more complex as you might have seen in its documentation. 

Okay, so nomal DFU update must first let nrf52832 enter DFU mode, but mesh DFU is not sure. 

Elfving said:

I see. I'll look into that and get back to you. Though are you sure that the proprietary Mesh DFU solution is what you are looking for? I got the impression that normal DFU might be sufficient for you as well.

I have successfully used this example to update the APP FW, and I think there are two things wrong.

The process is the same as I posted above, but in the step 1 "### Step 1: Generate a DFU file with nRF Util" I should change it to the following.

leo@leo-work:~/Nordic_bluetooth_52832/nRF5-SDK-for-Mesh$ nrfutil dfu genpkg --application bin/blinky/blinky_nrf52832_xxAA_s132_7.2.0.hex --company-id 0x00000059 --application-id 1 --application-version 2 --key-file private_key.txt --sd-req 0x0101 --mesh dfu_test.zip

 

One is that "--company-id" must be the same as the "company-id" in the bootloader_config_default.json file, and the other is --sd-req should be 0x0101. (refer to your file s132_nrf52_7.2.0_release-notes.pdf)

The value of --sd-req on the website is wrong?

 

I'm not sure whether I should use normal DFU or mesh DFU, but my purpose is to update the FW of the nRF52832 module through the serial interface. (including bootloader, softdevice and application)

The example I used is under the nRF5-SDK-for-Mesh folder, so should I use mesh DFU?

If not, I need to use normal DFU and know how to enter DFU mode without a button.

 

Thank you！

Leo.

[Elfving]

Hey again Leo!

Leo Lin said:

See this example? But are nomal DFU and mesh DFU independent?

Yes, that example. And the two types of DFU are somewhat independent: the proprietary mesh DFU and the BLE OTA DFU (Secure Bootloader) from nRF5 SDK. The first kind allows the nodes to be upgraded in parallel, while the latter requires individual separate connections to every node that is to be upgraded. Think of it as a DFU using Mesh. The Mesh DFU is complex, but is practical if you have a lot of nodes.

Sorry about that extra comment in Norwegian btw! I didn't mean to leave it there :)

Leo Lin said:

Can I use this example with normal DFU?

Yes, I am quite sure every example can be used along with normal DFU. Though there are other factors such as flash space etc. that might limit you.

Leo Lin said:

Yes, I have successfully used Mesh DFU example to update the Application FW, but the bootloader and softdevice update have not been successful yet. 

Did you follow the additional steps for that mentioned here? 

Leo Lin said:

However, the transmission speed through serial seems to be a bit slow. It takes more than one hour for me to update an APP FW with a data size of 321KB... Is this normal?

For mesh? Absolutely. 

The node takes a certain batch of that DFU it has received and sends it into the mesh network, with which it also is limited to 10 packets a second. It needs to do this so that the rest of the Mesh network also gets this DFU, though I guess in your case there is no Mesh network. Just this node.

Leo Lin said:

I'm not sure whether I should use normal DFU or mesh DFU, but my purpose is to update the FW of the nRF52832 module through the serial interface. (including bootloader, softdevice and application)

The question is if you want to update just a couple of devices or an entire network of units. Mesh DFU is a good way updating an entire mesh network. I assume a normal DFU is what you want. If you want it activated without a button maybe a firmware update over the air (FOTA) is what you need? Take a look here.

Best regards,

Elfving

[Leo Lin]

Hi Elfving,

Elfving said:

Sorry about that extra comment in Norwegian btw! I didn't mean to leave it there :)

Haha, it's OK！

Elfving said:

Yes, I am quite sure every example can be used along with normal DFU. Though there are other factors such as flash space etc. that might limit you.

OK, I want to think about how to integrate normal DFU into my example.

Elfving said:

Did you follow the additional steps for that mentioned here? 

I have seen this, but I don't know the difference in details. But I should not continue to look here at the moment, and I will look at this one again when I have time. If there are any questions, I will raise a ticket to ask questions, thank you！

Elfving said:

For mesh? Absolutely. 

The node takes a certain batch of that DFU it has received and sends it into the mesh network, with which it also is limited to 10 packets a second. It needs to do this so that the rest of the Mesh network also gets this DFU, though I guess in your case there is no Mesh network. Just this node.

I already know this, thank you, I can use the parameter -i to adjust the data transmission interval.

Elfving said:

The question is if you want to update just a couple of devices or an entire network of units. Mesh DFU is a good way updating an entire mesh network. I assume a normal DFU is what you want. If you want it activated without a button maybe a firmware update over the air (FOTA) is what you need? Take a look here.

I also think nromal DFU is more suitable for my needs.

I should send a command to enter DFU mode through the serial interface, not using buttons or ota.
But I am still not sure what I want to do.