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

APP UART COMMUNICATION ERROR eror code

both for APP_UART_FIFO_INIT and APP_UART_INIT i never receive APP_UART_DATA_READY

but at least i get APP_UART_DATA sometimes. most of the times i get APP_UART_COMMUNICATION_ERROR with uart_evt->data.error_communication being either 1 or 4 or 8 randomly.

what is the meaning of the error code there and how can i use it to determine the actual error? The data on the line looks fine in a logic analyzer.

Parents
  • (edit: might not be the correct answer?)

    Turns out that i incorrectly assumed turning on flow control would allow me to block the uart event handler for longer than one cycle. Apparantly flow controll doesn't work that way or is too slow or something.

    Even with flowcontroll enabled , do not block the uart event handler

    Also the uart event handler must be a high priority interrupt, otherwise the softdevice breaks it. The internal hw buffer is just 6 bytes or so, that leaves enough cpu time to put those bytes into an app_fifo and trigger event scheduler to call a function on the mainloop with lower priority to parse the data.

Reply
  • (edit: might not be the correct answer?)

    Turns out that i incorrectly assumed turning on flow control would allow me to block the uart event handler for longer than one cycle. Apparantly flow controll doesn't work that way or is too slow or something.

    Even with flowcontroll enabled , do not block the uart event handler

    Also the uart event handler must be a high priority interrupt, otherwise the softdevice breaks it. The internal hw buffer is just 6 bytes or so, that leaves enough cpu time to put those bytes into an app_fifo and trigger event scheduler to call a function on the mainloop with lower priority to parse the data.

Children
  • Sorry but neither of those two conclusions really make much sense. Flow control when enabled on both sides with RTS/CTS connected absolutely stops the UART in both directions from overflowing its buffer. That has nothing at all to do with the softdevice nor interrupt priorities or anything else. As long as the RTS/CTS are deasserted, you can take as long as you like to service the UART, cycles, milliseconds or seconds and it and the other end will just sit there quietly and wait for buffer space to become available.

    So what you're seeing has to be something else.

  • @RK Hmm. I'll try to make a full logic analysis including CTS/RTS when i get the time. I did see a difference when enabling flow control, so i dont think it plain didn't work at all. It just didn't fix the issue i had. Just not blocking fixed it.

Related