Serial DFU is failing with invalid response

[IvenK]

Hi there,

I'm struggling to get a DFU over serial done. I'm using a nRF52840-DK (PCA10056), the nRF-SDK 15.0 and nrfutil 3.5.0.

I

- genereated the key pair,

- built the secure-bootloader (pca10056_uart_debug) example with my generated public_key.c,

- built the ble_app_blinky (pca10056, s140),

- programmed the s140 v 6.0.0 SoftDevice (chiperase),

- programmed the bootloader (sectorerase) and

- generated DFU package from the ble_app_blinky.hex (sd-req 0xA9) with my private key

When I perform the DFU with nrfutil i get the following error message:

pc_ble_driver_py.exceptions.NordicSemiException: Unexpected Executed OP_CODE.

Expected: 0x03 Received: 0x1D

Further analysis reveal that after the first firmware package is transfered, the host sends a CRC request [0x03] and the answer is [0x60, 0x1D, 0x02].

I have no idea why this is failing or what the response code [0x1D] means.

I would appreciate any help on that matter.

Kind regards,

Iven Kolterjahn

[IvenK]

Hi Einar,

debugging doesn't seem to work here. When I try to debug the code in SES the whole DFU process just hangs. I see some communication in the debug console, but then it just stops (SES seems to freeze also). SES starts responding after I unplugged the nRF-Board.

This is the output of the SES debug console:

<info> app: Inside main
<debug> app: In nrf_bootloader_init
<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> app: Enter nrf_bootloader_fw_activate
<info> app: No firmware to activate.
<debug> app: Enter nrf_dfu_app_is_valid
<debug> app: Return false in valid app check
<debug> app: DFU mode because app is not valid.
<info> nrf_bootloader_wdt: WDT is not enabled
<debug> app: in weak nrf_dfu_init_user
<info> app_timer: RTC: initialized.
<info> app: Entering DFU mode.
<debug> app: Initializing transports (found: 1)
<debug> nrf_dfu_serial_uart: serial_dfu_transport_init()
<debug> nrf_dfu_serial_uart: serial_dfu_transport_init() completed
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> app: Enter main loop
<debug> app: Shutting down transports (found: 1)
<debug> nrf_dfu_serial: Received ping 1
<info> nrf_dfu_serial_uart: Allocated buffer 200033AC
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_PING
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x9, 0x1]
<debug> app: Shutting down transports (found: 1)
<debug> nrf_dfu_serial: Set receipt notif target: 0
<info> nrf_dfu_serial_uart: Allocated buffer 200033AC
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_RECEIPT_NOTIF_SET
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x2, 0x1]
<debug> app: Shutting down transports (found: 1)
<debug> nrf_dfu_serial: Received serial mtu
<info> nrf_dfu_serial_uart: Allocated buffer 200033AC
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_MTU_GET
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x7, 0x1]
*** HERE IT FREEZES. THE LINES BELOW APPEAR AFTER THE DISCONNECT ***
<debug> app: Shutting down transports (found: 1)
<info> nrf_dfu_serial_uart: Allocated buffer 200033AC
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_SELECT (command)
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x6, 0x1]

I tried using the SDK 16.0.0 with nrfutil v6.0.1, but this also does not work. Strangely here I get 0xB3 as response (instead of 0x1D) to the CRC request.

[Einar Thorsrud]

Hi,

This is odd. I have never seen a similar issue before, and do not see a good explanation. It would be good to narrow down this problem a bit.

• Do you see this issue if you use a precompiled bootloader example and example .zip file?
• What if you test with nrfutil 5.2.0?
• If it still fails with precompiled bootloader and example .zip files, can you get a trace of the actual UART signal and see what happens. Where does the invalid request code come from?

Also, you should be aware that there are problems with J-Link on Linux, as described here. That may or may not be related (probably not since you write you see the same behavior when Windows is the DFU master).

[IvenK]

Hi,

I'm not sure, if I might be doing something basic the wrong way. I tried the example located at "SDK_16.0\examples\dfu\secure_dfu_test_images\uart\nrf52840".

The following commands were used to flash the chip:

nrfjprog -f NRF52 --program softdevice_s140.hex --chiperase

nrfjprog -f NRF52 --program hrs_application_s140.hex --sectorerase

nrfjprog -f NRF52 --program mbr.hex --sectorerase

nrfjprog -f NRF52 --program bootloader_secure_uart_debug_without_bonds_mbr.hex --sectoranduicrerase

nrfjprog -f NRF52 --program blinky_mbr.hex --reset --sectoranduicrerase

After it's all done LEDs 1 and 4 are on and nothing more can be seen - no blinking, no reaction on button presses.

Performing the DFU with nrfutil v6.0.1 now fails with response 0xF5 on the CRC request. The same is with v5.2.0.

All this is performed on a Windows 7 x64 machine.

[IvenK]

Alright, it was the JLink issue posted in your link. I did the 'MSDDisable' command in "JLink Commander". After that i could perform a DFU.