MSP430F2274: RX interrupts collisions

The F2-series USCI interrupts are a bit of a maze, but I think(?) the indicators are all unambiguous.

What sort of collision are you seeing?

Hi Geral,

I would recommend to disable a COMM once the other is active, and vice versa.

Best Regards,

Diego Abad

I expect that if the two are independent then it should work. But if servicing one requires doing something to the other, then there could be problems. The cure being highly dependent on the dependencies.

Remember that GIE gets cleared when an interrupt is serviced but you can set it again within the ISR if required.

The I2C communications if for on board hardware control and the UART is used for a RS485 as a Slave Device.

The primary function of our product requires that the RS485 communications take precedence over the I2C.

The "collision" occurs when I2C is active and RS485 message is received leading to no response from the RS485 message. 

David's reply may provide insight as to what to look for. It maybe the collision isn't the issue, but rather I may clearing both interrupts and failing to service the second one.

Looking at our ISR for the USCIAB0RX_VECTOR I see we test which bit is set.

• IFG2 & UCA0RXIFG for UART
• IFG2 & UCB0RXIFG for I2C.

After handling each one we clear the corresponding bit:

• IFG2 &= ~UCA0RXIFG; for UART
• IFG2 &= ~UCB0RXIFG; for I2C

So if if both bits are set and one is handled that clears that interrupt will the other interrupt bit still trigger the same USCIAB0RX_VECTOR to fire again?

What happens if the ISR is handling one communication channel and the other communication channel receives a byte?

Any set and enabled interrupt flag should result in another interrupt cycle after the RTI.

One thing to keep in mind, clearing RXIFG as you show is usually not required since reading RXBUF does it automatically.

GIE is cleared during interrupt processing so if another interrupt triggers while an ISR is active, the new interrupt will not be handled until after the return from interrupt. Unless you set GIE in the ISR.

Without really knowing what's wrong, I'll throw in some observations from the Platitudes Department:

1) When I see code that explicitly clears RXIFG, it sets off alarms in my head. Reading RXBUF clears RXIFG atomically, so clearing it explicitly is either too early or too late. There are cases where you'd do that but they're rare (and probably outside the ISR). Also, the compiler will normally generate a BIC which (as far as I know) is atomic, but it would be permitted to use a read/modify/write sequence which could clear an unrelated IFG that arrived at just the "right" time.

2) I avoid using the IV register, particularly for the USCI. The arguments are analogous to (1), plus some concerns about (fixed) priority.

3) The I2C has flow control, but the UART doesn't. In the absence of other context, I'd probably give priority to the UART.

4) As always: Keep the ISR (path) very short. If e.g. a UART byte arrives while you're working with the I2C, you have a deadline (computable based on the bit rates) before the next (UART) byte arrives and overruns.

To answer your question: If both IFGs are set (or the second gets set while your ISR is executing), and your ISR only clears one  you'll pop right back into the ISR after exiting. There's an argument for structuring the ISR as a "while(any are set)" loop, but I'm not sure that's worth the benefit.