MCF54415 IRQ Status

[nabeelhasan]

Hi

Is there any way to read the status of the IRQ? By this I mean if the IRQ line is held low, is there any register I can read that will tell me if the line is being held high or low.

I was going through the document and I found EPORT Pin Data Register (EPPDR). But I did not find any "#define" in any header files that defines this. I was able to find this register in other processor header files like MCF54454 but we are using a MCF54415.

If any one knows a way to read the status or the IRQ line, that will be very helpful.

Thanks

[TomE]

> I was going through the document and I found EPORT Pin Data Register (EPPDR).

Tricky. That register doesn't appear in the V3 version of the manual, but is in the V4 manual. There seem to be bugs and omissions in the V3 manual in this chapter. But it documents the EDMA properly, and apparently the V4 manual doesn't.

> But I did not find any "#define" in any header files that defines this.

So write your own! The register addresses are in the Reference Manual, so make some appropriate #defines for those registers.

If you can find #defines in the MCF54415  header(10, 15, 16, 17, 18 are all the same) for EPPAR but not EPPDR, then maybe it was written from the faulty Version 3 of the manual.

If you read through "Table 2-2. MCF5441x Signal information and muxing" you'll see that the IRQ pins are also the GPIO Port C pins, so you can read the pin states through Port C as well as through EPPDR.

Very strangely, you can also program the pins as GPIO Outputs AND/OR the same pins can be programmed as Edge Port Outputs. So you could output data through the GPIO PODR_C register while outputting conflicting data through the Edge Port EPDR. There may be a priority or it may short out inside the chip.

Tom

[nabeelhasan]

Hi Tom,

Thanks for the hints,

1. One of the first things I did was just write my own #define, but unfortunately it did not really work. I will try it again just in case I made a mistake.

2. Unfortunately we cannot just read the Eport pins as GPIO. This is because once the pins are configured as IRQs, we cannot read status bits to see if they are high or low. (I found this the hard way :smileyhappy: ). We can only read GPIO Port C pins if they were configured as GPIO.

3. I also tried looking at the registers on CodeWarrior while running my program, and did find EPPDR under Edge port register.

I will try 1. again to see if it works

Thansk

[TomE]

> This is because once the pins are configured as IRQs, we cannot read status bits

That isn't obviously documented anywhere. The pin assignments for these chips are normally done through the Pin Assignment Registers, and for the Edge Port this is "15.3.6.5 Edge Port 0 Pin Assignment Registers (PAR_IRQ0H & PAR_IRQ0L)". The options are basically GPIO, DSP or USB. There's no "assignment to Edge Port" listed there at all. The "18.4.1 EPORT Pin Assignment Register (EPPAR)" register selects Level, Rising, Falling or Both, so there's no combination in that register that should disable GPIO.

So did you find that simple ENABLING the interrupt in "18.4.3 Edge Port Interrupt Enable Register (EPIER)" stops the pin from working as a GPIO? It certainly (again) doesn't say that.

> 1. One of the first things I did was just write my own #define, but unfortunately it did not really work. I will try it again just in case I made a mistake.

It has to be a voltaile pointer, and the right WIDTH. All of these registers are bytes.

When in doubt, always ask Google, in this case for "EPPDR coldfire #define":

https://lists.openwrt.org/pipermail/openwrt-devel/2008-June/002550.html

But since that file is for the MCF5445x the address is "0xFC094005", whereas for your chip it is "0xFC090005".

Tom

[nabeelhasan]

Hi Tom,

I will try the address 0xFC090005. There is a chance I may have just used the 0xFC094005

As for the IRQ and GPIO if you see 15.3.3

"The PPDSDR registers reflect the current pin states and control the setting of output pins when the pin is

configured for GPIO."

Once I set the GPIO as IRQ, I tried reading port C GPIO for that IRQ and it does not reflect the current state of the pin. It only reflects the current state of the pin

once the Pin is re assigned back as GPIO.

[TomE]

> "The PPDSDR registers reflect the current pin states ... when the pin is configured for GPIO."

I read that as "as compared to the pin being programmed to ALT1 or ALT2 in PAR_IRQ0H & PAR_IRQ0L".

Since you're not programming it as ALT1 or ALT2, as far as that chapter is concerned it should still be a GPIO pin.

The pin assignments work differently on different "families" of ColdFire chips. Some/many of the MCF51 work the same way the MC68HC11 did, which is that simply enabling a peripheral (like a UART) is enough for the pins to stop being GPIO and start being UART pins. The MCF52 and MCF53 have pin assignment registers that are independent of the peripherals being enabled or not. Often there can be multiple input pins that can be selected as an input to a peripheral (you can only have one) and multiple outputs (maybe you can have more than one). Sometimes the GPIO Input still works when a pin is reassigned. But the manuals don't detail this very well, You either "just have to know" or you have to reverse-engineer the internal design by writing test code. It would be a lot easier if the manuals had a "pin connection schematic"

Section 18.1 has a NOTE: "The GPIO module must be configured to enable the peripheral function of the appropriate pins", but there is no "Edge Port Peripheral" selection in that chapter for these pins. There's only GPIO, DSP/DREQ or USB.

The MCF54455 Manual has the same modules in it, but in "16.3.5.13 IRQ Pin Assignment Register (PAR_IRQ)" it says "pin configured as GPIO or external interrupt request 4 function as determined by the edge port module", which the MCF54415 manual doesn't say. It doesn't detail what "determines" what the pin does though, and my Rev 5 of that manual has corrupted graphics in the EPORT Block Diagram with the EPDDR graphic being two pages away from the main diagram.

> Once I set the GPIO as IRQ,

> > So did you find that simple ENABLING the interrupt in "... (EPIER)" stops the pin from working as a GPIO?

Is that the register that change it, or is there something else, like changing EPPAR to an Edge Mode? How did you "set the GPIO as IRQ," Simply enabling an interrupt on a GPIO pin (when the GPIO module supports interrupts) doesn't stop the GPIO from working. But this chip is different.

The RGPIO module has a register (16.3.4 RGPIO Pin Enable (RGPIO_ENB)) that is documented to change a pin from GPIO to RGPIO, but the Edge Port module isn't as clear.

Tom