NRF52 Secure UART DFU SDK 13.0

[rct42]

Greetings,

I'm having trouble being able to perform a DFU with the secure serial DFU. My setup:

• Using PCA10040 (nRF52832) with the s132_nrf52_4.0.2_softdevice.hex
• SDK v13.0.0, Keil v5.20, on a Windows 8 PC
• nRFgo Studio 1.21.2.10
• experimental_bootloader_secure_serial without flow control, 115200 baud

I'm using the secure DFU example (v13.0.0\examples\dfu\experimental_bootloader_secure_serial\pca10040_debug). The only modification I have made is to disable flow control (by editing nrf_serial_dfu.c:371). After programming the bootloader, I look at the debug messages via RTT. If I try to upload the demo app (dfu_test_app_hrm_s132.zip) via nRF Studio, I get "Received unsupported OP code" (and the op code is 0 if I step through using the debugger). Serial data is being exchanged between the PC and the PCA10040, as observed on an oscilloscope.

Meanwhile, I've tried another way of performing a DFU using the command: "nrfutil dfu serial -pkg dfu_test_app_hrm_s132.zip -p COM3 -b 115200". However, I get the error "pc_ble_driver_py.exceptions.NordicSemiException: No ping response". There is also no activity on the TX/RX data lines. I am using nrfutil version 2.3.0.

Questions:

1. Can someone confirm they have been able to perform a DFU via UART with the bootloader and examples in provided SDK 13?
2. Is there an example how to get another embedded device to perform the DFU? The target application is one with two microcontrollers where the master will transmit the NRF52 firmware update via UART from a SD card. [I've got this feature working with the old/legacy serial bootloader on a NRF51 and SDK v9.0, just upgrading the system to a NRF52 and SDK v13.0 for the extra BLE features]

[rct42]

I've just noticed a very similar thread. In my case, I cannot use flow control and also require another embedded device to perform the DFU (but would like to get it working with nrfutil first)

[rct42]

I've got a bit further with nrfutil. I had to supply "-fc 0" as an argument - I suspect that without this, it has flow control enabled by default (why!?!)? Anyway, the command I enter is:

nrfutil dfu serial -pkg dfu_test_app_hrm_s132.zip -p COM3 -fc 0 -b 115200

Meanwhile, the bootloader still reports "Received unsupported OP code", sends a response back ("Sending Response: [0x0, 0x3]"), then has a bunch of errors ("Error. Init command larger than expected" and "Failure to run packet write"), presumably because the nrfutil is trying to send the bootloader packets.

[rct42]

I've since confirmed the secure bootloader works with hardware flow control (I needed to swap the control lines). However, I still have yet to get the bootloader working without flow control.

I've uploaded a log of RTT debug messages with flow control enabled here.

Meanwhile the log of RTT debug messages without flow control (here) also starts off with:

WARNING:Received unsupported OP code

but eventually gives the following errors:

ERROR:Error. Init command larger than expected

nrfutil also reports the following error:

pc_ble_driver_py.exceptions.NordicSemiException: Unexpected Executed OP_CODE
Expected: 0x03 Received: 0x31

Suggestions for getting the secure UART bootloader working without flow control?

[bjorn-spockeli]

You should be able to run the Secure Serial Bootloader without Flow Control with the modifications described in this answer. Note: I think you only have to apply the changes in the secure serial bootloader project and not modify the nrfutil source code since you can set the baudrate and enable/disable flowcontrol, which was not possible in previous versions of nrfutil.

[rct42]

Thanks Bjorn, the serial DFU is working at 9600 baud without flow control. Out of curiosity, what do you think the reason for having to reduce the baud rate to 9600 for this to work without flow control? The legacy bootloader worked fine for us at 38400 baud...