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

Weird Interaction With VIC on ARM/LPC2103

Posted by rost_stargen on April 23, 2007
My environment:

Olimex LPC-P2103 board (ARM7)
Eclipse 3.2.2
GCC 4.0.2
Free RTOS 4.1.1

I have some problems with interrupts hanging queues and task delays.

I have interrupts enabled for TIMER2 in the LPC2103 processor. When the interrupt fires, my ISR (based on the serialISR demo) disables the interrupt, executes a QueueSendFromISR and then writes the VICVectAddr register to force the processor to readjust the interrupt priority. However the QueueReceive call in the task that is waiting on the queue hangs and a vTaskDelay call in another unrelated task hangs. If I do NOT write the VICVectAddr register things work OK.

I have a second interrupt for EINT2 (triggered by a momentary button on the board) and this interrupt seems to be serviced correctly regardless of whether or not I write the VICVectAddr register after servicing the TIMER2 interrupt which doesn't make sense to me.

I have been unable to see how writing the VICVectAddr register should have any effect on the queue or task delay.

Any ideas what I should look at?

Brian

RE: Weird Interaction With VIC on ARM/LPC2103

Posted by embeddedc on April 23, 2007
> writes the VICVectAddr register to force the processor to readjust the interrupt priority

Is this a valid thing to do while an interrupt is being processed. Does it work when not using FreeRTOS?

Maybe it is screwing up the timer interrupt hence the delay function does not work?

What do you mean by "readjust"?

RE: Weird Interaction With VIC on ARM/LPC2103

Posted by rost_stargen on April 23, 2007
embeddedc,

From the LPC2100 manual (not the best grammar!!!):

"Vector Address register (VICVectAddr - 0xFFFF F030)
This is a read/write accessible register. When an IRQ interrupt occurs, the IRQ service routine can read this register and jump to the value read. If any of the interrupt requests or software interrupts that are assigned to a vectored IRQ slot is (are) enabled, classified as IRQ, and asserted, reading from this register returns the address in the Vector Address Register for the highest-priority such slot (lowest-numbered) such slot. Otherwise it returns the address in the Default Vector Address Register. Writing to this register does not set the value for future reads from it. Rather, this register should be written near the end of an ISR, to update the priority hardware."

I don't think the above is very clear (ha ha), we understand it to mean the register can be read but written values are ignored, writes simply trigger the CPU to update it's view of the pending interrupts.


From serialISR.c (FreeRTOS demo for ARM7_LPC2106_GCC):

void vUART_ISR( void )
{
/* This ISR can cause a context switch, so the first statement must be a
call to the portENTER_SWITCHING_ISR() macro. This must be BEFORE any
variable declarations. */
portENTER_SWITCHING_ISR();

.....

/* Clear the ISR in the VIC. */
VICVectAddr = serCLEAR_VIC_INTERRUPT; <---- this is defined to be ZERO

/* Exit the ISR. If a task was woken by either a character being received
or transmitted then a context switch will occur. */
portEXIT_SWITCHING_ISR( ( xTaskWokenByTx || xTaskWokenByRx ) );
}


From my code:

void vEUI_ISR( void )
{

/* This ISR can cause a context switch, so the first statement must be a
call to the portENTER_SWITCHING_ISR() macro. This must be BEFORE any
variable declarations. */
portENTER_SWITCHING_ISR();

....

/* Clear the ISR in the VIC. */
WRITE(VICVectAddr, euiCLEAR_VIC_INTERRUPT); <--- "write" is our own routine for reg access, the param here is defined as ZERO...in other words, this should be the same as the demo example (I did try the EXACT syntax from the demo, same result)

/* Exit the ISR. No context switch will occur. */
portEXIT_SWITCHING_ISR(bQueueReturnValue);

}

Bothe the demo and my code call xQueueSendFromISR.


Brian

RE: Weird Interaction With VIC on ARM/LPC2103

Posted by embeddedc on April 23, 2007
It is curious that it works without the call to WRITE(VICVectAddr, euiCLEAR_VIC_INTERRUPT), as without this the interrupt is never complete as far as the VIC is concerned.

Are you using startup code that is based on code from another FreeRTOS.org demo? Specifically, are you vectoring directly to the ISR, or is there some code that executes prior to the ISR? To know look at what is loaded in the IRQ vector. If it is something like this:

ldr pc, [pc,#-0xFF0]

then you are vectoring directly to the ISR.

RE: Weird Interaction With VIC on ARM/LPC2103

Posted by rost_stargen on April 23, 2007
embeddedc,

I found the problem finally. I wasn't properly clearing the interrupt in the ISR, I was only disabling it. As a result the code kept re-entering the ISR and starving out all other non-interrupt tasks. I'm confused why when I did not trigger the CPU to update the interrupt priorities the ISR was not being re-entered, but that's something I'll worry about after I wrap up work on this ISR.

Thanks for your replies.


[ 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