Serial DFU with higher baudrate using custom nRF52832 board and SDK 15.2

RE: Serial DFU with higher baudrate using custom nRF52832 board and SDK 15.2

tBStar — Mon, 06 Jul 2020 00:32:41 GMT

I've tried and it did make the transfer slower with the same baudrate of 9600. I went back and checked my parameters and I was able to clock in 115200 with the following configuration:

sdk_config:
#define NRFX_UARTE_DEFAULT_CONFIG_HWFC 1
#define NRFX_UARTE_DEFAULT_CONFIG_BAUDRATE 30801920

firmware project:
No change

nrfutil: V5 or earlier seems to perform faster and -fc 0 is required for this to work
nrfutil dfu serial -pkg .\ebyte_nrf52832\s132\armgcc\_build\dfu-package.zip -p COM5 -fc 0

RE: Serial DFU with higher baudrate using custom nRF52832 board and SDK 15.2

tBStar — Sun, 05 Jul 2020 19:31:29 GMT

Sorry I totally missed your question, I did not try it yet. I will and let you know. Thanks a lot

RE: Serial DFU with higher baudrate using custom nRF52832 board and SDK 15.2

Hung Bui — Mon, 30 Mar 2020 09:07:33 GMT

Hi,
Have you tried to set PRN to 1 and test with higher baudrate ?

RE: Serial DFU with higher baudrate using custom nRF52832 board and SDK 15.2

tBStar — Sat, 28 Mar 2020 15:00:32 GMT

The only way I could make the Serial DFU work is to cap the baudrate to 9600 with HWFC turned off. Any other attempt using different nRFUtil versions failed. I would like to increase the DFU process hence my question about increasing the baudrate. Sometime I would get NRF_ERROR_NO_MEM : 0x00000004, sometimes I get different error message, depending on the configuration.

Thank you for your explanation, it makes sense; however, the question remains, how can I speed up the DFU process if possible?

Whatever the answer may be, a hardware or software solution, I would like to know 🙂, someone must have done it by now.

Thank you.

RE: Serial DFU with higher baudrate using custom nRF52832 board and SDK 15.2

Hung Bui — Mon, 16 Mar 2020 14:59:51 GMT

Hi tBStar,

Could you please clarify. Did you have problem using higher baudrates WITH FLOW CONTROL or WITHOUT FLOW CONTROL ?

The challenge of doing DFU without flow control is that the current implementation doesn't use EasyDMA ( EasyDMA buffer is only one byte). It rely on the CPU to fetch the data out when it's filled. However, when the CPU is writing data to flash, it will be blocked. And the maximum time for writing data to flash is 338us. The time it takes for transmitting 1 byte at 9600bps is 833us which is quite safe. If you go to higher you may risk dropping bytes on UART.

What you can do is to change the PRN setting to 1. This way we limit the DFU central to send only one packet and then wait for the response back on the nRF52 before continue. Have a look here: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/lib_dfu_transport_serial.html?cp=7_1_3_5_2_3_0#lib_dfu_transport_usb
You can set PRN to 1 with by using -prn 1 with nrfutil.

But this would also slow down the DFU process.