Debug why DFU start packet not starting DFU

RE: Debug why DFU start packet not starting DFU

bjorn-spockeli — Mon, 24 Apr 2017 06:13:48 GMT

@cswanson420: Glad to hear that you found the cause of the issue. Happy to help :)

RE: Debug why DFU start packet not starting DFU

cswanson420 — Mon, 24 Apr 2017 01:53:47 GMT

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.

RE: Debug why DFU start packet not starting DFU

cswanson420 — Mon, 24 Apr 2017 01:47:04 GMT

This worked! However, not on the broken device. When I put a break point at uart_event_handler in app.uart.c and invoke an nrfutil flash sequence , then the breakpoint is triggered and all is well. This does not happen on the broken device.

Therefore, I took another approach and recognizing p26 of the nRF53832 is used by the Sparkfun device as the UART RX channel, I used a Blinky program to toggle an LED using this pin. Again, on the working device, the LED flashed. On the broken device, the LED remained constantly illuminated.

Hence, the device is malfunctioning probably at the circuitry layer.

I learned a great deal with your help.

Thank you.

RE: Debug why DFU start packet not starting DFU

bjorn-spockeli — Thu, 20 Apr 2017 11:14:52 GMT

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.

RE: Debug why DFU start packet not starting DFU

bjorn-spockeli — Thu, 20 Apr 2017 09:25:17 GMT

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

RE: Debug why DFU start packet not starting DFU

cswanson420 — Thu, 20 Apr 2017 05:41:33 GMT

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.

RE: Debug why DFU start packet not starting DFU

bjorn-spockeli — Wed, 19 Apr 2017 14:38:50 GMT

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.

RE: Debug why DFU start packet not starting DFU

bjorn-spockeli — Wed, 19 Apr 2017 14:36:20 GMT

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.

RE: Debug why DFU start packet not starting DFU

cswanson420 — Wed, 19 Apr 2017 13:22:34 GMT

Also, is there any documentation how to compile code using arm-gcc to obtain a debug symbol file for use with J-LINKGDBServer?

RE: Debug why DFU start packet not starting DFU

cswanson420 — Wed, 19 Apr 2017 13:18:01 GMT

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?

RE: Debug why DFU start packet not starting DFU

bjorn-spockeli — Wed, 19 Apr 2017 12:01:42 GMT

Have you tried wiping the board and flashing the bootloader and softdevice hex files from the repo, here is the link, using nrfjprog?

RE: Debug why DFU start packet not starting DFU

cswanson420 — Tue, 18 Apr 2017 14:51:45 GMT

${NRFUTIL} --verbose dfu serial -pkg "${ZIP_ARTIFACT}" --port /dev/cu.usbserial-DN018TZM

NRFUTIL=/Users/cswanson/nRFutil.20170401/nrfutil.20170401_0_5_2/bin/nrfutil

BIN_ARTIFACT=$(find ${EXAMPLE_DIR}/_build/ -type f -name nrf*.bin)

ZIP_ARTIFACT=$(echo ${BIN_ARTIFACT} | sed 's/.bin/.zip/g')

EXAMPLE_DIR=$(find ${WD}/${SDK}/examples/${EXAMPLE}/pca10040 -type d -name armgcc)

Note: This command works on functioning Sparkfun devices.

RE: Debug why DFU start packet not starting DFU

bjorn-spockeli — Tue, 18 Apr 2017 13:59:32 GMT

Ah, so its a custom serial bootloader based on the serial bootloader from our SDK v11.0.0, that explains the LED behaviour. Could you post the nrfutil command you're using to start the serial DFU?

RE: Debug why DFU start packet not starting DFU

cswanson420 — Tue, 18 Apr 2017 13:54:36 GMT

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.

RE: Debug why DFU start packet not starting DFU

cswanson420 — Tue, 18 Apr 2017 13:50:59 GMT

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.

RE: Debug why DFU start packet not starting DFU

bjorn-spockeli — Tue, 18 Apr 2017 12:36:29 GMT

@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.

RE: Debug why DFU start packet not starting DFU

cswanson420 — Thu, 13 Apr 2017 12:39:50 GMT

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.

RE: Debug why DFU start packet not starting DFU

tvdstaaij — Wed, 12 Apr 2017 21:12:13 GMT

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.