This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Hi,

I built a simple custom board with an nRF52832 ebyte BLE module with no added components except for the RST and DFU buttons, the serial wiring are the same pins (RX, TX, DTR, CTS) as with the DK board. While I can program my custom board with any application using 9600 bauds without flow control, I find it impossible to use higher baudrates with flow control turned on on the bootloader. What can I do to enable higher baud rates, let's say 115200 baud rates? 

Thanks

Parents
  • 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. 

Reply
  • 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. 

Children
Related