Ack not received DFU UART

[Geeogham]

Hello,

I'm having problems running the DFU over serial bootloader example. The nrfutil command to update the application fails with message "timed out waiting for acknowledgement from device".

When I connect a logic analyzer to the UART pins I can see the start packet sent from the PC to the nRF52. Then the nRF52 sends the ack packet, 6 bytes in total (4 for ack + 2 for SLIP protocol), 2 bytes at a time with 2 ms in between. Hence the PC times out.

I cannot figure out what is causing this Tx underflow. Has anyone seen this issue?

My setup is:

• SDK 11.0
• Softdevice 132 2.0.0
• NINA B112 chipset from u-blox (contains a nRF52832)
• compiler: arm-none-eabi-gcc 5.4.1

[Geeogham]

I think I've found the problem: the bootloader starts erasing the swap to receive the application image while the ack for the start packet is still being transmitted. Accessing the flash blocks the CPU from sending more bytes to the UART, which explains the gaps in the transmission.

Basically ack_transmit() tries to send as many bytes as possible and relies on the next TX done interrupt to send more bytes when the UART is busy. So the call to ack_transmit() first sends 2 bytes then returns before the entire packet has been transmitted and process_dfu_packet() can run and start to prepare the flash. Erasing a page in flash disables all interrupts, so the UART interrupts are processed late and we see these 2 ms gaps (consistent with the time it takes to erase a page) between bytes sent over the UART.

Has anyone had the same problem? It seems a synchronization mechanism is needed to delay accessing the flash until after the ack has been transmitted.

[bjorn-spockeli]

@geeogham: I suggest that you take a look at this python script from pc-nrfutil, which is used to perform serial DFU. Around line 60 you'll see several the definitions of several delays, e.g. how long you should wait before sending more data over the UART after you have sent the start packet.