Keep DTR/RTS high during DFU

Hi guys:

Right now I have my custom board using nRF52833.

I wang to use DFU over uart to upgrade firmware.

I try a different way to enter DFU mode, and this require DTR stay low during the whole precess.

Can this  achieved by modifying the code in nrfutil python script or bootloader?

Thanks in advance!

Parents
  • Hello,

    During a DFU process, the nRF is reset at least once. A successfull DFU usually has 2-3 resets depending on what SDK you are using (nRF5 SDK or nRF Connect SDK).

    During a reset, there is no way to keep a pin as an output. You can set it immediately after the reset, but there will be a small gap. If that doesn't work for you, you would need to use an external pullup or pulldown resistor. That is unfortunately the only way to keep GPIO states while resetting the nRF. 

    Best regards,

    Edvin

  • Hi Edvin,

    Thanks for your reply.

    Since I individually have an usb-serial pcb board. The DTR/RTS will keep high when there is no data transport on TXD/RXD. During the DFU process, DTR/RTS will become low before the DFU finished.  I just want to know if I can always let DTR/RTS stay high on this usb-serial pcb board.

    Alien

  • Hello Alien,

    So you are saying that your usb-serial pcb already pulls up the DTR/RTS? 

  • Hi Edvin,

    Yes,when it pluged in my computer, the DTR/RTS stay high.

    Alien

  • Ok. If you are seeing that it dips down even with an external pullup then it must be that the nRF actually pulls it down. What bootloader are you using? And what SDK version are you using?

    On the other side. Isn't the purpose of the DTR/RTS to prevent the other device sending data whenever the target is not ready? I would say that it is better to have the nRF let the connected device know that it shouldn't send data when it is not turned on and the application is running.

    BR,
    Edvin

  • I'm using secure_bootloader_uart_mbr_pca10040, and I have modified pca10040.h to custom_board.h. 

    And the SDK version is nRF5_SDK_17.0.2_d674dde.

    Yes, you're right about DTR/RTS. But on my custom board ,I need to use RTS to simulate button press to let it enter DFU mode. I use pyserial to setRTS(1) and setRTS(0) to do so.

    And I use DTR to do reset. I need DTR to keep high cause once it becomes low, the board will continuous reset during DFU process. I just need to find a way to let it keep high.

    Right now I'm thinking about modifying nrfutil or nrf_uarte.h.

    Hope you can understand me!

    Best,

    Alien

Reply
  • I'm using secure_bootloader_uart_mbr_pca10040, and I have modified pca10040.h to custom_board.h. 

    And the SDK version is nRF5_SDK_17.0.2_d674dde.

    Yes, you're right about DTR/RTS. But on my custom board ,I need to use RTS to simulate button press to let it enter DFU mode. I use pyserial to setRTS(1) and setRTS(0) to do so.

    And I use DTR to do reset. I need DTR to keep high cause once it becomes low, the board will continuous reset during DFU process. I just need to find a way to let it keep high.

    Right now I'm thinking about modifying nrfutil or nrf_uarte.h.

    Hope you can understand me!

    Best,

    Alien

Children
  • Hello Alien,

    You need to use DTR to reset the nRF into DFU mode? If that is the case, you should consider using another pin, disabling flow control, or use some other method to enter DFU. 

    It is possible to use the VREGRET register to tell the nRF to enter DFU mode after the next reset. Could that be an option? In that case, you could use pretty much any event (button press/long button press/ specific UART command, Bluetooth message) to tell the device to enter DFU mode. If that is feasible, then I can give you some pointers if you'd like.

    BR,
    Edvin

  • Hi Edvin,

    I'm really grateful for your reply.

    Actually I can realize dfu by using other way.

    But I have to use dtr/rts to try to do reset.

    So can you tell me why it is hard to keep dtr/rts high during DFU.

    Best,

    Alien

  • When you reset the device, all GPIOs will be put back in their default state (Disconnected input), so this means that from the nRF's side, the pin is floating. It is not pulled down. I suggest you try to debug this sequence, to try to pin-point when the pin is pulled down. It is most likely right before or right after the reset. Check when the UART is enabled, and if it is disabled before the reset.

    Best regards,

    Edvin

Related