• State Suggested Answer
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 62 subscribers
  • Views 2228 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 Amanda Hsieh

    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.

Reply
  • 0 in reply to Amanda Hsieh

    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.

Children
No Data
Related