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

nRF52832 UART Tx Pin Floating

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

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

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

Reply Children
No Data
Related