5223X Interrupt Controller -- setting levels/priorities

[ScottTrappe]

I'm doing some enhancement work on a project using the MC52233 ColdFire V2 MCU; the original development team is gone. It uses the Interniche TCP/IP stack (free version). My question has to do with setting interupt priorities and levels. The 52235 Reference Manual makes it very clear that every enabled interrupt must have a unique level/priority value, e.g., RM section 15.3.6:

          " 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. ..."

My concern is that the existing code doesn't do this. In particular, all the Fast Ethernet Controller interrupts (sources 23-35) are set with the exact same value: LVL=6, PRI=0. However, the corresponding vector table entries all point to the same interrupt handler, so doest that make this OK? If not, do you have any guidance for how the various interrupt sources should be prioritized?  The EPHY interrupt is at LVL=3, is that lower level typical?

Also, can anyone point me to where the Interrupt Sources are listed?  In MCF52235RM Rev. 7,  in section 15.3.8.1 it refers to Table 15-6, but that is an incorrect reference; there doesn't seem to be any table showing the mapping of interrupt sources into the Interrupt Controller.

Thanks!

[TomE]

> My concern is that the existing code doesn't do this.

You've found a bug in the code. Fix it.

The priorities don't really matter most of the time. They only apply when interrupts at the same level happen at near-exactly the same time, or when interrupts have been masked out for a while and multiple interrupts at the same level are all active. Then the controller has to use the priority bits to decide which one to present to the CPU.

If you do have multiple interrupts with the same priority at the same time then the interrupt controller will probably present a mangled interrupt vector. These sort of intermittent bugs are really hard to track down.

> the corresponding vector table entries all point to the same interrupt

> handler, so doest that make this OK?

I don't think so. The interrupt controller generates a vector, not the service address. it is likely the hardware will select "all vectors" and you could end up with an AND or an OR of the different vectors.

> In MCF52235RM Rev. 7,  in section 15.3.8.1 it refers to Table 15-6,

> but that is an incorrect reference;

Please raise a support request with Freescale. You've found a serious error in that manual. I have Rev 6, and it has four PAGES of interrupt sources listed in that section. When they created Rev 7 they managed to kill this table.

The Rev 6 PDF has 660 pages. Rev 7 has 656, so it looks like they only left these four pages out.

If you look at the Reference Manual Addendum - it doesn't list that Rev 7 has this problem either. so they need to fix the Manual and fix the Addendum until they can fix the manual.

Click on "Support" and then "Create Service Request". You may need to exchange messages with them a few times until they can see the problem you're reporting.

Read the Rev 6 manual here:

http://www.scribd.com/doc/47705663/User-Manual#outer_page_228

Send me a Private Message with your email address and I'll email you Rev 6.

Tom

[ScottTrappe]

For the benefit of any others reading this series of posts, I should confirm that Tom's comment about producing mangled vectors is exactly on-point.

I originally stumbled on this problem while trying to figure out why we were getting "spurious" interrupts from UART 2 -- which was not configured to produce any interrupts!  This was when I noticed that UART 0 and 1, which are configured to generate interrupts, had the same Level/Priority settings. So apparently when both ports are simultaneously generating interrupts, the interrupt controller would get confused just as you say and synthesize a semi-random vector, in this case for UART 2.

By the way, this mis-programming was introduced in the InterNiche TCP/IP stack that Freescale once promoted for use with this chip. All three UARTs use the same settings, as do all the FEC interrupts. Eric Gregory's HTTP server demo code carries on with this bug also. So it has a long ignoble history.   [The UART misbehavior, at least, is masked in the "stock" code, because all three UART ports have interrupt handlers; the UART 2 handler erroneously gets invoked, sees nothing to do, and returns.]

Should I report that as well, or does anyone care about firmware that old?

[TomE]

> [The UART misbehavior, at least, is masked in the "stock" code, because all

> three UART ports have interrupt handlers; the UART 2 handler erroneously

> gets invoked, sees nothing to do, and returns.]

So UART1 and 3 are requesting interrupts, the simultaneous requests with the same priorities generates the vector for UART 2, the service routine does nothing, and then ... the original requests are still pending so it interrupts again. So how does it ever get out of this loop?

Maybe the "vector collision" isn't deterministic and sometimes it generates a valid vector and sometimes it doesn't. Freescale do warn of "undefined behavior", and all warnings like that should be taken very seriously.

> Should I report that as well, or does anyone care about firmware that old?

You've reported it here. I think that's the best you can do.

Tom

[ScottTrappe]

Tom,

      Thanks for your speedy and informative reply, especially the missing manual pages! I submitted a support request to Freescale, so perhaps one more vote will help tilt the scale to get them to actually fix this.

      My issue is wondering if it matters what priorities I should assign to the various FEC interrupts, so if anyone has any experience with this proessor using some other FEC driver than Interniche, I would be indebted to you.

Thanks!

[scifi]

---

TomE wrote:

> In MCF52235RM Rev. 7,  in section 15.3.8.1 it refers to Table 15-6,

> but that is an incorrect reference;

Please raise a support request with Freescale. You've found a serious error in that manual. I have Rev 6, and it has four PAGES of interrupt sources listed in that section. When they created Rev 7 they managed to kill this table.

---

I did that in June last year. They promised to report it to the documentation team.

[TomE]

> I did that in June last year. They promised to report it to the documentation team.

I'd like to say "Astounding, as six months later they released a Reference Manual Addendum without your Addenda", but I'm afraid I have to sadly say "that seems to be typical".

Report it again. Keep reporting it. You can make a difference.

I've just reported it as well. I also suggested they put the Rev 6 one back on the web site for the time being.

I reported a similar problem in November 2009, and 25 months later got a fixed version - that won't be made available as it was found to mainly duplicate other documents. But it got fixed eventually:

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

Tom

[TomE]

I'm pleased to say this problem with the 2011 Rev 7 manual was fixed in 2015. There's a "Rev 7.1" manual. It has an Addendum which states:

Replace the content of section 15.3.8.1 with the following text and Tables 15-16 and 15-17, which were present in Rev. 6 of the reference manual but missing in Rev. 7:
Table 15-16 and Table 15-17 list the interrupt source assignments for Interrupt Controllers 0 and 1.

Tom