Is the detection of an Interrupt totally dependent on type e.g. level or edge? - .net-micro-framework

Question

Page 36 EMX User Manual states: "Interrupts can be activated on rising or falling edges with an optional glitch filter." However Redpine Signals RS9110-N-11-21 Datasheet states: "Active high, level triggered."
The interrupt is triggered by the WiFi device. Within the C# code if I use a parameter of InterruptEdgeLevelHigh or InterruptEdgeLevelLow I receive an Argument Exception. That is ok as it agrees with the EMX user manual. If I use InterruptEdgeBoth, InterruptEdgeHigh or InterruptEdgeLow I cannot receive a interrupt. I am not sure if this is because the device is using "Active high, level triggered".
If RedPine are limited to "level triggered" should I be able to detect their interrupts with Edge triggered anyway or is the interrupt detection absolutely restricted to Level?
Here is part of the code that I am using to test the trigger:
public static void Main()
{
config = new SPI.Configuration((Cpu.Pin)EMX.Pin.IO2, false, 0, 0, false, true, 1000, SPI.SPI_module.SPI1);
SPI1 = new SPI(config);
WiFiReset = new OutputPort((Cpu.Pin)EMX.Pin.IO3, true);
WiFiInterrupt = new InterruptPort((Cpu.Pin)EMX.Pin.IO26, false, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeHigh);
// "Interrupts can be activated on rising or falling edges with an optional glitch filter." Page 36 EMX User Manual.
// Redpine Datasheet: "Active high, level triggered."
// NETMF interrupt event: "If an InterruptEdgeLevelHigh or InterruptEdgeLevelLow interrupt event occurs, an application must call the ClearInterrupt method to re-enable this event."
WiFiInterrupt.OnInterrupt += new NativeEventHandler(WiFiInterrupt_OnInterrupt);
try
{
byte[] in_initialise = { 0x15, 0x00 }; //initialisation
byte[] out_initialise = new byte[2];
SPI1.WriteRead(in_initialise, out_initialise);
if (out_initialise[1] != 0x58) //SUCCESSFUL
{
WiFiReset.Write(false);
Thread.Sleep(1);
WiFiReset.Write(true);
SPI1.WriteRead(in_initialise, out_initialise);
}
if (out_initialise[1] == 0x58)
{
Debug.Print("WiFi is Initialised.");
WiFiInterrupt.ClearInterrupt();
intFlag = false;
byte[] in_bandStart = { 0x7c, 0x04, 0x10, 0x00, 0x02, 0x18, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00 }; //Band
byte[] out_bandStart = new byte[20];
SPI1.WriteRead(in_bandStart, out_bandStart);
if (out_bandStart[19] == 0x58) //SUCCESSFUL
{
//Debug.Print("WiFi established Band Command Start.");
while (intFlag == false && delay < maxDelay)
{
++delay; //waiting for interrupt
SPI1.WriteRead(tx_data, rx_data);
if (rx_data[0] == 0x55)
break;
Thread.Sleep(1);
}
if (delay != maxDelay)
{
*****************************************************************************************************
static void WiFiInterrupt_OnInterrupt(uint data1, uint data2, DateTime time)
{
byte[] in_intStart = { 0x5c, 0x00, 0x10, 0x00 }; //Band Start
byte[] out_intStart = new byte[4];
SPI1.WriteRead(in_intStart, out_intStart);
intFlag = true;
intTime = time;
}
At the point that the first interrupt is due, I have already received 0x58 several times confirming receipt (see "Waiting for interrupt").
Band Command Start
Send : 7c Recv : 00
Send : 04 Recv : 58
Send : 10 Recv : 58
Send : 00 Recv : 58
Send : 02 Recv : 58
Send : 18 Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 04 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Wait for interrupt
Interrupt received, Do master read
Send : 5c Recv : 00
Send : 00 Recv : 58
Send : 10 Recv : 58
Send : 00 Recv : 58
wait for start token
Send : Dummy 00 Recv : 58
Send : Dummy 00 Recv : 58
Send : Dummy 00 Recv : 55
Read descriptor is
Send : Dummy 00 Recv : 00
Send : Dummy 00 Recv : 97 .........Band Success Response
Send : Dummy 00 Recv : 00
Send : Dummy 00 Recv : 00
Send : Dummy 00 Recv : 00
Send : Dummy 00 Recv : 00
Send : Dummy 00 Recv : 00
Send : Dummy 00 Recv : 55
Send : Dummy 00 Recv : 88
Send : Dummy 00 Recv : 01
Send : Dummy 00 Recv : 00
Send : Dummy 00 Recv : 00
Send : Dummy 00 Recv : d1
Send : Dummy 00 Recv : 27
Send : Dummy 00 Recv : 04
Send : Dummy 00 Recv : 00
Band Response =97 Status=00
--------------------------------------------
Init Start
Send : 7c Recv : 80
Send : 04 Recv : 58
Send : 10 Recv : 58
Send : 00 Recv : 58
Send : 00 Recv : 58
Send : 10 Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Send : 00 Dummy Recv : 58
Any comments would be much appreciated.
Kevin.

Answer 1

This behavior is correct. Your module is generating INT based only on level transition with no edge (blue line on image). EMX set as InterruptEdgeLow/Both/High is expecting only specific (or nonspecific if both edge) edge transition and because only level has changed (without edge), INT is not generated.
This image is not so accurate (transisiton on blue line probably is taking longer in your case) but shows the difference.

Answer 2

The redpine module is level triggered.
You should be able to configure your interrupt handler to detect a rising edge, which will be raised when you transition from low to high.
However, that particular device can leave the interrupt line high when there is further data to service. So you'll need to poll for the interrupt line at the end of your ISR, and only acknowledge the interrupt if you discover that it's low.
Doing so allows your interrupt to trigger again.