PA0 can't be used for InterruptPort?

I’m having problems with InterruptPort. I’m prototyping touchscreen driver (STMP610 via I2C) before trasferring in native C++ code and I need INT signal from the touchscreen chip that is tied to PA0, but when I try to assign event function to the InterruptPort I get an exception. Any other port/pin works fine.
The firmware is compiled by me on FEZCerb base. I’ve no other reservation or peripheral defined on PA0 … for what I know.

        public TouchScreen()
            touch_int = new InterruptPort((Cpu.Pin) 0x00, false, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeHigh);
            touch_int.OnInterrupt += touch_int_OnInterrupt;          <-- Exception  

            I2CDevice.Configuration i2c_config = new I2CDevice.Configuration( TouchAddress, 400 );
            touchI2C = new I2CDevice(i2c_config);


        static void touch_int_OnInterrupt(uint data1, uint data2, DateTime time)
            // Touch interrupt
            byte[] rbuff = I2CRead(0xd7, 4);
            Debug.Print("Got Touch Interrupt!");

///// Exception
Eccezione first-chance di tipo 'System.ArgumentException' in Microsoft.SPOT.Hardware.dll
Eccezione first-chance di tipo 'System.ArgumentException' in Microsoft.SPOT.Hardware.dll
Eccezione non gestita di tipo 'System.ArgumentException' in Microsoft.SPOT.Hardware.dll

What’s wrong ?

Do you have any other interrupts on pin 0 on other ports (PB0, PC0, etc.)?

Uh Architect, I can’t use pin 0 if I have other int on pin 0 for a different port ?
I have PE0 for Ethernet, yess …

Yes, that is the current limitation. :frowning:

@ Architect - :frowning: :frowning:

Now that you tell me this, I remind some comment in the src code … Very unlucky …
This apply also in native code ?

Not sure if this limitation enforced by hardware or just by the PK only. If this is PK only then you should be able to fix this easily (you are compiling the firmware already).

You will need to change the size of the array that stores the interrupt handlers and use pin and port number for indexing instead of just pin number.

Let me know if you need help to track the exact spot for that.

Theorically if you don’t need to reflect native int to managed code, may be you have no problem. This is not a limitation of the SMT32F4 chip, it has 23 exti io mappable to pins …
Tomorrow I will check the code … this is a big issue becouse the board is wired and I can’t change pins. I wasn’t aware of this.

BOOL STM32F4_GPIO_Set_Interrupt( UINT32 pin, GPIO_INTERRUPT_SERVICE_ROUTINE ISR, void* ISR_Param, GPIO_INT_EDGE mode, BOOL GlitchFilterEnable)
	UINT32 num = pin & 0x0F;
	UINT32 bit = 1 << num;
	UINT32 shift = (num & 0x3) << 2; // 4 bit fields
	UINT32 idx = num >> 2;
	UINT32 mask = 0xF << shift;
	UINT32 config = (pin >> 4) << shift; // port number configuration
	if (ISR) {
		if ((SYSCFG->EXTICR[idx] & mask) != config) {           <-- doesn't take correctly in account the port number
			if (EXTI->IMR & bit) return FALSE; // interrupt in use
			SYSCFG->EXTICR[idx] = SYSCFG->EXTICR[idx] & ~mask | config;

It seems that the [em]STM32F4_GPIO_Set_Interrupt( UINT32 pin, GPIO_INTERRUPT_SERVICE_ROUTINE ISR, void* ISR_Param, GPIO_INT_EDGE mode, BOOL GlitchFilterEnable) [/em] function doesn’t take in account the port when check int register. But the things are not so easy …

If you read the STM32F4 manual, you’ll see that interrupts are multiplexed across pins. You can set PA0’s interrupt, but then you’ll lose PE0’s. This limitation has nothing to do with NETMF or how the port was written; it’s an actual limitation of the processor.


Yes, and if you use PA1’s interrupt, you’ll lose the interrupts of PB1, PC1, PD1, etc. Same thing for PA2/PB2/… etc.

Yes, I know about SYSCFG_EXTICRx limitation for pins. This can be managed in many situations in c/c++ code, but not in this case where PE0 is INT for Ethernet ENC28. Thank you in any case … :frowning:

PS: I was able to move ETH Int from PE0 to PE4 and now TSC is working fine and eth too …
good enough …