Hub AP5 Module and Interrupts

NETMF & Gadgeteer
1

I have a Corba II (Eco) with a hub AP5 module. The hub (socket 8) ist connected to a breakout module. The hub (socket 5) ist connected to a led strip.

The interrupt is handled a few times and stopps. If the breakout module is directly connected to the Corba II (Socket 5) it works properly. It seams that the communication between Corba II (Eco) and hub AP5 does not working continuously.

How can I fix it?

Code:

  InterruptInput in1 = breakout.CreateInterruptInput(Gadgeteer.Socket.Pin.Three, GT.SocketInterfaces.GlitchFilterMode.Off, GT.SocketInterfaces.ResistorMode.Disabled, GT.SocketInterfaces.InterruptMode.RisingAndFallingEdge);

  InterruptInput in2 = breakout.CreateInterruptInput(Gadgeteer.Socket.Pin.Four, GT.SocketInterfaces.GlitchFilterMode.Off, GT.SocketInterfaces.ResistorMode.Disabled, GT.SocketInterfaces.InterruptMode.RisingAndFallingEdge);

  in1.Interrupt += in1_Interrupt;
  in2.Interrupt += in2_Interrupt;

  Debug.Print("Program started.");
}

void in1_Interrupt(InterruptInput sender, bool value)
{
  ledStrip.SetLed(1, value);
}

void in2_Interrupt(InterruptInput sender, bool value)
{
  ledStrip.SetLed(2, value);
}
2

@ Michael.62 - Is the hub connected to socket 4 on the Cobra II? Roughly how many times does it take for the interrupt to fail? How are you triggering the interrupt? Even though it works fine on the Cobra II, can you check the line to see if it is actually changing state?

3

  1. Yes, the hub is connected to port 4 on the Cobra II.

  2. Sorry, I can not reproduce the behavior on port 8 (hub). The interrupt will not fired. If I connect the hub to port 5 (Corba) all is working. Also I can read the ports directly (hub).

  3. I use the button from the breadboard X1. It is connected to port 8 (hub).

  4. I have checked the signals with a multimeter and the level is changing between 0V and 3.2V.

Further I have installed the NETMF and Gadgeteer Package 2014 R5.

4

I can reproduce the behavior:

  1. The event is fired with the button on the Breakout Module.
  2. It works when I press the button in an interval of roughly 1 second.
  3. It stops when I press the button faster.
  4. Further slower events are now ignored.
  5. The hub accepts no events until power off and power on.

Maybe the hub (firmware) is not able to handle events, which are faster than the software can process them (event overflow)?

5

@ Michael.62 - After the hub stops processing interrupts, are you still able to talk to it and tell it to turn and led on or off or does it completely stop responding?

6

Yes, I can communicate with the hub and leds are switching. Only the interrupt handling is stopped.

7

@ Michael.62 - If you connect the hub to socket 4 on the Cobra II and then connect a button anywhere on the hub, and you run the below code, does the issue persist?


void ProgramStarted()
{
	this.button.ButtonPressed += (a, b) => Debug.Print("Pressed.");
	this.button.ButtonReleased += (a, b) => Debug.Print("Released.");
}
8

Sorry, unfortunately I have no Button - but an identical circuit with a breadboard realized.

Yes, the event is fired until I push the button very quickly.

Output from Visual Studio 2013:

Using mainboard GHI Electronics FEZ Cobra II Eco version Rev B
Program started.
Der Thread ‘’ (0x5) hat mit Code 0 (0x0) geendet.
Pressed.
Released.
Pressed.
Released.
Pressed.
Released.
Pressed.
Released.
Pressed. => Last Event.

9

@ Michael.62 - The hub itself is connected to socket 4 on the Cobra II? Do you have anything else connected in the designer? The code I gave still showed the issue?

10

Yes, the hub is connected to port 4 (corba) and only corba, hub and button are connected in the designer.

For the test I have created a new project:

  • Corba II (Eco)
  • Hub AP5 => connected to port 4 (Corba)
  • Button => connected to port 1 (Hub)

Your code shows the same issue.

11

@ Michael.62 - Can you see if pin 3 on the cable between the Cobra II and Hub continues to toggle when you press the button? It is the interrupt line that is signaled when an input on the hub changes state so we can raise events to you.

12

I don’t want to mess up any kind of debugging and help, but have you tried a different cable? Do you have another hub to try?

13

With a new Hub and cable - the same issue.

Signal pin 3 (between Corba II and Hub):

  1. Low after power on.
  2. Changes from low => high => low, if the button is pressed.
  3. Changes from low => permanent high, if the the button pressed quickly.

In my opinion is point 3 (Hub) the main problem.

14

@ Michael.62 - The line remains high because it is waiting for us to talk to the hub and figure out what input pin was toggled. Since we cannot reproduce your issue here, can you add the HubAP5 sources to your project from https://bitbucket.org/ghi_elect/gadgeteer/src/716277af79fb3edc6f9ad76afa071ccceb5cc0ef/Modules/GHIElectronics/HubAP5/HubAP5_43/HubAP5_43.cs?at=master? https://www.ghielectronics.com/docs/122/gadgeteer-driver-modification should help. Line 449 has the interrupt function that is called. Could you add a debug.print to the start of it to see if it is getting called when the interrupts die for you?

15

Ok. The Hub is not the problem.

Here the output:

Using mainboard GHI Electronics FEZ Cobra II Eco version Rev B
Program Started
Der Thread ‘’ (0x5) hat mit Code 0 (0x0) geendet.
OnInterrupt.
Pressed.
OnInterrupt.
Released.
OnInterrupt.
Pressed.
OnInterrupt.
Released.
OnInterrupt.
Pressed.
OnInterrupt.
Released.
OnInterrupt.
Pressed. => Last event.

The interrupt handler is not called.

16

I have replaced Cobra II (eco) through a new Corba II (net). Same issue.

17

Now I have removed the hub between Corba and button. The button is connected to port 4 (Corba). This configuration works without the known issue.

Is there a different handling of the interrupts between Hub and Button when they are connected to port 4 (Corba)?

Loaded assembies (MFDeploy):

DeviceInfo:
HAL build info: 4.3.1.0, Microsoft Copyright (C) Microsoft Corporation. All rig
OEM Product codes (vendor, model, SKU): 255, 0, 65535
Serial Numbers (module, system):
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Solution Build Info: 4.3.6.0, Copyright (C) GHI Electronics, LLC
AppDomains:
default, id=1
Assemblies:
mscorlib,4.3.1.0
Microsoft.SPOT.Native,4.3.1.0
Microsoft.SPOT.Security.PKCS11,4.3.1.0
System.Security,4.3.1.0
Microsoft.SPOT.Hardware,4.3.1.0
Microsoft.SPOT.Graphics,4.3.1.0
Microsoft.SPOT.TinyCore,4.3.1.0
Microsoft.SPOT.IO,4.3.1.0
System.IO,4.3.1.0
Microsoft.SPOT.Hardware.Usb,4.3.1.0
Microsoft.SPOT.Hardware.SerialPort,4.3.1.0
Microsoft.SPOT.Touch,4.3.1.0
Microsoft.SPOT.Ink,4.3.1.0
Microsoft.SPOT.Hardware.PWM,4.3.1.0
Gadgeteer,2.43.1.0
GHI.Hardware,4.3.6.0
GTM.GHIElectronics.HubAP5,4.3.6.0
GTM.GHIElectronics.Button,4.3.6.0
GHI.Usb,4.3.6.0
Microsoft.SPOT.Net,4.3.1.0
GHI-Test,1.0.0.0
GHIElectronics.Gadgeteer.FEZCobraIIEco,4.3.6.0

18

@ Michael.62 - the hub uses an expanded chip to give you the IOs you see. Interrupts on the hub sockets are routed through a single pin on that chip that we have to poll to see which pin raised it.

The interrupt was raised when you pressed the button. But it wasn’t when you released it. Can you confirm that the physical interrupt line was deasserted after the press and then see whether or not it was asserted again when you released it even though the handler was not called?

19

With my simple test equipment (analog oscilloscope) I get the following result:

  1. If the button is pressed, the physical interrupt line goes high and low. The software interrupt is handled.
  2. If the button is released, the physical interrupt line goes high and never low. The software interrupt is not handled.
20

@ Michael.62 - This issue should be fixed for the next SDK.