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]

Yes, I have unfortunately. The nrfjprog program uses the serial UART to program the device, so it doesn't work since the device doesn't ACK the DFU start packet. The only thing that does work is programming the device with the nRF52_DK with J-Link Commander.

What would be a big help is to better understand how to derive the target memory address to write both the softdevice and the dfu so I could use the nRF52_DK to reprogram the device.

I may be naively assuming 0x00000 is the location of the softdevice.

There is also a file called dfu_gcc_nrf52.ld in the Sparkfun Repo that appears to have memory offsets.

Are these offsets relevant for proper flash memory offset programming?

For instance:

FLASH (rx) : ORIGIN = 0x7A000, LENGTH = 0x4000

Would I write the compiled binary to 0x7A000?