we are trying to compile the Project FreeRTOS 4.0.4 (we picked out the uP
Rowley Demo, originally it was for LCP2124, but we’ve changed everything to
run it on the LPC2106) on a Philips LPC2106-Evalutation Board from Olimex
with the CrossStudio 1.6 from Rowley and I have some trouble with it:
(almost) everytime i use an interruptrequest not given in the demo (e.g. a
button on EINT2-Pin or a additional Timer-Interrupt) my program crash by
beeing hold in one of the default abort handlers (time data-, prefetch-, or
undef abort).
Which startup code are you using? The startup code must setup stacks for the IRQ and System modes. Could it be that you are running out of stack in the IRQ?
How are your interrupts being called. Do you vector directly to the interrupt with interrupts remaining disabled, or do you have some intermediary code? You should be vectoring directly.
Is the interrupt that is causing the problem attempting to perform a context switch, or is it just a plain interrupt that always returns to the task that it interrupted?
From your question it sounds like the examples interrupt routines given in the FreeRTOS download are working correctly (i.e. the sample UART ISR for the LPC2106 GCC port). Is this correct?
Yes it is correct, that the sample ISRs are working fine! But if i extend one of the examples with another ISR, it crashes.
I’ve used both the FreeRTOS-uP-Rowley-demo and Rowleys-sample startup skript for Philips LPC210X (both are called “Philips_LPC210X_Startup.s”), but it always results in the same error.
I’ve compared the two scripts and found out that only the bootloader’s got a different checksumm (if Preprocessiordefinition VECTORED_IRQ_INTERRUPTS is set like in my IDE, Checkum is 0xB9205F88 (Rowley-startup) or 0xB9205F84 (FreeRTOS-startup))?!
The Interrupts are called vector directly like it is given on the FreeRTOS-Homepage and I tried it with or without a context-switch.
What now happens is:
the FreeRTOS-Systemticker (Timer0) works fine and all Threads are started normally. When my timer1-IRQ occurs (like described above) I could debug that the uC jumps correct into the ISR (can watch it by debugging and setting a breakpoint on it) and let the LED toggle. But this happens only about 2…5 times, then an error handler occurs (mostly undef-handler).
This also happens if the program jumps in to the ISR by pressing the Button on EINT2.
I could imagine that it has something to do with nested interrupts, but I’ve tried everything that comes in my mind (disable all IRQs when entering ISR, context switching etc.) and nothing worked.
Have you altered portENTER_SWITCHING_ISR() at all? The macro must end with a bracket {. This ensures the correct stack frame is setup before your variable lSwitchRequired is defined.
Try making lSwitchRequired stack, then setting it to 1 on each interrupt. This might highlight where the problem is.