IRQ Code causes LoPy reset every time - any ideas please?

[Dan.C]

Hi experts,

We are trying to run the following bit of code and we get a reset every time that the pin state changes e.g. throwing a switch or button change or any hardware change at all. Can anyone see what we may be doing wrong?

pin_pump = Pin('P8', mode=Pin.OUT, value=1, pull=Pin.PULL_UP)

pin_switch = Pin('P17', mode=Pin.IN, pull=Pin.PULL_UP)

def handler_switch():

pin_pump.toggle()

pin_switch.irq(trigger =(Pin.IRQ_HIGH_LEVEL | Pin.IRQ_LOW_LEVEL), handler=handler_switch)

[LoneTech]

First, when writing a block of code in the forum, please wrap in triple backquotes ``` or indent with four extra spaces. This causes it to be formatted as code:

pin_pump = Pin('P8', mode=Pin.OUT, value=1, pull=Pin.PULL_UP)
pin_switch = Pin('P17', mode=Pin.IN, pull=Pin.PULL_UP)
def handler_switch():
    pin_pump.toggle()
pin_switch.irq(trigger =(Pin.IRQ_HIGH_LEVEL | Pin.IRQ_LOW_LEVEL), handler=handler_switch)

Second, on the surface of it, your code is fine (although there should be no point to having a pullup on an output).

Third, we have a few pins with peculiar functions on the LoPy. P8 (internally GPIO 2) should be fine as long as you don't put a microSD card in the expansion board (it's connected to DAT0 on that slot), but P17 (internally GPIO 35) happens to be in two peculiar ranges; P13 to P18 are input only, and GPIO >=32 seem to not be correctly handled in the current firmware. These pins also default to not be in GPIO mode. In a quick test I don't even seem to get a digital input level from that pin, let alone the bug that causes its irq method to mess with registers for P0 (GPIO 3). It may well be enabling that interrupt without setting up its handler, and then crash rapidly because of serial activity. Furthermore, as I haven't gotten anything to happen on P17, there's a chance both I and the firmware are mistaken on which GPIO it actually is routed to.

Other pins to avoid include P2, which is used for the RGB LED and low level bootloader, P12, which is used for the high level bootloader, and P5-P7 which are used for the LoRa radio. We still need to iron out which pins are fully usable.

We'll probably need a better understanding of the RTC / analog functions to fix the issues with P17, and it's likely output ability will never be there (including pull up/down). For the moment, try a less peculiar pin, like P3 or P11.

[LoneTech]

Sorry, I missed the most common mistake: handler_switch gets called with an argument (the pin that generated the interrupt). You need to accept that, even if you don't use it. I'm a little too focused on details sometimes.

[Dan.C]

LoneTech - thank you so much for your detailed clarification! I will give it a try and share my findings with the forum.

Thanks again!