Main Site Documentation

Interrupt stops working


#1

Hi all,

well i have got a problem that has got me totally puzzled :’(

I our design we use several i2c port expanders (type PCA9535). These can generate an interrupt signal so indicate to the processor that data on the inputs has changed. Worked fine in the past. The signals are send to 2 inputs of our processor and we use the code:


        static InterruptPort ExpanderMother_ChangedPort = new InterruptPort((Cpu.Pin)EMX.Pin.IO23, true, Microsoft.SPOT.Hardware.Port.ResistorMode.PullUp, Microsoft.SPOT.Hardware.Port.InterruptMode.InterruptEdgeLow);
        static InterruptPort ExpanderStack_ChangedPort = new InterruptPort((Cpu.Pin)EMX.Pin.IO21, true, Microsoft.SPOT.Hardware.Port.ResistorMode.PullUp, Microsoft.SPOT.Hardware.Port.InterruptMode.InterruptEdgeLow);
        static InterruptPort Button_Select = new InterruptPort((Cpu.Pin)EMX.Pin.IO30, true, Microsoft.SPOT.Hardware.Port.ResistorMode.PullUp, Microsoft.SPOT.Hardware.Port.InterruptMode.InterruptEdgeLow);
        
ExpanderMother_ChangedPort.OnInterrupt += new NativeEventHandler(ExpanderMother_ChangedPort_OnInterrupt);
            ExpanderStack_ChangedPort.OnInterrupt += new NativeEventHandler(ExpanderStack_ChangedPort_OnInterrupt);

I have also added an intterupt port etc to the select button on our pcb for testing purposes. Somehow i stop receiving the other interrupts. So i thought i might be getting no interrupts at all. But pushing the select button show that interrupt immidiatly. So i went on to looking at the port expanders. I hooked up our scope / logic analyzer to the pins on the processor and i can see that the signal goes low… But no response from my code. Even if i make the input low manually there still is no response. But again pushing the select button will gives immidiatly response :o

Any clues or hints anybody? So the weird thing is that they do work sometimes…

Regards,

Per


#2

Maybe you are releasing the object and at some point it is garbage collected.


#3

Hi Gus,

well i have done a lot of testing and it looks to me that it has got something to do with the pull up resistors (on the PCA9535 i think). Somehow the low going edge doesn’t get detected (but i do see it on my scope). If i connect the input on the emx shortly to the vcc the interrupts work again.

So i am looking at the pull up resistors and the vcc now.

Regards,

Per


#4

Hi,
I have same problem ( http://tinyclr.com/forum/10/3515/). Do you know how remove problem with interupt? Please.


#5

What do you do when you get the interrupt? You should not leave the program to stuck in the event handler for long time because this will block other events. Maybe this is the reason why you are not seeing the interrupt firing?


#6

Hi Joe,

We actually have got 2 interrupt problems now (maybee the last isn’t a real intterupt problem)

  1. The problem with the port expander is solved now. We have got a intterupt driven read function. The read isn’t done in the interrupt handler, it is a short as possible (just 2 lines of code in there). But we did seem to miss an interrupt sometimes. On the PCA9535 the interrupt output will stay low until you do a read on the port that drives the intterupt. There are 2 8 bit busses on it. We have defined one of them as 8 inputs and the other as 8 outputs. The problem was with the outputs. 1 of them wasn’t connected and started to float. This would then would force the int output to go low. But that actuall interrupt was missed sometimes by the emx (maybee because it wass bussy with something, we seem to push the limits of the emx with our design). The other problem is that we never read the output bus of our expander (since they are defined as outputs i didn’t see a reason to do that). But that bus generated the low int output and wouldn’t reset until you do a read. So we now just read both busses of the expander and everything works ok now. Still no real idea why we miss the interrupt that the second bus generates though, but we don’t have any problems anymore with this workaround.

  2. Our second problem is with the CAN bus. We stop getting the data received interrupt / event. The can bus works nice though. I can send to the connected device and it get’s data. I just don’t get any data received event. I have got a CAN tester connected and i can see that the device is sending data to the EMX. The only solution when this happens is to disconnect everything from the emx (usb, ethernet ) and restart it. There are no CAN error either. So this one has got us a bit puzzeled again ???


#7

Maybe 2 is related to 1. Do not use the port expander, does CAN work well?


#8

Hi Gus,

removed that part of the code completely and that doesn’t help. What seems to help is connecting our can debugger.

We use this software + hardware : http://www.wgsoft.de/de/menu-can-monitor-linls/menu-can-monitor-ss.html

This sollution seems to be very consequent ??? So if we stop getting the data received event (and we are alway able to send data, that goes fine) we can reboot our emx many times and it stil keeps failing. If i then connect the debugger software / hardware ( and reboot the emx) it will be fixed. 100% fixing rate.

Do you have any ideas on this? Maybee something with the bus state / load? Like i said, we don’t get any errors (or maybee those events aren’t fired either).

Regards,

Per


#9

I do not know CAN. But, is there some type of terminator that needs to be on the buss?

That could explain why the test equipment cures the problem.


#10

Did you subscribe to all error events from CAN like “buss off”?

Maybe you have too many errors to the point FEZ is going “buss off”


#11

Hi Gus,

yes we subcribe to all events and output them to the debugger. But we don’t get any errors. If i disconnect the can device that is on the bus (while the debugger is attached) then i get a bus off error nicely.

[quote]Maybe you have too many errors to the point FEZ is going “buss off”
[/quote]

If this would happen, then i shouldn’t be able to send data either? And why would connecting the debugger prevent this state? Because the debugger isn’t doing anything on the bus (apart from listening).

Like i said, this one has got me really puzzled…


#12

Can you make a very small program to test just CAN and let us know if you see the same behavior?


#13

Hi Gus,

i will do that! I will send you the results later today.

Regards,

Per