DFU Bootloader using BLE + UART: I need to selectively not initialise UART

[Nick_RA]

I have a customised bootloader using uart + BL, built from the SDK examples and modified using articles found here. It works - most of the time. The product is a cusom board which provides connections to the outside world either by uart or by gpio signalling. Both are provided - it's up tto the customer which method they use.

My issue is thus: If the uart is initialised without an interface physical connection, the system hangs (and in my case the watchdog resets it). I discovered this when developing my application and I got around it by checking the gpio line first as the "idle" state of a logic-level uart is high, and only initialising the uart if there is a signal present.

For this same reason, the BLE+UART Bootloader crashes if there is no physical interface connected. So I want to prevent the uart service from running in the same way. But I'm finding it difficult to follow the SDK code, especailly as documentation is scant.

So can you advise the best way for me to skip the uart listener at runtime?

[Menon]

Hello,

Could you please specify which SDK version you are using? Additionally, you mentioned it's a custom board; could you also indicate which Nordic chip this board is based on?

Kind Regards,

Abhijith

[Nick_RA]

It's nRF52832 & SDK 17.1.0

[Vidar Berg]

Hello,

The way it normally works is that the bootloader initializes both the serial and BLE transport, and the bootloader will thenwait for DFU to be initiated on either transport. The first transport that receives the DFU start command will 'close' the other transport.

My issue is thus: If the uart is initialised without an interface physical connection, the system hangs (and in my case the watchdog resets it). I discovered this when developing my application and I got around it by checking the gpio line first as the "idle" state of a logic-level uart is high, and only initialising the uart if there is a signal present.

Since the UART bus may be physically disconnected, I recommend enabling the internal pull-up resistor on the RX line to prevent this input from floating. You can do it by adding this line after UART init but before RX enable:

NRF_GPIO->PIN_CNF[RX_PIN_NUMBER] |= GPIO_PIN_CNF_PULL_Pullup << GPIO_PIN_CNF_PULL_Pos;

If the RX input is left floating, it will often lead to an NRF_DRV_UART_EVT_ERROR error event.

Best regards,

Vidar

[Nick_RA]

Hi Vidar,

Sorry if this sounds rude, but is this a known solution, or your educated guess? For example I would expect that the uart initialisation code sets up the gpio itself so I would expect the pullup to be disabled in that case.

Irerspective, I would still like to know how I can selectively skip the uart transport if possible.

[Vidar Berg]

It's common practice to enable the pull-up on the RX line if the bus may become disconnected. You are correct that the UART configures the GPIO without the pull-up enabled.

You may connect a debugger to your board to check if the NRF_DRV_UART_EVT_ERROR event is raised as I suspect, or if the bootloader hangs due to something else.

Nick_RA said:

Irerspective, I would still like to know how I can selectively skip the uart transport if possible.

You can't reliably read the signal level if the input is floating, so you would need another way to determine if the UART is connected.