This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Error using UART1 as a FIQ

I have a firmware runing fine with UART1 as a normal IRQ.

Recently I realize that I should use UART1 as a FIQ to be sure that the communication works fine.

As an IRQ I had the this defintions:
"...
VICVectAddr7=(unsigned long) ISR_UART1;
VICVectPriority7=0x00000008;
VICIntSelect &= 0xFFFFFF7F;
VICIntEnable |= 0x00000080;
..."
"...
void ISR_UART1 (void) __attribute__ ((interrupt("IRQ")));
...."

void ISR_UART1
{ .... .... cTmp=U1IIR; VICVectAddr = 0x00000000;
}

As a FIQ I changed to:

As an IRQ I had the this defintions:
"...
VICIntSelect |= 0x00000080;
VICIntEnable |= 0x00000080;
..."
"...
void FIQ_Handler(void) (void) __attribute__ ((interrupt("FIQ")));
...."

void FIQ_Handler(void)
{ DEBUG = 1
DEBUG = 0
DEBUG = 1 ISR_UART1(); //it is the only one FIQ so I call imediatly this funciton
DEBUG = 0
}

With the osciloscope I can see the the Debug going '1'->'0'->'1' but it never leaves the function and don't get the final '0'.

Can anyone help me with this???

  • Do you really think a FIQ handler should call an IRQ handler?

    Shouldn't you just throw away your new FIQ handler and instead adjust the UART code to be a FIQ handler? After all, you don't want to waste time with an extra function call.

  • Problem resolved.

    The problem is that I leave the code:

    void ISR_UART1 (void) __attribute__ ((interrupt("IRQ")));

    And when I call the function ISR_UART1 the program don't leave this function.
    I think that the problem is because of this: 1- When start FIQ_Handler the CPU saves the LR making a PUSH. 2- Then I was calling the ISQ_UART1 (with the statement: void ISR_UART1 (void) __attribute__ ((interrupt("IRQ"))); ) So the LR was saved with a PUSH to the stack 3- When the ISR_UART1 ends it makes as operation like RETI (return from an Interrupt). with this the CPU will load the LR previous to the call of the ISR_UART1.

    I think the problem was something like this.

    Thanks,
    Carlos Costa

  • Yes - as I indicated in my first post, a FIQ handler isn't supposed to run any code that thinks it is an IRQ handler. That will seriously break the intended use of the stacks for FIQ and IRQ processing.