ColdFire/68K Microcontrollers and ProcessorsのトピックMCF5235 Interrupt Vector 191

MCF5235 Interrupt Vector 191

Ahlan — Mon, 05 Sep 2011 21:47:06 GMT

Hi,

We are using a MCF5235 processor with the eTPU loaded with the Freescale Set1 and Tpu channels 0 through 7 programmed as GPIO.

If we raise more than one of the first 8 eTpu inputs simulataneously (inputs are wired together) the processor takes vector 191 (VBR + 0x2FC)

Vector 191 is INTC1 source 63 which according to the RM rev 1.1 on page 13-18 is "Not used".

Obviously this is not the case.
Can someone tell us what the interrupt means and why it might occur.

I filed SR 1-782546511 on Thu 25-Aug-2011 but as of today (5-Sep-11) the SR has not been assigned to anyone.

Perhaps the forum can do better?

Hoping that someone can help us,

best wishes,

Ahlan

Re: MCF5235 Interrupt Vector 191

TomE — Tue, 06 Sep 2011 07:20:26 GMT

Check all of the Interrupt Pending registers to see what the interrupt controllers think they're doing. Check both IRLRn and IACKLPRn registers.

Check:

13.2.1.6 Interrupt Control Register (ICRnx, (x = 1, 2,..., 63))

Each ICRnx specifies the interrupt level (1–7) and the priority within the level (0–7). All ICRnx registers can be read, but only ICRn8 to ICRn63 can be written. It is the responsibility of the software to program the ICRnx registers with unique and non-overlapping level and priority definitions. Failure to program the ICRnx registers in this manner can result in undefined behavior.

Multiple TPU interrupts at the same priority/level could be causing this.

There's nothing in the errata for this chip matching this problem, but read SECF180 in the MCF5208 Errata and make sure you're not triggering any Spurious Interrupts.

Tom (A Random Poster)

Re: MCF5235 Interrupt Vector 191

MrBean — Tue, 06 Sep 2011 16:10:19 GMT

Thread from 2009, same cause:

https://community.freescale.com/message/51128#51128

Re: MCF5235 Interrupt Vector 191

Ahlan — Tue, 06 Sep 2011 19:32:10 GMT

Thanks to TomE and Mr Bean for solving this problem!

Indeed simultaneously raising interrupts that have the same level/priority causes the processor to take an illegal vector.

Strangely it was always 191 - and sad that Freescale doesn't document this problem more clearly and that no-one at Freescale could be bothered to reply to my SR.

Many thanks to the Forum :smileyhappy:

The coding error stems from our porting the application from CPU32 where the TPU generated the interrupt vector of the lowest numbered channel when multiple interrupt requests were present.

I think it is a definite weakness of Coldfire that the ICR level/priority has to be unique and even worse that if it isn't then unspecified nasty things happen!.

MfG

Ahlan