FEZ Cerberus port PD2 not available as interrupt port?

Archive
1

The following line of code yields an exception when executed


p_portId=FEZCerberus.Pin.PD2;
bool bGlitchFilter = true;
Port.ResistorMode InputResistorMode = Port.ResistorMode.PullUp;
Port.InterruptMode InterruptMode = Port.InterruptMode.InterruptEdgeLow;
			
mMyPort = new InterruptPort(p_portId, bGlitchFilter, InputResistorMode, InterruptMode);

I can use all other ports on the same slot X7 as interrupt ports except for this one. Is there a specific reason PD2 cannot be used for interrupts? I checked the documentation of the controller but didn’t find a clue.

It is possible to use PD2 as output port. This works as expected.

2

Check schematics, may be it is used for something else.

Are you using Gadgeteer template for your app?

3

PD2 is used for the CMD pin on the SD card. Other than that, all of the pins are interrupt capable. We will investigate as to why the pin is throwing an exception.

4

I already did that.

There is a pullup of 47K to Vcc, perhaps because of IO SD_CMD in the schedule.
I don’t understand however this results in this port not usable as interrupt port?

5

After some reading I discovered why I got an exception when defining port PD2 as an interrupt port.
The answer is here http://wiki.tinyclr.com/index.php?title=Cerb-Family (scroll down to STM32F4 Interrupt Pin Limitations)
I already had defined PC2 as an interrupt port, so this explains the exception.
Maybe somebody else can tick the “this answered the question” button?

6

STM32 Pin are effectively multiplexed between PA, PB and so on…But As I had the same problem, it normally does not throw an exception, but the only thing is that one of boh wont raise the Interruption…Or maybe there is something special checking this multiplexing in the Cerberus Firmware…

Concerning you question about the “Check this is the answer”, only you can check, but can’t check for your self. What you can do is edi your first post, and uncheck the “This is a technical…”, so that it will be set back to a simple topic and won appeat anymore as an unanswered question on the forum.

7

Thanks Louis - did just that.

8

Note that this isn’t a limitation of the STM32F4, it’s a limitation of the firmware. I don’t think that a given EXTI line (PA0/PB0/PC0/etc is EXTI0, for example, and PA1/PB1/PC1/etc is EXTI1) can be configured for a different TYPE of interrupt simultaneously (rising edge vs falling edge, for example), but the interrupt will still be generated regardless of which port was triggered. I think.

If I’m wrong or misunderstanding the reference manual, please correct me.

9

@ godefroi -

Look at this, chapter 2.2.11, only 16 external I/O interrupt line a a time…

http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/DM00037051.pdf

10

PA0 and PB0 will raise the same interrupt, so one would need some way to know which pin caused the interrupt, but it will still be raised for either, I believe.

Again, I could be wrong…

11

When testing one of my modules, I had the following issue :

The same PIN for UART and InterruptInput : If I do not initialize the UART, the input throw on event, else, it does not ! sot it is not both raise, but more only one of both raise…

12

But I believe that’s a bug in the firmware, not a fundamental limitation of the hardware?

13

Perhaps…