• State Verified Answer
  • Replies 18 replies
  • Subscribers 62 subscribers
  • Views 6428 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

    Some suggestions to check:

    • According to its Github readme, the latest version of nrfutil only supports the new serial bootloader format, so I believe you would need a legacy version of nrfutil to flash an application through the legacy bootloader.
    • I personally had trouble with UART DMA in the serial secure bootloader on the nRF52, and had to set all UART DMA support defines to 0 in sdk_config.h to get it to work.
  • 0 in reply to tvdstaaij
    • Yes, thank you. I am using the 0.5.2 nrfutil and the process works flashing an identical device. I did something rash with this particular device that has caused it to not be flashed other than to do a J-link commander loadbin operation.
    • This error state has really given me an opportunity to dive into the internals of the NRF52 SoC that I otherwise would not have done. Indeed, this experience may cause me to abandon completely serial DFU and got the extra length to achieve BLE DFU.
    • Notwithstanding, I am nagged that after flashing the broken device with a functioning devices "memory" I was able to get the bootloader LED sequence to activate - which is a flashing with a reducing frequency - as I had erased it during examination, but the device will not begin the DFU process upon receiving the start packet.
    • So, is the device toast? Or, is there a means to understand why the bootloader is not recognizing the start packet.
  • 0

    @cswanson420: From your description in the comments ;" I was able to get the bootloader LED sequence to activate - which is a flashing with a reducing frequency" , it could sound like you have not flased the single_bank_serial_s132 example. It does not blink a LED, it only turns one on at startup.

  • 0

    This could be. However, I did a savebin operation on a functioning device for the flash, data, code, UICR, FICR, APB, AHB, internal and external peripheral memory regions. I used these files to do a loadbin operation onto the malfunctioning device. After this loadbin operation, the device started to perform its bootloader led sequence. Prior, it did not. I may have done the UICR and FICR regions incorrectly as I stored 4096 bytes rather than 256 so maybe this overwrote something? Just guess right now.

  • 0

    What I am trying is to compile the sparkfun code so I may flash it and then use GDB with JLink GDBServer to set breakpoints in the bootloader to determine whether the DFU start packet is being detected or not.

Related

core_v2_widget.Hide()