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.

[cswanson420]

A solution is to use Segger Ozone and put a breakpoint at the top of the function uart_event_handler in app.uart.c and invoke an nrfutil dfu serial flash sequence. The debugger will break at the top of this function and you shall be able to follow the logic from this point to determine either why the DFU packet is formatted incorrectly, not processed at all, or simply not detected in my case - in which case the breakpoint is not triggered.

Pertaining specifically to the Sparkfun 52832 breakout, use a Blinky program to toggle pin 26 wired to an LED. If the LED flashes (confusing term I know), then the circuit is good. If not, then the circuit is bad and subsequently the board will not work using this pin. You may get wiring access to pin26 from the UART RX pin on the board.