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

Using two UARTs on nrf52833.

Hello! I have a few questions and concerns.

1) There are two UARTs on nrf52833. UART0 and UART1. How do I get them to work properly? For UART1, work is available only through DMA, because UARTE1?
2) On one of the UART, pin TX is connected to P0.24, and RX is connected to P1.00. After UART initialization, an interrupt with the error NRF_DRV_UART_EVT_ERROR is immediately triggered and when sending data, the end of sending interrupt is not called. It is noteworthy that if you do not use GPIO port 1, but use port 0, then everything is fine and everything works. Both UARTs behave the same.

The task in general is to work with the sim868 modem, where one UART is connected to the GSM modem itself, and the second is connected to the GPS.

  • Hello,

    Are you testing with HW flow control enabled, and in that case, have you connected the RTS and CTS line? Incorrectly configured flow control could potentially explain why you never get the TX complete event.

    1) There is no legacy UART1 without DMA as you say, so you need to use the UARTE driver (UART doc). 

    2) Induced noise on a floating RX input may be enough to trigger a NRF_DRV_UART_EVT_ERROR.  Have you tried to ignore the error and just re-enable UART RX ((void)nrf_drv_uart_rx()) on this event to see if any data comes trough at all.

    Also, do you use the NRF_GPIO_PIN_MAP() when specifying pins on port 1?  e.g., NRF_GPIO_PIN_MAP(1,0) => p.1.0

  • Hello.

    I don't use flow control.
    1) OK, I have UARTE0 and UARTE1.
    2) When UART is initialized on port 1, many interrupts with an error are immediately called. Moreover, if you call nrf_drv_uart_rx () again in the interrupt, then this function hangs. If we initialize UART to port 0, then everything will be without errors. Unfortunately, schematically, it is necessary to use 24 pins on port 0 for sending and 0 pin on port 1 (32 pins) for receiving.

    Yes, I am using the NRF_GPIO_PIN_MAP (1, 0) macro

  • Hello,

    Are you testing this on the nRF52833 DK, or a custom board? I noticed from the silkscreen on the backside that P1.00 is connected to the SWO input on the Segger interface chip. Maybe that's what's causing the interference.

    Solder bridge configuration:

    SB57 Closed Cut to disconnect the nRF52833 SWO line from the signal switch and the interface MCU
Related