We have a project with various interrupts. The 1ms C0 timer interrupt is the lowest priority and we would like the RXC uart interrupt to be able to interrupt this timer interrupt.

We have added a asm("sei") instruction at the beginning of the Timer ISR but when we set the timer INTFLAG, the timer routine needs to complete before it then call the Timer ISR again. We are using the JTAG ICE. Is this normal operation?

The problem we have is dropped receive bytes and it appears this is due to an interrupt routine taking too long - ie two serial bytes may be received during timer ISR.

I guess a DMA pipe would fix this but using the DMA does not look straight forward.

Multiple interrupts with xmega are not managed by the I flag.
Therefore, multiple interrupts of the same interrupt level are not generated.
Let TimerC 0 be a low-level interrupt and RXC be a high-level interrupt.
The sei command is useless. Because the I flag is not manipulated by xmega interrupts.

Use of multilevel interrupts requires caution. This is because unless cli is executed in the low-level interrupt, a higher level interrupt is always executed.

Whoah! Talk about dodgy practice. You have to be VERY sure there's no possibility the ISR may recurse in that case !!

Far better is to reassess your overall design. As long as ISR() handlers are over in microseconds they should not really block others though there could be a very small jitter as their service is delayed.

Kabasan, you reply is very informative. I think you are correct that the I flag is not used in interrupts and so the sei instruction is useless. I know that with other microcontrollers, the i-flag is manipulated which then allows interrupts to be blocking or non-blocking.

Clawson, we are trying to make this work, not break it. We are currently using USB HID and a 500kBaud UART. It looks like it is probably the USB interrupt (there are two interrupts) which takes a few us to complete. At 500kBaud, it only takes 4us to skip a byte. I have changed the speed down to 125kBaud but there is still an issue. When I set the USB interrupts to medium level priority, the USB HID driver does not run.

Not sure where to go now. Does anyone know how to use the JTAG ICE trace? I have been using the JTAG ICE for around a month now and it does seem very limited and is not so good at even single stepping (except in assembler).

Yes, the sei/cli instructions do work, but I was specifically referring to inside the interrupt.

For example, if an interrupt is called, and the sei instruction is used to re-enable interrupts within the ISR and the same interrupt flag trigger gets set, the next interrupt will not get called until after the first interrupt finishes. I did test this in the JTAG ICE. This is not a major deal breaker but could cause some issues if it is not understood.

In the end, the issue I had was not related to this - it was to do with some very rough oscillator calibration.

and the same interrupt flag trigger gets set, the next interrupt will not get called until after the first interrupt finishes.

That does not sound right. When I is enabled then on every opcode fetch the AVR checks the set of interrupt trigger flags and will then vector to any it finds set. So if you are in UART ISR, then you SEI, then the UART trigger happens again you should find yourself back at the start of the UART ISR having interrupted the only half finished previous service. That is why I mentioned recursion above!

Perhaps Xmega have some different way to handle this compare to Tiny/Mega ?

It seems you are spending a lot of time servicing the timer interrupt. Can't it just set a flag and return? Whatever you have as an "operating system" could then do what needs to be done as a result of the timer interrupt, as a normal interruptible task?

The counter/timer is a big beast. It can generate several interrupts. Some of the interrupt request flags are cleared when the interrupt is taken. At least one other is not cleared automatically. You have to read a register. If that interrupt flag is not cleared it would generate constant interrupts. I don't see any other way the counter/timer could cause overruns in the usart.

Well if the counter/timer was set up to generate a million interrupts a second, that could wreak havoc.