• State Suggested Answer
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 62 subscribers
  • Views 2217 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 243911
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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?

Parents
  • 0

    Hi, 

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

    -Amanda H.

  • 0 in reply to Phil

    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. 

  • 0 in reply to Amanda Hsieh

    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. 

  • 0 in reply to Amanda Hsieh

    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.

Reply Children
Related