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

How is the RTS-pin controlled in UART with flowcontrol

I am using a nrf52832 to communicate via UART to a GSM module (AT commands).

I have setup the device with a baud rate of 9600 and using HW flowcontrol. The nrf52 is doing other stuff at the same time such as communicating via bluetooth.

The problem occurs when the AT commands gets longer. After the nrf52 has send its command it sets the RTS pin and the GSM module can't send its response. The pin isn't cleared until the nrf52 sends a new command. See the picture below (0 is TX, 1 is RX, 2 is CTS, 3 is RTS).

image description

I know the pin is supposed to be set when the softdevice does something, but in what other cases is it set, and what might cause it in this case?

edit: Accidently wrote spi instead of uart

edit: Thanks for the insight guys. It helped me solve the problem. In my case I had a breakpoint in a different part of the code that sometimes triggered. This of course stopped the processor and the rx fifo would fill up.

Parents
  • "I know the pin is supposed to be set when the softdevice does something"

    Not directly - the softdevice knows nothing at all about whether you are using the UART or not and doesn't do anything to the RTS signal. If you're thinking the softdevice disables UART by forcing the RTS pin high, when it's doing things, that is not correct.

    The RTS pin goes high when the buffer space falls to a minimum to stop the sending device sending until you've read the data which already came in so you don't lose it. Are you reading the data which comes in?

Reply
  • "I know the pin is supposed to be set when the softdevice does something"

    Not directly - the softdevice knows nothing at all about whether you are using the UART or not and doesn't do anything to the RTS signal. If you're thinking the softdevice disables UART by forcing the RTS pin high, when it's doing things, that is not correct.

    The RTS pin goes high when the buffer space falls to a minimum to stop the sending device sending until you've read the data which already came in so you don't lose it. Are you reading the data which comes in?

Children
No Data
Related