uart rx overruns

[zevv]

Hi Andre,

Thanks a lot for adding stm32 support to qemu!

I'm having some troubles with the USART though, maybe you can help me out. If data is received too fast from the host to the stm32 uart, I get a sort of overrun on the emulated receive path, both when polling USART_SR_RXNE and when using interrupts.

Let me describe the symptom with an example:

• qemu runs with -nographic option, serial port is connected to stdio
• I paste 4 characters into my xterm so they are sent into the emulated uart, for example "abcd"
• USART_SR_RXNE fires once, I receive the first byte "a" in the ARM program in USART DR.

after this, nothing happens, the remaining 3 chars do not arrive. But then:

• I press space (or any other key) once. Now RXNE fires again, and I receive the second byte "b"
• I press space (or any other key) once. Now RXNE fires again, and I receive the third byte "c"

etc.

So it seems that the received bytes are queued somewhere within qemu, but the stm32 is not informed of waiting bytes by the RXNE flag.

Am I doing something wrong with wrong assumptions, or could this be a bug in the stm32 usart code?

Thanks!

[beckus]

Hello,I am glad that you find this project useful.
I am not aware of any bugs with the UART (or with QEMUs character device framework), but it is very possible that there are.
Have you tried other means of sending characters to the UART?  I usually test by using telnet (using the QEMU command line option "-serial tcp::7777,server" and then connect using the telnet client in another window).  The best way I know of to troubleshoot this is to run QEMU in a debugger and trace through the STM32 UART code to see what is happening.  I would offer to do some testing on my side, but I am very tied up right now with a project.
I don't think this is relevant to your problem, but note that there is a QEMU config flag "--extra-cflags=-DSTM32_UART_ENABLE_OVERRUN" which is explained in the README.  All this does is overwrites characters when you send multiple characters at once.
Thanks,Andre

 On Thursday, July 9, 2015 2:06 PM, Ico Doornekamp <[email protected]> wrote:

Hi Andre,Thanks a lot for adding stm32 support to qemu!I'm having some troubles with the USART though, maybe you can help me out. If data is received too fast from the host to the stm32 uart, I get a sort of overrun on the emulated receive path, both when polling USART_SR_RXNE and when using interrupts. Let me describe the symptom with an example:

• qemu runs with -nographic option, serial port is connected to stdio
• I paste 4 characters into my xterm so they are sent into the emulated uart, for example "abcd"
• USART_SR_RXNE fires once, I receive the first byte "a" in the ARM program in USART DR.
  after this, nothing happens, the remaining 3 chars do not arrive. But then:
• I press space (or any other key) once. Now RXNE fires again, and I receive the second byte "b"
• I press space (or any other key) once. Now RXNE fires again, and I receive the third byte "c"
  etc.So it seems that the received bytes are queued somewhere within qemu, but the stm32 is not informed of waiting bytes by the RXNE flag.Am I doing something wrong with wrong assumptions, or could this be a bug in the stm32 usart code?Thanks!—
  Reply to this email directly or view it on GitHub.

[zevv]

• On 2015-07-10 04:48:33 +0200, Andre Beckus wrote:

Have you tried other means of sending characters to the UART?

I just did, and indeed the problem does not occur when using telnet.
That solves the problem for me.

The best way I know of to troubleshoot this is to run QEMU in a
debugger and trace through the STM32 UART code to see what is
happening. 

I already stated with some basic printf-style debugging yesterday before
I contacted you, but could not find anything wrong in the stm32 part of
the qemu code. Indeed the problem seems to lie elsewhere.

Thanks for helping me out,

Ico

:wq
^X^Cy^K^X^C^C^C^C

[beckus]

Great.  I'm glad it worked.  Unfortunately, there are a lot of quirks like that...

• Andre

  On Friday, July 10, 2015 2:11 AM, Ico Doornekamp [email protected] wrote:

  • On 2015-07-10 04:48:33 +0200, Andre Beckus wrote:

Have you tried other means of sending characters to the UART?

I just did, and indeed the problem does not occur when using telnet.
That solves the problem for me.

The best way I know of to troubleshoot this is to run QEMU in a
debugger and trace through the STM32 UART code to see what is
happening. 

I already stated with some basic printf-style debugging yesterday before
I contacted you, but could not find anything wrong in the stm32 part of
the qemu code. Indeed the problem seems to lie elsewhere.

Thanks for helping me out,

Ico

:wq
^X^Cy^K^X^C^C^C^C
—
Reply to this email directly or view it on GitHub.

[kousu]

Hi! I think I ran into this today, though with tx instead of rx. I've got some chopstx-based firmware I am debugging with your project (thanks!) but I wired up the UART for I/O and while at first it seemed stable, the more prints I added the likelier it was to see hangs. It's inconsistent, and I haven't pinned it down for sure yet -- but if I don't solve it soon I plan to make a minimal test case project -- but it seems to be that when output is sent too fast to the UART it drops.

I ran qemu-system-arm -serial null -serial tcp::7878,server & nc localhost 7878 and sniffed the communication with Wireshark, and qemu simply seems to be dropping some data. And then once some data is dropped, my programs choke up because they don't receive the amount of data they expect.

I ran with qemu-system-arm -S and connected gdb with gdb -ex "target remote :1234" and single-stepped; stepping slowly would fix the problem. Stepping quickly would still show it, but to a reduced degree.

I think this is probably related to f28e8a5#diff-f44b64de825a4c23e77c796039da3773. UART2 and UART3 need to be enabled through those removed registers, as can be seen in libopencm3's implementation:

https://github.com/libopencm3/libopencm3/blob/0fd4f74ee301af5de4e9b036f391bf17c5a52f02/include/libopencm3/stm32/f1/rcc.h#L405-406

I haven't tried running qemu itself in gdb, but I have started adding DPRINTFs here and there to it.

I might have more insights later this week! I'm going to keep taking a look at this. qemu_stm32 is pretty important for making my project reliable, so I'm motivated to help it get better.

[beckus]

Hello, sorry for the delay. I am not sure exactly what is happening, and am a bit tied up with other projects to look into it deeply right now. But, if you do get some minimal test case project, let me know as this would definitely help with troubleshooting... Thank you

[kousu]

We may have figured it out the root cause of this: #30
I'd really appreciate some feedback and insight though. This patch works for us, but it seems a little bit ad-hoc still.

[kousu]

After trying to move some of that code around a bit, I don't think that's the root-root cause, but it's somehow related. I am hoping it helps someone get some insight.