The print task is the only task permitted to access the LCD - thus
ensuring mutual exclusion and consistent access to the resource. Other
tasks do not access the LCD directly, but instead send the text they
wish to display to the print task. The print task spends most of its
time blocked - only waking when a message is queued for display.
but actually, if I compile using make and running using qemu-system-arm -M lm3s811evb -kernel gcc/RTOSDemo.bin I can only see that black screen.
Why? Is there something I am not considering? It should work out of the box, since it’s also writen in the official doc that I mentioned. So why I see black screen?
Probably there is something I am not considering because I am a newbie
I think this is more of a tools question than a FreeRTOS question. Nonetheless I just tried building an unmodified version of this project using the IAR tools and executed your QEMU command line. Without doing anything else I see:
The menu has ssd0303 selected as per your screenshot. Using QEMU version 6.2.0.
I recommend first stepping through the project in the debugger to see if you can see why it’s not working - it’s an old demo so there may be things like limited assert messages (or no assert messages) to let you know visually. If you still can’t see what is wrong, diff the project with the IAR and Keil projects to see what the differences are.
my curiosity asks: what if it isn’t an old demo? what is the new way of doing it?
I don’t get what I should do with gdb… how to investigate asserts?
Also, if I compile doing DEBUG=1 make (which basically does a -g I guess) and then I start qemu with -s -S and then start gdb via arm-none-eabi-gdb RTOSDemo.axf -ex 'target remote :1234' I am just in FaultISR, so the while(1)… so basically no instruction is executed… it’s only the while(1) of the FaultISR that it’s executed… but if I compile without DEBUG=1 and do the same, in debug I arrive at ResetISR, and only AFTER I do continue I reach FaultISR, I don’t know why lol…
anyway, how to investigate this fail? I am a newbie but I am curious and I want to learn
I tried with -O1 and it works. It does not work for O0,O2,O3… is it kinda random? Should I avoid using gcc in this project since it gives so strange behaviors and instead use just Keil? Or should I just stick with -O1 ?
If I were you, I would stick with -O1 for the time being to be able to continue development and report the problem to the gcc support forum.
If I were myself () and had a little time, I would subsequently move every single file to another opti level until I find the offending file, then do the same for each function in that file until I know exactly where the optimizer causes the problem. It may not even be the compiler but sloppily written code.
But that is just me because I like to do those kinds of things.
EDIT: It just so happens that I am currently working on a fairly big project in which no attempts ever have been made since inception to compile with a different than default optimization. When I played with that code a little bit, using different optimizations, building as well as running would break in a multitude of ways, exposing a few inherent severe problems in the existing code base that had just coincidentally escaped detection. Testing under different optimization levels is a grossly underrated element in the test matrix.
If it works with O1 but not O0 then it could be a memory issue as O1 will use less memory. Is stack overflow detection on? Would you know if stack overflow hook function had been called - it might be just sitting in a while( 1 ) loop inside the stack overflow hook or an assert. You need to learn how to use the debugger before learning how to use the RTOS.
thanks for answer, but when I started to write my own code (creating a new task), I get compile errors:
arm-none-eabi-ld: gcc/RTOSDemo.axf section `.bss' will not fit in region `SRAM'
arm-none-eabi-ld: section .ARM.exidx LMA [0000ba04,0000ba0b] overlaps section .data LMA [0000ba04,0000ba07]
arm-none-eabi-ld: section .data._impure_ptr LMA [0000ba08,0000ba0b] overlaps section .ARM.exidx LMA [0000ba04,0000ba0b]
arm-none-eabi-ld: region `SRAM' overflowed by 1496 bytes
arm-none-eabi-ld: /usr/lib/gcc/arm-none-eabi/13.1.0/../../../../arm-none-eabi/lib/thumb/nofp/libc.a(libc_a-closer.o): in function `_close_r':
/builddir/build/BUILD/newlib-4.3.0.20230120/build-newlib/arm-none-eabi/thumb/nofp/newlib/../../../../../newlib/libc/reent/closer.c:47: undefined reference to `_close'
arm-none-eabi-ld: /usr/lib/gcc/arm-none-eabi/13.1.0/../../../../arm-none-eabi/lib/thumb/nofp/libc.a(libc_a-lseekr.o): in function `_lseek_r':
/builddir/build/BUILD/newlib-4.3.0.20230120/build-newlib/arm-none-eabi/thumb/nofp/newlib/../../../../../newlib/libc/reent/lseekr.c:49: undefined reference to `_lseek'
arm-none-eabi-ld: /usr/lib/gcc/arm-none-eabi/13.1.0/../../../../arm-none-eabi/lib/thumb/nofp/libc.a(libc_a-readr.o): in function `_read_r':
/builddir/build/BUILD/newlib-4.3.0.20230120/build-newlib/arm-none-eabi/thumb/nofp/newlib/../../../../../newlib/libc/reent/readr.c:49: undefined reference to `_read'
arm-none-eabi-ld: /usr/lib/gcc/arm-none-eabi/13.1.0/../../../../arm-none-eabi/lib/thumb/nofp/libc.a(libc_a-writer.o): in function `_write_r':
/builddir/build/BUILD/newlib-4.3.0.20230120/build-newlib/arm-none-eabi/thumb/nofp/newlib/../../../../../newlib/libc/reent/writer.c:49: undefined reference to `_write'
arm-none-eabi-ld: /usr/lib/gcc/arm-none-eabi/13.1.0/../../../../arm-none-eabi/lib/thumb/nofp/libc.a(libc_a-sbrkr.o): in function `_sbrk_r':
/builddir/build/BUILD/newlib-4.3.0.20230120/build-newlib/arm-none-eabi/thumb/nofp/newlib/../../../../../newlib/libc/reent/sbrkr.c:51: undefined reference to `_sbrk'
arm-none-eabi-ld: /usr/lib/gcc/arm-none-eabi/13.1.0/../../../../arm-none-eabi/lib/thumb/nofp/libc.a(libc_a-abort.o): in function `abort':
/builddir/build/BUILD/newlib-4.3.0.20230120/build-newlib/arm-none-eabi/thumb/nofp/newlib/../../../../../newlib/libc/stdlib/abort.c:59: undefined reference to `_exit'
arm-none-eabi-ld: /usr/lib/gcc/arm-none-eabi/13.1.0/../../../../arm-none-eabi/lib/thumb/nofp/libc.a(libc_a-fstatr.o): in function `_fstat_r':
/builddir/build/BUILD/newlib-4.3.0.20230120/build-newlib/arm-none-eabi/thumb/nofp/newlib/../../../../../newlib/libc/reent/fstatr.c:55: undefined reference to `_fstat'
arm-none-eabi-ld: /usr/lib/gcc/arm-none-eabi/13.1.0/../../../../arm-none-eabi/lib/thumb/nofp/libc.a(libc_a-isattyr.o): in function `_isatty_r':
/builddir/build/BUILD/newlib-4.3.0.20230120/build-newlib/arm-none-eabi/thumb/nofp/newlib/../../../../../newlib/libc/reent/isattyr.c:52: undefined reference to `_isatty'
arm-none-eabi-ld: /usr/lib/gcc/arm-none-eabi/13.1.0/../../../../arm-none-eabi/lib/thumb/nofp/libc.a(libc_a-signalr.o): in function `_kill_r':
/builddir/build/BUILD/newlib-4.3.0.20230120/build-newlib/arm-none-eabi/thumb/nofp/newlib/../../../../../newlib/libc/reent/signalr.c:53: undefined reference to `_kill'
arm-none-eabi-ld: /usr/lib/gcc/arm-none-eabi/13.1.0/../../../../arm-none-eabi/lib/thumb/nofp/libc.a(libc_a-signalr.o): in function `_getpid_r':
/builddir/build/BUILD/newlib-4.3.0.20230120/build-newlib/arm-none-eabi/thumb/nofp/newlib/../../../../../newlib/libc/reent/signalr.c:83: undefined reference to `_getpid'
make: *** [makedefs:191: gcc/RTOSDemo.axf] Error 1
) and had a little time, I would subsequently move every single file to another opti level until I find the offending file, then do the same for each function in that file until I know exactly where the optimizer causes the problem. It may not even be the compiler but sloppily written code.