I compiled the original project file in Ubuntu using arm-none-eabi-gcc to make and generated RTOSDemo.axf and RTOSDemo.bin, but when I ran the.axf and.bin files using qemu, there was only a black screen on the virtual screen with no output, I don’t know why.
Have you tried running it with -nographic -serial stdio -semihosting -semihosting-config enable=on,target=native options?
Also, remove the -s -S to run without waiting for the debugger.
Are you talking about this demo? If yes, the following page provides instructions about how to run this - FreeRTOS demo for the QEMU LM3S6965 model port - FreeRTOS™.
I can’t use command -serial stdio and - semihosting, what’s more, when I just use -nographic, there is still no output, just a line of “Timer Period is zero, disabling”.
The LM3S6965 demo for Eclipse and QEMU is normal. However, when I try to use the LM3S811 demo in QEMU, it can run but with a black screen on the emulated OLED.
Are you talking about this demo then? If yes, I am not sure it was tested on QEMU - Luminary Micro LM3S811 ARM Cortex-M3 Port for the Keil RVDS, IAR and GCC development tools - FreeRTOS™.
Can you try to use GDB and see if you are able to reach main?
I am trying to emulate a board which has a OLED display, but can't see anything. Can you tell me if there is something important I am not considering? this article maybe has the same question? However the person use IAR to compile, not GCC.
Lets try to narrow down the problem. Please update your main function to the following:
int main( void )
{
/* Print or display a message. */
while( 1 );
return 0;
}
Then see if you are able to get the message. This would help us narrow down if the issue is with FreeRTOS or QEMU setup itself.
I try to use arm-none-eabi-gdb, then the feedback is like this picture
I don’t know why gdb stop in the startup.c, and after continue there’s no more output.
Did you put a breakpoint in main before continuing using command b main? Is yes, this issue is related to your QEMU setup and you are likely to get better response on QEMU support forum.
I just add “-g” in the makefile and don’t set any other cutoff points.
Through the above article, I found the question: the level of compile. When I change the level from -O2 to -O1, everything becomes normal.
Does it mean that it works when you change optimization to O1?
From the result, it seems like this. But I don’t know why when optimization level is O2 the .axf is abnormal.
If you want to debug your application then better use ‘-O0’ or at least ‘-Og’.
If your application doesn’t run properly when using (higher) optimization the reason is almost always buggy source code.
Buggy means ‘undefined behaviour’ or not properly using ‘volatile’ where required …