dspaude wrote on Tuesday, July 24, 2007:
Hello,
Why would using configUSE_PREEMPTION #defined as 0 cause a prefetch abort even before FreeRTOS’s scheduler is started (which means that FreeRTOS isn’t even actively being used)? I get a prefetch abort even when setting something simple like a global variable to an integer (like 0). However, if I #define configUSE_PREEMPTION as 1 then FreeRTOS runs okay.
Any ideas?
Darrik
davedoors wrote on Tuesday, July 24, 2007:
Very odd. Is it possible that in interrupt that makes use of a FreeRTOS API function is being executed prior to the scheduler being started?
Dave.
dspaude wrote on Tuesday, July 24, 2007:
I would think that if this were true then the preempted version would have the same problem. The same identical code with just the configUSE_PREEMPTION #define set differently causes dramatically different results (preemption works, cooperative aborts).
Have any of the FreeRTOS examples been tried in cooperative mode?
rtel wrote on Wednesday, July 25, 2007:
>Have any of the FreeRTOS examples been tried in cooperative mode?
Yes definitely, although I may occasionally forget to re-test the cooperative version when making changes. Some of the examples may result in errors being reported when run in cooperative mode (i.e. the ‘check’ task reporting that one particular test task has not executed as expected) but not a crash.
Which port are you using?
Regards.
dspaude wrote on Wednesday, July 25, 2007:
I am using the GCC SAM7S port as the base, but of course with many changes for my application. I may try a debugger to see if there is something else that happens that I am not seeing, but the last time I used the debugger it literally indicated that the failure was on a variable assignment before the OS even started (and no interrupts should have happened before that point in the code).
dspaude wrote on Thursday, July 26, 2007:
The main difference I see in the FreeRTOS code between configUSE_PREEMPTION == 0 and configUSE_PREEMPTION == 1 is that configUSE_PREEMPTION == 0 uses attribute “IRQ” for the tick handler while configUSE_PREEMPTION == 1 uses attribute “naked”. I recall seeing some note that attribute “IRQ” for GCC didn’t work very well (for some “current version of GCC”–whatever version that was). Could this be related?
davedoors wrote on Thursday, July 26, 2007:
If you are using a V4.n.n version of GCC and you are compiling it to ARM mode (as its an IRQ) you should be ok, but you could try writing your own entry code to be sure. To do this you would simply have to declare the function naked and call the save/restore context macros as per the preemptive example. This would be somewhat wasteful in a real application but would make a good test.
I think I recall you saying the crash happened before the scheduler was started though? Which demo are you basing your test on?
dspaude wrote on Thursday, September 27, 2007:
I finally got back to trying to resolve this problem. I modified the vNonPreemptiveTick() function prototype in portISR.c to use the "naked" attribute instead of "IRQ" and that allowed the code to power up. There are other issues related to this change, but at least it powered up. Before this change it would just crash when switching to any task except the IDLE task. However, if the IDLE task is the only one, then the system still crashes. Again, this is based on the SAM7S port and using GCC 4.2.1 (YAGARTO).