Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Interrupts being disabled for extended period

Posted by Janaka on November 1, 2006
Hello everyone,
I am currently running FreeRTOS on a Atmel AT91SAM7S256.

We use FreeRTOS Queues and Semaphores for inter-thread communications as well as ISR communications.
The problem I am having is, during heavy application loading, I miss TWI interrupts; hence overflows. Further investigations point at xQueueReceive, xQueueSend causing this. My hypothesis is that because queue activity (hence semaphore activity) causes the interrupts to be disabled for 240us, this causes it to miss the TWI RxRdy interrupt; eventually causing the overflow of the hardware.

The Oscilloscope trace of the TWI overflow and associated signals has been captured and is viewable here:
http://www.flickr.com/photo_zoom.gne?id=285266143&size=o

To capture this, I toggled IO lines on different events.
The signal descriptions are as follows (listed down the right hand edge in the image):
LabelSignal name
---------------------------------------------------------------------------------------------------------------------------------
A2 TWI Clock
A1 TWI Data
7 Idle Activity task (Every time around the loop)
6 EnterCritical - Exit Critical timings (Note that I am forcing this pin low at portRESTORE_CONTEXT)
5 USB interrupt time (Logic 1 at start of USB interrupt, 0 at end of interrupt)
4 TWI comms Interrupt (Logic 1 at start of TWI interrupt, 0 at end of interrupt)
3 NA
2 QueueRecive activity (xQueueReceive but clearing this before any possible context switching)
1 QueueSend activity (xQueueSend but clearing this before any possible context switching)
0 RTOS Interrupt ( vTaskIncrementTick, vTaskSwitchContext )

As you can seen the periodic TWI_RxRdy interrupt occurs approx every 200us and CANNOT be invoked while queues are being manipulated. Hence the next TWI interrupt after Interrupts are re-enabled is for the TWI overflow.

===============
Questions:
===============

1. Is it possible to ONLY disable the PIT timer interrupt while queues are being manipulated & context switching ?
2. Is there any variations of the queue implementation (even commercial ones) , that do not disable the interrupts, that I could use in FreeRTOS ?
3. Is there any other solutions to this problem ?


===============
Misc information.
===============
The application that uses the following:
- USB (HID class, custom pipes and custom host app)
- TWI
- Serial Comms
- DBGU Comms
- SPI
- Timer Interrupt
+ 5 threads at different priority levels (including idle priority)

RE: Interrupts being disabled for extended pe

Posted by Neil Bradley on November 1, 2006
I'm using the same CPU as well - congrats!

Anyway, what immediately springs to mind - what about turning the TWI into a FIQ and setting FIQs as higher priorities? Then just disabling IRQs?

RE: Interrupts being disabled for extended pe

Posted by Janaka on November 1, 2006
Congrats to you as well! :)

If I hack the FreeRTOS code I probably could get the FIQ for TWI working. The current implementation uses "__disable_interrupt()" library function. That disables IRQ and FIRQ on the CPSR register on the ARM7TDMI. I think that Idea has merit if I decide to hack FreeRTOS. Worst thing is AT91SAM7S256 does not allow DMA access to TWI or USB either! :{

RE: Interrupts being disabled for extended pe

Posted by Jokke on November 1, 2006
In my port, which is Keil, the disable interrupt is a short assembler macro, where the bits to set in the control register are specified. There it would be easy to leave the FIRQ enabled through OS operations.

240 us sounds like a long time for irq to be disabled. Did you try to measure that (e g some debug pin set/clear when enterring and leaving disabled state)? I guess you run 48MHz?

RE: Interrupts being disabled for extended period

Posted by Nobody/Anonymous on November 1, 2006

> We use FreeRTOS Queues and Semaphores for inter-thread communications as well
> as ISR communications.
> The problem I am having is, during heavy application loading, I miss TWI interrupts;
> hence overflows. Further investigations point at xQueueReceive, xQueueSend
> causing this. My hypothesis is that because queue activity (hence semaphore
> activity) causes the interrupts to be disabled for 240us, this causes it to
> miss the TWI RxRdy interrupt; eventually causing the overflow of the hardware.

240us seems a long time. Are you sending a lot of data, or making lots of calls to send small amounts of data? There maybe a more efficient alternative.

Also, you may be able to use scheduler locking instead of disabling interrupts. When the scheduler is locked interrupts remain enabled, but context switches cannot occur.



<snip>

> 1. Is it possible to ONLY disable the PIT timer interrupt while queues are being
> manipulated & context switching ?

Any interrupt that can read or write to the queue being manipulated needs to be disabled if the queue is accessed both from a task and an ISR.


> 2. Is there any variations of the queue implementation (even commercial ones)
> , that do not disable the interrupts, that I could use in FreeRTOS ?

FreeRTOS uses the scheduler locking mechanism to ensure interrupt remain enabled while data is being actually copied to the queue (the part that could potentially take the most time). Most commercial implementations would just disable interrupts, so may perform worse. The downside is that interrupts are then disabled briefly while the scheduler is being unlocked again.


> 3. Is there any other solutions to this problem ?

There may be a more efficient way of doing whatever it is you are doing. For example, using a circular buffer instead of a queue, and waking the the task using a vTaskResume() once there is data in the buffer, rather than letting the task wake automatically on the queue event.

The use of the FIQ is the best option if the TWI interrupt does not itself cause a context switch.


RE: Interrupts being disabled for extended pe

Posted by Janaka on November 1, 2006
Comrades. Thanks for the responses.
I do run at ~48Mhz. I do measure the IRQ lockout time using debug pin Set/Clear. However I should note that this is not easy as it context switches in middle of queue write/read functions and I had to put some assembler code in the context switching area to get accurate timings (It stores/pulls out CPSR during context switches).
In the IAR compiler I can put some assembler code to leave FIRQs enabled, however I don't know what the effect on the RTOS will be. Thats why I said it will be a FreeRTOS hack.
I am sending a lot of data through the queues (specially for USB). At least Twice every 100mS I send chunks of USB data (30 bytes each). In addition to this, there are other intra tread communications between the 5 threads.
I think alternative queuing/semaphore mechanisms, vTaskResume and scheduler locking has a lot of merit. I am investigating those now.

> Any interrupt that can read or write to the queue being manipulated needs to be disabled
> if the queue is accessed both from a task and an ISR.
Makes sense. This means I have to lock down specific interrupts when accessing specific queues in my implementation.
I will be glad to hear any more suggestions/insights/solutions. Thanks and Cheers.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists