search

beckus / qemu_stm32

QEMU with an STM32 microcontroller implementation
http://beckus.github.io/qemu_stm32/
Other
524 stars 144 forks source link

uart rx overruns #7

Open zevv opened 9 years ago

zevv commented 9 years ago

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:

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

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 commented 9 years ago

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 <notifications@github.com> 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:

zevv commented 9 years ago

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 commented 9 years ago

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

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 commented 5 years ago

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 https://github.com/beckus/qemu_stm32/commit/f28e8a58bc7964ef9ae206dd64462614de6a540f#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 commented 5 years ago

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 commented 5 years ago

We may have figured it out the root cause of this: https://github.com/beckus/qemu_stm32/pull/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 commented 5 years ago

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.