stm32l4 - uart communication cannot process continuous data fast enough

[niewim19]

stm32l4 UART communication cannot process continuous block of data fast enough. This bug blocks history usage in psh and forces STM32L4Runner in phoenix-rtos-tests to use strange looking 30ms delay after each character (cutting baudrate from 115200 to 333)

Everything is fine when a real human types communicates with target (e.g with picocom) but using some script that sends data without human-related delays (times between character strikes) breaks the communication and target misses some characters (as they would never arrive via UART)

Replication:

• Using picocom:

  • connect to board via UART (baudrate 115200)
  • check the connection (type something)
  • copy and paste something into commandline (some long message e.g whole latin alphabet as one message)
  • observe the response
  • if you are inside of psh you may observe only some letters sent to psh / some letters doubled / some letters missing
  • if you paste some short command it has a non-zero chance of being sent good

• using python script with pyserial module used

  • open port
  • send any string
  • observe the response on opened picocom (with --nolock option to not block the port)
  • as picocom is the only reader of port it will observe simmilar behaviour as described above: missing letters, doubled letters etc.

Also because of this the functionality of psh history is broken as pressing up key on keyboard (in psh) prints letter A which means that only half of the whole message was processed correctly

[anglov]

@damianloew As DMA UART was merged please do the following steps:

1. Enable DMA on default console UART via board_config.h
2. Run tests (CI should do relevant test and all of them should pass)
3. Remove workaround in phoenix-rtos-tests https://github.com/phoenix-rtos/phoenix-rtos-tests/blob/6cd0ac76475196a268db2fe95b6f735c97e6b2b2/trunner/target/armv7m4.py#L104C1-L108C1
4. Run tests.

If everything will pass, then this issue can be closed.