SAM7 System Interrupt

adecar wrote on Thursday, September 24, 2009:


I have a bit of a request for FreeRTOS.  I’m currently working on a project which requires the use of 3 UARTS, the SAM7 has 3 uarts on board, 2 normal and 1 debug uart which has reduced functionality, but for our particular application we do not require anything other than the standard 8-N-1 settings on the port.

I have my own UART abstraction layer which we have used on the SAM7 before which just requires me to add a low level driver for the uart, however, there’s a bit of an issue with the sam7 port out of the box.

The system interrupt vector which you install assumes that the only time it will ever be called is because the system tick has "gone off", however, the DBGU on the SAM7 shares the system interrupt with the PIT timer.

Now, modifying the port code is obviously trivial, but what I like to do when you release a new version of FreeRTOS is to just drop it into my project and replace the existing freertos distribution, rebuild and bobs you uncle.  However, if I make changes to the port file then they will obviously be lost.

So, what I’m asking (proposing) is would it be possible to provide a define which allows a user routine (or macro) to be called if the PIT was not the source of the interrupt, so for example, the freertos system tick could become:

    void vPreemptiveTick( void )
    /* Save the context of the current task. */
    #if defined( configUSE_SAM7_SYSTEM_DISPATCHER )
    /* Increment the tick count - this may wake a task. */
    /* Find the highest priority task that is ready to run. */
    /* End the interrupt in the AIC. */
    #if defined( configUSE_SAM7_SYSTEM_DISPATCHER )

If you don’t use the option, then the code will compile as is, but if you do use the option, you have to supply the sam7_system_irq_dispacher routine which the user supplies to locate the source and then handle the interrupt.

One other thing which has been like this for a while, the sam7x256 header file which you use is out of date, and the function which installs the system interrupt has an incorrect syntax when used against the current atmel library functions, it’s missing a first parameter which should be a pointer the AIC base address.  This isn’t a problem unless you change the header to a newer one (i.e if you think, oh I’m not using a SAM7X so I’ll change the include to SAM7S) and then wonder why you keep ending up in data abort.



rtel wrote on Friday, September 25, 2009:

I would be grateful if you would add this to the feature request tracker (under SourceForge).

Also, how did you get the code to be displayed as formatted code?  I tried it the other day but it just added tags into the text.


mikehitekp wrote on Tuesday, September 29, 2009:

Could I also remind you of this thread
which seems to cover the same area


adecar wrote on Tuesday, September 29, 2009:

The method in that thread is a bit "hacky". you’d either have to cut and paste code from vTaskStartScheduler to get it to install your own vector, or you’d have to let it install it’s own vector and then in one of the tasks that start, disable interrupts and then install your own vector and then let yourself take over that interrupt, which isn’t a very clean thing to do in my eyes.

Providing a compile time solution into the port is a much nicer way of dealing with this.


adecar wrote on Tuesday, September 29, 2009:

Oh, and I’m not sure what I did with the tags, I clicked the "101010" button and then just pasted my code from textmate directly into the block it created and it pretty much came out how I expected.