nRF52832 UART Tx Pin Floating

[Mark J]

Hi,

Our application requires that we connect a nRF52832 to a Microchip PIC32MZ host via the Nordic parts UART (RS-232 at CMOS levels).

In a previous application, we successfully connected an nRF51822 to a TI AM35x part via UART with no difficulty, but in this case we are running into a challenge.

At present, we are still using the Nordic Dev Kit (DK) and Microchip Starter Kit (SK). The nRF52 DK UART connections are being accessed from P17 (P0.06 Nordic Tx and P0.08 Nordic Rx). These will be connected to a PIC32MZ SK. When we connect the Nordic Rx pin to the SK Tx pin, a Voltmeter or scope, we are getting Nordic restarts. These are a result of a "uart_error_handle" callback with event "APP_UART_COMMUNICATION_ERROR" in which we call "APP_ERROR_HANDLER(p_event->data.error_communication);"

We are confident in the PO.08 line being the UART Rx given the following config code.

#define RX_PIN_NUMBER 8 #define TX_PIN_NUMBER 6 #define CTS_PIN_NUMBER 7 #define RTS_PIN_NUMBER 5

const app_uart_comm_params_t comm_params = { RX_PIN_NUMBER, TX_PIN_NUMBER, RTS_PIN_NUMBER, CTS_PIN_NUMBER, APP_UART_FLOW_CONTROL_DISABLED, false, UART_BAUDRATE_BAUDRATE_Baud115200 };

APP_UART_FIFO_INIT(&comm_params,UART_RX_BUF_SIZE, UART_TX_BUF_SIZE,	                                                                     uart_error_handle,  APP_IRQ_PRIORITY_LOW, err_code);
APP_ERROR_CHECK(err_code);

Unless I misunderstand, the definition of Rx Pin to 8 is for P0.08 and not physical pin 8 (P0.06). This seems clear when I reference the nRF52 DK schematic and I assume that the default pin definitions that we are using (from pca10040.h) match the DK. - but this may be my issue.

If not, do we need to change the direction, pull-up, drive, or sense for the Rx pin used?

I would not expect a Voltmeter or scope to cause such an issue (restarts) unless the Rx line was floating.

... but my experience on these kinds of hardware connection issues is limited.

Thanks in advance.

Mark J

[Daniel Veilleux]

Hello Mark,

It looks like the UART's RX pin hasn't been pulled-up by default since nRF51 SDK v10.0.0 (see "{SDK_ROOT}/components/drivers_nrf/uart/nrf_drv_uart.c"). You can enable the pin's internal pull-up by modifying nrf_drv_uart.c or by adding nrf_gpio_cfg_input(rx_pin, NRF_GPIO_PIN_PULLUP); to an appropriate place in your code after APP_UART_FIFO_INIT is called.

Also, the default behavior of resetting the device when a UART error is detected is meant to make debugging a new design easier (f.e. drawing attention to the fact that nothing is pulling up a pin). A soft reset is not required by the hardware though and in most cases you should consider implementing a less-severe error handling policy.

Best regards, Daniel

[Mark J]

Hi Daniel,

Thanks for the response. I have added the code below to support pull-up.

// Enable pullup on tx pin. nrf_gpio_cfg( RX_PIN_NUMBER, NRF_GPIO_PIN_DIR_INPUT, NRF_GPIO_PIN_INPUT_DISCONNECT, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_S0S1, NRF_GPIO_PIN_NOSENSE);

... and the problem seemed to go away, but now it appears to come and go, even when the pull-up is in place. When the problem does not exist, I am receiving data just fine. When it shows up, I just get APP_UART_COMMUNICATION_ERROR in the UART error callback and I get no data.

If I cycle dev kit power - eventually the problem goes away.

Note that when in an erroneous state - I get APP_UART_COMMUNICATION_ERROR continuously - regardless of whether data is coming in on the Rx line or not.

Our hardware engineer has suggested that when using CMOS level RS-232 to drive an Rx line, no pullup should be required. What error could a missing pullup cause in the UART that would initiate the APP_UART_COMMUNICATION_ERROR?

[Daniel Veilleux]

Hello Mark,

If you take a look at the implementation of the nrf_gpio_cfg_input you can see that you should be using NRF_GPIO_PIN_INPUT_CONNECT instead of NRF_GPIO_PIN_INPUT_DISCONNECT. Why did you decided to not use nrf_gpio_cfg_input directly?

Do the two boards share a common GND? I would recommend putting a scope on the UART pins when it is misbehaving so you can see what's going on.

[Mark J]

Hi Daniel,

I had added the nrf_gpio_cfg call after seeing it within a forum post and before seeing your comment. I have since changed it to nrf_gpio_cfg_input. After more experimentation while watching SEGGER_RTT_WriteString terminal output, I can now better re-create the issue. It seems to be related to UART timing. If I process our commands a too high a frequency, I start to see these APP_UART_COMMUNICATION_ERROR values within the UART callback. I believe that we could be doing a better job managing the buffer. Is there documentation that details what can cause APP_UART_COMMUNICATION_ERROR?

[Daniel Veilleux]

Hello Mark,

The UART ERRORSRC register values are enumerated on page 337 of the Product Specification. The app_uart module includes the specific error source in the error_communication field of the app_uart_evt_t struct when it reports an APP_UART_COMMUNICATION_ERROR.