Ack not received DFU UART

RE: Ack not received DFU UART

ScottD — Thu, 05 Jan 2017 16:21:56 GMT

Ahh, thanks for the reply. I misunderstood your previous comment and thought you fixed the issue by changing the timeouts. I fixed my issue as well. I was having problems with the timing of the USB connection in Linux and added delays elsewhere to remedy.

RE: Ack not received DFU UART

Geeogham — Thu, 05 Jan 2017 10:43:11 GMT

I used the default timeouts in the script. I found another issue in the example provided in the SDK11 for the DFU bootloader. The softdevice used to build the example image does not match the softdevice provided with the SDK. Can you check if the image you're trying to flash supports the softdevice on your device?

RE: Ack not received DFU UART

ScottD — Thu, 29 Dec 2016 16:48:12 GMT

@Geeogham: I think I am having a similar issue on my system. Could you possibly provide the updated timeouts you used in the python script to address this issue? Thanks!

RE: Ack not received DFU UART

Geeogham — Thu, 20 Oct 2016 15:36:23 GMT

Thanks Bjorn, I've solved the problem using the timeouts defined in the python script.

RE: Ack not received DFU UART

bjorn-spockeli — Thu, 20 Oct 2016 06:50:27 GMT

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

RE: Ack not received DFU UART

Geeogham — Fri, 14 Oct 2016 07:44:38 GMT

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.