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

  • Hi Daniel, It turns out that we had a software issue. We had mistakenly included a nrf_delay_ms(1000) call within our UART callback when app_uart_evt_t->evt_type was APP_UART_TX_EMPTY. If we used the UART infrequently, this was not an issue. If we used the UART frequently, the nrf_delay_ms call caused the unit both generate APP_UART_COMMUNICATION_ERROR and execute code much more slowly. Our changing UART access frequency coincided with our enabling pull ups (bad luck or timing). This led us down the wrong path of searching for a hardware issue. We removed the nrf_delay_ms() call and we have left the pullup code in place (that you provided) for good measure, and comms are working solidly now. Tx for your help as always.

Related