[RTEMS Project] #3310: zynq_uart_write_polled could produce a blocking scenario

RTEMS trac trac at rtems.org
Wed Feb 21 10:10:54 UTC 2018


#3310: zynq_uart_write_polled could produce a blocking scenario
--------------------------+--------------------------
  Reporter:  fdpousa      |      Owner:  (none)
      Type:  enhancement  |     Status:  new
  Priority:  normal       |  Milestone:
 Component:  bsps         |    Version:  5
  Severity:  normal       |   Keywords:  zynq arm bsp
Blocked By:               |   Blocking:
--------------------------+--------------------------
 The actual code for the zynq_uart_write_polled has a while loop inside.
 What could happen if a hw fault occurs? If TX buffer is always full, lower
 priority tasks may remain in a blocked state. The objective is to use the
 UART communication directly by RS232/RS422 protocol without any console.

 Why is this function codified different than zynq_uart_read_polled()? With
 the  zynq_uart_read_polled codification the blocking risks disappear if hw
 fails and a byte is never put in RX Buffer. I suggest to apply the same if
 struct to zynq_uart_write_polled.

--
Ticket URL: <http://devel.rtems.org/ticket/3310>
RTEMS Project <http://www.rtems.org/>
RTEMS Project


More information about the bugs mailing list