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

[Phil]

We are using another microcontroller to update the application firmware in an nRF51822 over the UART using the DFU HCI protocol from SDKv11.0.0.

The nRF51822 uses the HCI/UART bootloader from the example in SDKv11.0.0.  We have implemented the DFU HCI protocol as described in SDKv11.0.0, which sends a Start packet, then Init packet followed by data packets and finally a stop packet.  This works Ok when everything is correct.

Our problem is that if the application image is invalid  (ie: the application image CRC is invalid, or the image download isn't complete), then after receiving the DFU STOP  packet the nRF51822 remains in boot-loader mode as it should but we can't do another DFU.  When the DFU is restarted then the nRF51822 boot-loader fails to send ACK packets.   It doesn't always fail at the same point.  Sometimes it stops after the START packet and other times it goes until several DATA packets have been sent.

If the nRF51822 is reset, by either power off/on or via JLink (nrfgprog --reset), the the boot-loader starts again and can repeat the DFU Ok.

We don't have any means of doing a hardware reset of the nRF51822.  So once this situation occurs we are stuck.

Is there a software command to reset the boot-loader?

[Amanda Hsieh]

Hi, 

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

-Amanda H.

[Phil]

The problem is Out Of Sequence Packet Error.

[Amanda Hsieh]

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. 

[Phil]

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. 

[Phil]

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.

[Amanda Hsieh]

Hi, 

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

-Amanda H.

[Phil]

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.