req_pin_idle() in uart_nrf_sw_lpuart.c

[td-pradecki]

Hi!
I am developing application for nrf52840 on nrf connect sdk 2.9.0.
I am using mcuboot with serial transport as a bootloader. In bootloader I am using uart with hwfc and in application I am using lpuart for hci communication.

The same pin is used for hwfc rts and for lpuart req pin.

I was experiencing strange behaviour of req pin when hwfc was enabled in bootloader.

I managed to fix the problem by changing:

static void req_pin_idle(struct lpuart_data *data)
{
	nrf_gpio_cfg(data->req_pin,
		     NRF_GPIO_PIN_DIR_OUTPUT,
		     NRF_GPIO_PIN_INPUT_DISCONNECT,
		     NRF_GPIO_PIN_NOPULL,
		     NRF_GPIO_PIN_S0S1,
		     NRF_GPIO_PIN_NOSENSE);
}

from uart_nrf_sw_lpuart.c to:

static void req_pin_idle(struct lpuart_data *data)
{
	nrf_gpio_cfg(data->req_pin,
		     NRF_GPIO_PIN_DIR_OUTPUT,
		     NRF_GPIO_PIN_INPUT_DISCONNECT,
		     NRF_GPIO_PIN_NOPULL,
		     NRF_GPIO_PIN_S0S1,
		     NRF_GPIO_PIN_NOSENSE);
	nrf_gpio_pin_clear(data->req_pin);
}

According to lpuart documentation, this is correct logic. I think it is a bug and should be passed to ncs developers.

Kind regards,
Piotr Radecki

[dejans]

Hi,

Thank you for reporting this potential issue.

What do you refer to as hwfc? How did you enable it in the bootloader?

I was experiencing strange behaviour of req pin when hwfc was enabled in bootloader.

Can you elaborate on the problem? What was strange behavior about? Do you have any logs to share?

Best regards,
Dejan

[td-pradecki]

Sorry, I kind of omitted exact issue description since fundamental issue seems to be that this code is not compatible with the doc https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/drivers/uart_nrf_sw_lpuart.html#uart-nrf-sw-lpuart.

However I'll try to quickly describe how the problem manifested. My use case is that mcuboot enters serial recovery mode. It uses mcumgr with transport layer uart and flow control. On the other hand, application acts as a bluetooth controller and communicates with the host using hci based on lpuart.

Since mcuboot left req pin in high state and lpuart in app never drove it low, there was high state instead of low state on the req line which effectively destroyed the communication.

Please let me know if I can provide any more description :)

Best regards,

Piotr

[dejans]

Hi Piotr,

Which board do you use?

Is everything working fine if you do not use bootloader?

td-pradecki said:

I kind of omitted exact issue description since fundamental issue seems to be that this code is not compatible with the doc https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/drivers/uart_nrf_sw_lpuart.html#uart-nrf-sw-lpuart.

Can you elaborate on this incompatibility?
Control protocol specifies "The REQ line of the first device is connected with the RDY line of the second device. It is configured as an output and set to low."

Best regards,
Dejan

[td-pradecki]

I am using custom board based on nrf52840.
Yes, everything worked fine without using bootloader and even with flow control on req pin in bootloader.

Please note that driver implementation prior to my modification was:

static void req_pin_idle(struct lpuart_data *data)
{
	nrf_gpio_cfg(data->req_pin,
		     NRF_GPIO_PIN_DIR_OUTPUT,
		     NRF_GPIO_PIN_INPUT_DISCONNECT,
		     NRF_GPIO_PIN_NOPULL,
		     NRF_GPIO_PIN_S0S1,
		     NRF_GPIO_PIN_NOSENSE);
}

which means that line is configured as output but not set low. It probably assumes that pin was set low prior to that operation which is not always true.

Best regards,
Piotr

[dejans]

Hi Piotr,

Thank you for providing additional information.

We will look into this possible bug internally. I will get back to you with status update probably during next week.

Best regards,
Dejan