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

[Einar Thorsrud]

Hi . Iven,

Can you post the full command you used to generate the DFU package and the full command you used to do the DFU operation? (In case there is no problem there, have you attempted to use a newer nrfutil version?)

[IvenK]

Hi Einar,

nrfutil pkg generate --hw-version 52 --application-version 1 --application ble_app_blinky_pca10056_s140_1.hex --sd-req 0xA9 --key-file demo_private.key

DFU operation:

nrfutil dfu serial -pkg app_fw1.zip -p /dev/ttyACM0 -b 115200

The thing is, in the end I'll use an ARM-based processor running Linux and utilizing the UartSecureDFU from Jimmy Wong. It is based upon the nrfutil v3.5.0. I generate the Linux using Yocto and got some trouble including the nrfutil as a python application. So, I found JW's C application.

[Einar Thorsrud]

Hi,

I see. So everything looks OK until the bootloader complains about the unsupported OP_CODE, which was never transmitted by nrfutil in the first place. I think we need to look at what happens in the bootloader.

Perhaps the best would be to put a breakpoint in the NRF_DFU_OP_CRC_GET case in nrf_dfu_data_req() in <SDK>components\libraries\bootloader\dfu\nrf_dfu_req_handler.c. Does it get this far? If not, what happens? If the request is correctly received, how is it processed? How does it result in the error response?

[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.