OTA DFU hci_mem_pool_rx_produce fails

[Ray]

I'm making progress, but still struggling to get the sample DFU built into NRF Toolbox to download successfully with my bootloader. Using hrs_dfu_s130_*.zip.

For this, and for my app, it gets to the point where it is downloading the firmware, but after 7-9 packets processed properly by app_data_process in dfu_transport_ble.c, I get an err_code back from hci_mem_pool_rx_produce == ERR_NO_MEM.

At first I thought that perhaps (because my base app is fairly large) there wasn't enough room for the dual-bank update, but when I switch to single-bank instead [no other changes] it still fails the same way.

Thoughts? Thank you very much.

[Ray]

For the record, in case anyone else runs into this, here is another instance of exactly the same problem: devzone.nordicsemi.com/.../

The buffers are being consumed faster than they are being released by the DFU callback function, hence the DFU operation fails.

This person's ultimate resolution is not irrelevant - the notion that UART debug instrumentation may be slowing down the processing of incoming data packets. I will look into this.

[Ray]

Indeed that was the problem. After removing UART debugging code, the timing was such that there were sufficient hci memory buffers to keep up, and the DFU completed.

[bjorn-spockeli]

You can also try to increase the connection interval by modifying the follwing defines in dfu_transport_ble.c

#define MIN_CONN_INTERVAL                    (uint16_t)(MSEC_TO_UNITS(15, UNIT_1_25_MS))             
#define MAX_CONN_INTERVAL                   (uint16_t)(MSEC_TO_UNITS(30, UNIT_1_25_MS))

Setting the minimum to 30 and maximum to 50 should help.