nRF52832 UART Tx Pin Floating

RE: nRF52832 UART Tx Pin Floating

Mark J — Thu, 12 May 2016 18:19:08 GMT

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.

RE: nRF52832 UART Tx Pin Floating

Daniel Veilleux — Wed, 11 May 2016 18:08:25 GMT

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.

RE: nRF52832 UART Tx Pin Floating

Mark J — Wed, 11 May 2016 17:57:35 GMT

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?

RE: nRF52832 UART Tx Pin Floating

Daniel Veilleux — Wed, 11 May 2016 17:13:29 GMT

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.

RE: nRF52832 UART Tx Pin Floating

Mark J — Wed, 11 May 2016 00:37:55 GMT

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?

RE: nRF52832 UART Tx Pin Floating

Daniel Veilleux — Fri, 29 Apr 2016 23:31:00 GMT

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