Reset Bootloader for SDKv11.0.0 using DFU /HCI over UART

RE: Reset Bootloader for SDKv11.0.0 using DFU /HCI over UART

Phil — Sat, 22 Feb 2020 00:37:33 GMT

The issue isn't fixed. I could not get the boot-loader to restart a DFU if a DFU doesn't run to completion.

We have a workaround. That is if a DFU is interrupted, don't restart it for 120secs to give time for the boot-loader to perform a software reset of the nRF51.

RE: Reset Bootloader for SDKv11.0.0 using DFU /HCI over UART

Amanda Hsieh — Fri, 21 Feb 2020 10:20:45 GMT

Hi,

It seems you fixed issue is fixed, right? Please correct me if I misunderstand. Thanks.

-Amanda H.

RE: Reset Bootloader for SDKv11.0.0 using DFU /HCI over UART

Phil — Mon, 10 Feb 2020 21:58:52 GMT

I did find the boot-loader times out and resets the nRF51 after 120secs if no serial data is received.

After the nRF51 reset, another DFU can be performed.

RE: Reset Bootloader for SDKv11.0.0 using DFU /HCI over UART

Phil — Mon, 10 Feb 2020 21:56:36 GMT

I corrected the Out Of Sequence Packet Error. On the next DFU I sent the Start packet with SEQ=1 and the nRF51 replies with ACK=4. This is out of sequence as we expect ACK = 2. The received ACK indicates the nRF51 was expecting SEQ = 4. (This lines up with the stop packet of the previous DFU which sent SEQ=3). The received start packet is discarded, evident by the fact the application memory never gets erased. We then re-send the start packet with SEQ=4 and receive a response with ACK=5. This is the correct acknowledgment. By the way I tested re-sending the start packet with all other SEQ values and always received ACK=4. This was the only value of SEQ where the ACK=SEQ+1 (except SEQ=3. In that case I can't tell if this is the correct ACK or an error. Given the previous STOP packet send SEQ=3, this must be an error).

However, despite receiving the correct ACK, the second DFU doesn't get very far. The Start packet is acknowledged but the application memory isn't erased. There is no response to the INIT packet.

Also I found inconsistent behaviour. If the first DFU sends the STOP packet, but the image is invalid (wrong length or CRC), it stops responding at the INIT packet of the next DFU. However if the DFU is interrupted part-way through and the STOP packet is never sent, then the DFU can be recovered if you send a START packet twice (with correct SEQ value).

We can't test using nrfutil as we don't have a serial connection to the nRF51. The nRF51 serial port is directly connected to the master micro, and we can't access the pins.

RE: Reset Bootloader for SDKv11.0.0 using DFU /HCI over UART

Amanda Hsieh — Mon, 10 Feb 2020 13:38:56 GMT

Hi,

I am checking with the development team. I will be back asap I have any update.

Do you see the same behavior if you are using nrfutil instead of your own software?

-Amanda H.

RE: Reset Bootloader for SDKv11.0.0 using DFU /HCI over UART

Phil — Fri, 07 Feb 2020 05:04:35 GMT

The problem is Out Of Sequence Packet Error.

RE: Reset Bootloader for SDKv11.0.0 using DFU /HCI over UART

Phil — Fri, 07 Feb 2020 03:42:59 GMT

Actually that didn't work. Not incrementing SEQ and ACK resulted in our DFU command sequence running through to the end and being able to repeat DFU, but the boot-loader didn't actually flash any data into the application flash memory.

So it is essential that SEQ increments. And I think the problem is what the SEQ and ACK values are in the start packet when the DFU is repeated. My guess is that the transport layer doesn't care that the DFU ended and the boot-loader didn't jump to the application.

Is there any further information on how SEQ and ACK works with reliable packets in the HCI DFU?

RE: Reset Bootloader for SDKv11.0.0 using DFU /HCI over UART

Phil — Fri, 07 Feb 2020 01:24:00 GMT

The problem seems to be with SEQ and ACK numbers in the HCI header of the DFU packet.

The DFU protocol packets have a 4-byte HCI header. The first byte has two 3-bit fields; SEQ and ACK. Our software was starting with SEQ=1, ACK=2 when the DFU Start packet is sent and incrementing these on every DFU packet sent to the nRF51.

By trial and error I found that DFU still works ok of these fields and not incremented, and can repeat a DFU if the application is invalid and the boot-loader keep running.

Also it requires the SEQ=1, ACK=2. Other values cause a DFU to fail.

The reference for the HCI header is in the "Bluetooth Core Specification v5.00, Vol 4 Part D Three Wire UART Transport Layer".

The specification shows SEQ being incremented (mod 7) for each sent packet. Also there is a non-zero SEQ value in the response. The nRF51 boot-loader response packets always have SEQ=0.

It appears that the nRF51 bootloader doesn't follow the BLE specification for the HCI header.

We only require to receive response packets so that we know when to send the next DFU command. We don't intend to implement packet re-transmissions so this will work for us.

RE: Reset Bootloader for SDKv11.0.0 using DFU /HCI over UART

Phil — Thu, 06 Feb 2020 22:56:42 GMT

This is the documentation from nRF5 SDKv11.0.0 for the serial DFU we are using:

Software Development Kit > Previous versions of nRF5 SDK > nRF5 SDK v11.0.0 > Examples > DFU bootloader

examples > BLE & HCI/UART Bootloader/DFU

It only describes four DFU commands for controlling the boot-loader

RE: Reset Bootloader for SDKv11.0.0 using DFU /HCI over UART

Phil — Thu, 06 Feb 2020 22:10:21 GMT

That does a software reset from within the nRF51822. What I meant is software reset via DFU command so that the other microcontroller can reset the nRF51822 when it is boot-loader mode. Or at least a DFU command that restarts the boot-loader.

So far I can only see there are 4 DFU command to control the bootloader: Start Packet, Init Packet, Data Packet and Stop packet. I assumed that sending a Start packet DFU command would reset the boot-loader. However, that is not what we observe.

If the DFU fails to complete, so the boot-loader doesn't run the application after the DFU Stop packet is sent, then the nRF51 remains in bootloader mode. When another DFU is started, the bootloader fails and stops sending ACK packets after a couple of DFU command packets. The only recovery mechanism so far is to reset the nRF51. After a reset (power on or by JLink) the nRF51 restarts in boot-loader mode, because the application is invalid, and will correctly perform a DFU.

Our problem is that we have no way of doing a hardware reset of the nRF51 from the other microocontroller. We only have the UART connection and nRF51 GPIO pin P0.19 and P0.17.

Is there a known reason why a DFU cannot be repeated while the nRF51 is in boot-loader mode?

RE: Reset Bootloader for SDKv11.0.0 using DFU /HCI over UART

Amanda Hsieh — Thu, 06 Feb 2020 12:13:14 GMT

Hi,

If you have enabled the SoftDevice you can use sd_nvic_SystemReset, if not you can use nvic_systemreset().

-Amanda H.