Hi,

FreeRTOS 4.0.4 uses on AT91SAM7X256 the Periodic Interval Timer (PIT) which triggers the system interrupt (sys_irq). But sys_irq is triggered by some other peripherals as well like Debug Unit (DBGU), or Watchdog Timer (WDT). So 'vTaskIncrementTick' is allowed to be called only if the interrupt is triggered by the PIT. If the interrupt is triggered by another peripheral a hook function should be called. As I use the DBGU I had to modify the function 'void vPreemptiveTick( void )' as follows

void vPreemptiveTick( void ) __attribute__((naked));
void vPreemptiveTick( void )
{
/* Save the context of the current task. */
portSAVE_CONTEXT();

/* Increment the tick count - this may wake a task. */
if ((AT91C_BASE_PITC->PITC_PISR & AT91C_PITC_PITS) > 0) /* N E W */
vTaskIncrementTick();

serveDBGUFunc(); /* N E W */

/* Find the highest priority task that is ready to run. */
vTaskSwitchContext();

/* Clear PITS and end the interrupt in the AIC. */
AT91C_BASE_AIC->AIC_EOICR = AT91C_BASE_PITC->PITC_PIVR;

portRESTORE_CONTEXT();
}

Perhaps you may want to adopt these modifications to FreeRTOS.

Hardware details can be found in Atmel's manual 'AT91 ARM Thumb-based Microcontrollers AT91SAM7X256/AT91SAMX128 Preliminary', Version '6120D-ATARM-02-Feb-06' (document name 'doc6120.pdf'), fig. 10-1 'System Controller Block Diagram (http://www.atmel.com/dyn/resources/prod_documents/6120s.pdf).

Regards

Thomas

This is one of the benefits of open source!

Ways of using DBGU with the PIT was discussed here recently, but I cannot provide a reference as the search facility seems to have stopped working on the forum (anybody else seeing this?).

The tick interrupt could be generated off a different timer if that was preferable to you.

In your solution you are effectively polling the DBGU, is this correct? If you want the DBGU to generate interrupts itself then you have to check the source of the interrupt from within the ISR so as not to increment the tick on DBGU interrupts.

Sharing interrupts like this on a peripheral such as the PIT is a pain as by its nature you want it to be frequent and fast. I think the way people do this is to check the source of the interrupt from within the ISR, and then service whichever is found to be the cause.

Your solution looks fine provided the debug interface does not itself cause any interrupts.

Regards.

Hi, Richard,

why shouldn't the DBGU generate interrupts in my case?
The DBGU does generate interrupts for me. But there is no function call to 'serveDBGUFunc' because this function is declared as inline in my file 'dbguISR.h' which is included in 'portISR.c'. So there is no function call overhead.

Here is the definition of the function:

void serveDBGUFunc(void);
extern inline void serveDBGUFunc(void)
{
unsigned AT91C_DBGU_CSR_Val;

AT91C_DBGU_CSR_Val = *AT91C_DBGU_CSR;
if (((AT91C_DBGU_CSR_Val & AT91C_US_TXRDY)!=0))
{
...
}
if ((AT91C_DBGU_CSR_Val & AT91C_US_RXRDY)!=0)
{
...
}
...
}

I don't like to modify the original FreeRTOS code because I must repeat my modifications with every new FreeRTOS version. I would prefer a hook function in the function 'vPreemptiveTick' or another smart solution which doesn't require me to touch the original FreeRTOS code.
Regards
Thomas

Hi,
no, I don't poll the DBGU. The DBGU generates interrupts. I do check which peripheral generate the interrupt. That is why I inserted the line 'if ((AT91C_BASE_PITC->PITC_PISR & AT91C_PITC_PITS) > 0)'.
For further details see my posting following 'RE: FreeRTOS 4.0.4, AT91SAM7X256, Timertick' from richardbarry at 2006-07-19 05:40.
Regards
Thomas