• State Verified Answer
  • Replies 18 replies
  • Subscribers 63 subscribers
  • Views 6497 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 121338
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Debug why DFU start packet not starting DFU

cswanson420

Firstly, platform: Sparkfun 52832 breakout board, DFU using UART, flashing an application, using nrfutil.

The problem fundamentally is the nRF52832 is not sending an ack that it received the DFU start packet. The packet is formatted correctly as defined by infocenter.nordicsemi.com/.../bledfu_transport_serial.html

the nrfutil code indicates a timeout as a result of not receiving the ack for the start packet.

I have the capability to use the nRF52DK with J-Commander to look at various places in memory and the registers, I just don't know how to go about determining why the SoC is not replying.

I also am guessing that there is the possibility the CPU in the nRF52832 may not actually be running the bootloader code, although from the appearance of the flashing LED the hardware presents itself as being in the bootloader mode.

Questions:

  1. Is there a means to derive whether the code executing is the bootloader code,
  2. If the code is bootloader code, how could one determine why the start packet is not being acknowledged and subsequently moving the the next state in the DFU state machine.
  • 0

    No, nrfjprog uses the SWD interface, it wraps a jlink .dll, so its basically the same as J-Link Commander, but with some extra nrf5x only features. The SoftDevice should be flashed with 0x00000000 as the start address and the bootloader should be flashed to the nRF52 starting from 0x7A000. Its much easier to just use nrfjprog, which handles this for you, just provide it with the hexfile.

  • 0

    I also recommend using Segger's Ozone Debugger, here is the link. Just place the .outfile from the _build folder in the armgcc folder and then open it using Ozone, and you're up and running.

  • 0

    I was able to program the device with multiple hex files, but alas, none of them were able to restore the functionality of a serial DFU for an application as the affected device was never willing to ACK the DFU start packet.

    I was able to install Ozone, and it's awesome. Just what I was looking for and I am able to debug the compile .out file from the Sparkfun repo. Many Thanks.

    I am impressed that an RX event on the UART should raise an event within the SoftDevice(?) and the subsequent ACK could be interrupted with a breakpoint. Placement of this breakpoint should indicate whether the RX event is being received or whether some other condition is causing the ACK to be suppressed.

    Any clue indicating where I could look for the UART start packet ACK response code would derive much gratitude.

  • 0

    I downloaded the repository and compiled the bootloader for the PCA10040 board (just uncommented CFLAGS += -DBOARD_PCA10040 and commented out #CFLAGS += -DBOARD_CUSTOM in the Makefile).I flashed it to the DK along with the Softdevice from the hex folder. I had to enable flow control with nrfutil in order to perform a serial DFU, i.e.

    nrfutil dfu serial -pkg ble_app_hrs.zip -p COM51 -fc
  • 0

    If you want to debug whether the nRF52 sends an ack or not, then you can place a breakpoint in rx_vendor_specific_pkt_type_handle() in hci_transport.c at the ack_transmit() calls.

Related