ESP32 [WiPy 3.0] GPIO onPinFall Causes Crash


#1

When Pin interrupt is triggered [onPinFall OR onPinRise] the device crashes and I get this …

touched!
Guru Meditation Error: Core 0 panic’ed (Interrupt wdt timeout on CPU0)
Register dump:
PC : 0x40088b58 PS : 0x00060134 A0 : 0x80087546 A1 : 0x3ffc22d0
A2 : 0x3ffc120c A3 : 0x3ffc12d0 A4 : 0x00000c88 A5 : 0x3f406608
A6 : 0x0000cdcd A7 : 0x00060323 A8 : 0x3ffc12d0 A9 : 0x00000011
A10 : 0x3ffc12d0 A11 : 0x00000011 A12 : 0x00000000 A13 : 0x00000001
A14 : 0x0000cdcd A15 : 0x3ffb6500 SAR : 0x0000000d EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000
Backtrace: 0x40088b58:0x3ffc22d0 0x40087543:0x3ffc22f0 0x40085f37:0x3ffc2310 0x4010ab1d:0x3ffc2350 0x4010acff:0x3ffc2370 0x401153fe:0x3ffc2390
Rebooting…
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:3064
load:0x40078000,len:0
ho 12 tail 0 room 4
load:0x40078000,len:11504
entry 0x40078d64

I thought that this was something that I was doing stupid but in the end I moved the WiPy into the Expansion Board and cloned the Interrupt example project directly… no other changes apart from setting the pin numbers. [buttonPin = D13 / ledPin = D12]
Is this a known problem with ESP32 or am I missing something ??


#2

UPDATE !!!

So I found a way to fix this problem but I am sure it’s not right and it certainly is not documented.

If I attach BOTH an onPinFall and onPinRise interrupt to the button pin then everything works happily.
My code now looks like this …

################################################################################
# Interrupt Basics
#
# Created by Zerynth Team 2015 CC
# Authors: G. Baldi, D. Mazzei
################################################################################

import streams
streams.serial()

buttonPin=D13
ledPin=D12 # LED0 will be configured to the selected board led

pinMode(buttonPin,INPUT_PULLUP)_
pinMode(ledPin,OUTPUT)_

def pressed():
print(“touched!”)
digitalWrite(ledPin,LOW) # just blink the LED for 100 millisec when the button is pressed_
sleep(100)_
digitalWrite(ledPin,HIGH)_

def idle():
pass

print(‘start’)
onPinFall(buttonPin, pressed)
onPinRise(buttonPin, idle)

As you can see the onPinRise function is empty but this does appear to sort things out.
question is WHY whats going on ???


#3

Sorry to keep on about this.

I have now put my WiPy board back into my own hardware expansion.
The GPIO interrupt that I am using comes from a touchscreen controller and so pulses everytime I touch the screen.

Using the same example code with a very slight modification I can print a count to the console everytime I touch the screen.

Now comes the issue …
Often touches are not seen, if I hold my finger on the screen a new touch event [pulse] is triggered at about 12mSEC intervals … these are not caught and my counter updates VERY erratically.
I have used this exact same set up with code built using the native PyCom tools with no problem at all so I know that the ESP32 is not the problem here.

Question[s] …
Is the onPinFall event really an edge triggered event. Does it use the native hardware within the chip ??
[it looks to me very much as if it is being polled]

when the debounce value is set to 0 [which I think is the default anyway] is there then a minimum pulse width that will trigger the event ???
Pulses coming from the touchscreen are very clean and about 40microSeconds wide.
These pulses are often not detected so back to the first question !!!

My main reason to switch to Zerynth was to have the ability to embed some C code in along-side the python
[I need to do some drawing on an LCD screen] this does not seem so easy to do using Pycom tools.
Very poor response to the touch screen is going to make this a bad option though.

This is all part of a professional product that we are developing. Possibly 100’s of units/licenses will be required.


#4

Hi @w1bworx,

the onPinRise, onPinFall behaviour is really strange since we are currently using those functions on several ESP32 projects without problems.

Are you using updated virtual machines (version r2.1.2) on your devices?

onPinFall and onPinRise do use native interrupt hardware functionalities, they do not poll for changes in the signal, so, specifying a debounce value of 0, should allow you to detect all changes detectable by pure C ESP32 applications since we are using ESP-IDF functions.

We are glad you appreciate the possibility of mixing C and Python programming and of the fact that you are considering using Zerynth in your professional development.

Let me know if you want the sales team contact you.


#5

Update since originally posting.

I found that MOST of the erratic behaviour was down to the fact that we had configured the Wifi capabilities of the Pycom board. I had a function running in an independent thread that periodically checked the Wifi port to see if it was connected and if not to work through a list of known access point.

In this case however we are not really using Wifi [yet !!] I had been playing around in the days before with FOTA using AWS … which BTW worked well and eventually we might want to add this back again.

So with all the Wifi stuff removed the interrupts are detected just fine so forget all my ranting about polling !!
I am surprised as I understand that from the documentation that pin interrupts are handled mostly above everything else so not sure why the Wifi thread caused problems [and BTW the WiFI WAS connected nearly all of the time so the ‘checking’ thread would not have had anything really to do].

In spite of this I DO still need to add the empty [onPinRise] function however otherwise basically I get the same type of crash as originally reported. Not so much and not everytime though which is interesting.
We are using this for a touchscreen controller so a crash/restart every few button presses is still not usable !!

For the moment this workaround fixes the problem even though I don’t understand why.
And we are adding quite a lot of native c-code to the project now [for other reasons] so I guess we still have the option of handling the pin function there although the Python side really should be able to deal with this !!

Forgot to mention … yes I am using 2.1.2 VM [ FOTA enabled version ]

Oh and while we are not using the Wifi capabilities of the ESP32 [unless we decide that FOTA is a good idea] we definitely will have need of Bluetooth [BLE] at some point… I know that everyone has had some issues with this and I think Espressif have been quite slow on sorting it out but I hope this functionality is soon to be included by Zerynth.