search

beckus / qemu_stm32

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

slow event (e.g. UART) timing handling broken #45

Closed jmfriedt closed 1 year ago

jmfriedt commented 1 year ago

I am using this version of qemu for teaching FreeRTOS including inconsistent access to a shared resource in a multitasking environment. Using the example at https://github.com/jmfriedt/tp_freertos/tree/master/3mutex I show how a slow peripheral such as a UART leads to unpredictable result if accessing the resource is not protected with a mutex. On both the hardware microcontroller and older versions of this qemu, the result should be 

LED Off
22222222222222222221111111111111111222222222222222222222211111111111111111111122
111111
22222222222222222221111111111111111111112222222222222222222221111111111111111111111222

2222222222222222222222222222222222222222222
1111111111111111111111111111111111111111111
1111111111111111111222222222222222222222111111111111111111111222222222222222222222111
2
1111111111111111111111111111111111111111111
2222222222222222222222222222222222222222222111111111111111111111
111111111111111111122222222222222222222111
22222222222222221111111111111111111112222222
1111111111111111111111
2222222222222222222222111111111111111111112222222222222222222221111111111111111111111
1
 9 2222222222222222222222222222222222222222222

but now the result is

LED Off
2222222222222222222222222222222222222222222
1111111111111111111111111111111111111111111
2222222222222222222222222222222222222222222
1111111111111111111111111111111111111111111
2222222222222222222222222222222222222222222
1111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111
2222222222222222222222222222222222222222222
1111111111111111111111111111111111111111111
2222222222222222222222222222222222222222222
1111111111111111111111111111111111111111111
2222222222222222222222222222222222222222222
1111111111111111111111111111111111111111111
2222222222222222222222222222222222222222222
2222222222222222222222222222222222222222222

meaning that the long delay introduced by a UART communication leading to the FreeRTOS scheduler to switch task is no longer detected by the emulator. I git bisected the problem to commit 4ac96ba679496140b090b3ef18f429e964a941e7 since 985241040ad0e3a67976d8abdef3df7371140235 is still good. This commit is entitled "fix slow event loop" and touches hw/char/stm32_uart.c: I believe the correction brought with this commit is incorrect and breaks the valid behaviour of the emulator.

Edit: I realize the change in behaviour is introduced by #define STM32_UART_NO_BAUD_DELAY: commenting this options resumes to the original behaviour. I wonder what is the rationale for breaking proper peripheral timing analysis which seems to me as one of the highlights of qemu.

beckus commented 1 year ago

@jmfriedt I am sorry that this commit caused an issue and a headache. Thank you for the analysis. I don't recall the exact rationale for the STM32_UART_NO_BAUD_DELAY macro, but I believe it was something I used as a temporary measure for testing purposes. I can't think of a good reason to break the peripheral timing by default. I am guessing that I uncommented it while debugging an issue and did not intend to commit it into the released code (lazy programming as I should have just enabled the macro from the command line and not modified the code).

So, I think #define STM32_UART_NO_BAUD_DELAY should be commented out. I will plan on doing this in the near future...