Strange behaviour of interrupts

Recurrent H/W and software problems
ulli
Posts: 47
Joined: Tue Feb 09, 2021 9:48 am
Location: Monschau, Germany
Has thanked: 8 times
Been thanked: 2 times

Strange behaviour of interrupts

Post by ulli »

Hi all,

I'm trying to create an event driven program on an ESP-WROOM-32 and interrupts are driving me mad.

There are 8 input pins generating interrupts when they go low plus at least one timer routine called every couple of ms. I first tried interrupts only, no timer. This works for three to five interrupts, then stops working. If I add a timer it becomes even worse. The timer service routine works until one of the interrupts comes in. Then it stops working, the interrupt is also not served, the whole thing becomes unresponsive.

Here's the code with unnecessary parts left out:

Code: [Local Link Removed for Guests]


'Ports

SENSOR1 = 36
SENSOR2 = 39
SENSOR3 = 34
SENSOR4 = 32
SENSOR5 = 33
SENSOR6 = 25
SENSOR7 = 35
SENSOR8 = 26

'...

'Sensor init

pin.mode SENSOR1, input
pin.mode SENSOR2, input
pin.mode SENSOR3, input
pin.mode SENSOR4, input
pin.mode SENSOR5, input
pin.mode SENSOR6, input
pin.mode SENSOR7, input
pin.mode SENSOR8, input

interrupt SENSOR1, irh1
interrupt SENSOR2, irh2
interrupt SENSOR3, irh3
interrupt SENSOR4, irh4
interrupt SENSOR5, irh5
interrupt SENSOR6, irh6
interrupt SENSOR7, irh7
interrupt SENSOR8, irh8

'...

timer0 2000, ti
wlog "before wait"
wait
wlog "past wait"

irh1:
if pin(SENSOR1) = 1 then return
interrupt SENSOR1, OFF
wlog "1"
return

irh2:
if pin(SENSOR2) = 1 then return
interrupt SENSOR2, OFF
wlog "2"
return

irh3:
if pin(SENSOR3) = 1 then return
interrupt SENSOR3, OFF
wlog "3"
return

irh4:
if pin(SENSOR4) = 1 then return
interrupt SENSOR4, OFF
wlog "4"
return

irh5:
if pin(SENSOR5) = 1 then return
interrupt SENSOR5, OFF
wlog "5"
return

irh6:
if pin(SENSOR6) = 1 then return
interrupt SENSOR6, OFF
wlog "6"
return

irh7:
if pin(SENSOR7) = 1 then return
interrupt SENSOR7, OFF
wlog "7"
return

irh8:
if pin(SENSOR8) = 1 then return
interrupt SENSOR8, OFF
wlog "8"
return

ti:
wlog "timer"
return

end

It should serve every input interrupt once printing its number to the console. Independently the timer should chime up every 2 secs.

But this is not what happens. Timer prints "timer" every 2 secs until I pull one of the inputs two ground. It simply stops working.

If I leave out the timer activation before wait, a few interrupts (between three and six regardless of sensor number) are handled correctly, then it also stops working.

My fault or is something wrong with interrupts?

Thanks for your help.

Cheers
Ulli
The light at the end of the tunnel has been switched off for energy saving reasons.
User avatar
cicciocb
Site Admin
Posts: 1900
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 407 times
Been thanked: 1271 times
Contact:

Re: Strange behaviour of interrupts

Post by cicciocb »

Remove the wlog and replace with print.
ulli
Posts: 47
Joined: Tue Feb 09, 2021 9:48 am
Location: Monschau, Germany
Has thanked: 8 times
Been thanked: 2 times

Re: Strange behaviour of interrupts

Post by ulli »

I used wlog because I don't currently have a serial connection. I'll try it tomorrow.

Is there a certain reason why wlog doesn't work well with interrupts?
The light at the end of the tunnel has been switched off for energy saving reasons.
User avatar
cicciocb
Site Admin
Posts: 1900
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 407 times
Been thanked: 1271 times
Contact:

Re: Strange behaviour of interrupts

Post by cicciocb »

The interrupt is very fast and probably generates a lot of wlog messages that saturate the wlog output buffer
User avatar
cicciocb
Site Admin
Posts: 1900
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 407 times
Been thanked: 1271 times
Contact:

Re: Strange behaviour of interrupts

Post by cicciocb »

You could eventually use the UDP with the toolkit as receiver instead of the wlog
ulli
Posts: 47
Joined: Tue Feb 09, 2021 9:48 am
Location: Monschau, Germany
Has thanked: 8 times
Been thanked: 2 times

Re: Strange behaviour of interrupts

Post by ulli »

[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Tue Jun 06, 2023 6:35 pm The interrupt is very fast and probably generates a lot of wlog messages that saturate the wlog output buffer
How can that be? Before I wlog I do a "interrupt SENSORx, OFF".

I don't know how the BASIC command "interrupt" is implemented, but usually further interrupts are masked until the service routine ends. Otherwise you would have the effect I'm seeing with every bouncing push button handled via interrupts.
The light at the end of the tunnel has been switched off for energy saving reasons.
User avatar
cicciocb
Site Admin
Posts: 1900
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 407 times
Been thanked: 1271 times
Contact:

Re: Strange behaviour of interrupts

Post by cicciocb »

The interrupts are handled by SW in Annex (do not really use H/W interrupts).
I suppose that the problem comes from WLOG that is not as fast as the PRINT command
ulli
Posts: 47
Joined: Tue Feb 09, 2021 9:48 am
Location: Monschau, Germany
Has thanked: 8 times
Been thanked: 2 times

Re: Strange behaviour of interrupts

Post by ulli »

[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Wed Jun 07, 2023 9:42 am I suppose that the problem comes from WLOG that is not as fast as the PRINT command
The wlog is only a first check to see if the concept works. In the final version it will not be there anymore. What will be there is a bunch of commands to do the job. They will certainly be much slower than wlog. Am I going to face problems there? If so, can you give me an example of how to trigger things with interrupts. That would be really helpful. Thank you for your help.
The light at the end of the tunnel has been switched off for energy saving reasons.
User avatar
cicciocb
Site Admin
Posts: 1900
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 407 times
Been thanked: 1271 times
Contact:

Re: Strange behaviour of interrupts

Post by cicciocb »

In fact wlog should not be called very very often as it could saturate the output buffer.
Anyway, I think that the problem comes from your code as you are disabling the interrupts for each button after the first action.
In parallel, probably you also miss the pullup resistors; the pin.mode SENSORx, input, pullup should fix the problem except for the pins 34 to 39 (in your example the pins 35 and 36) that require an external resistor (info here : [Local Link Removed for Guests] )

You can see a live example here on the wokwi simulator
https://wokwi.com/projects/366887236363095041

Code: [Local Link Removed for Guests]


'Ports

SENSOR1 = 36  ' requires an external pullup resistor
SENSOR2 = 39  ' requires an external pullup resistor
SENSOR3 = 34  ' requires an external pullup resistor
SENSOR4 = 32
SENSOR5 = 33
SENSOR6 = 25
SENSOR7 = 35  ' requires an external pullup resistor
SENSOR8 = 26

'...

'Sensor init

pin.mode SENSOR1, input, pullup
pin.mode SENSOR2, input, pullup
pin.mode SENSOR3, input, pullup
pin.mode SENSOR4, input, pullup
pin.mode SENSOR5, input, pullup
pin.mode SENSOR6, input, pullup
pin.mode SENSOR7, input, pullup
pin.mode SENSOR8, input, pullup

interrupt SENSOR1, irh1
interrupt SENSOR2, irh2
interrupt SENSOR3, irh3
interrupt SENSOR4, irh4
interrupt SENSOR5, irh5
interrupt SENSOR6, irh6
interrupt SENSOR7, irh7
interrupt SENSOR8, irh8

'...

timer0 2000, ti
wlog "before wait"
wait
wlog "past wait"

irh1:
pause 100 ' wait a little bit to avoid rebounds
if pin(SENSOR1) = 1 then return
wlog "1"

return

irh2:
pause 100 ' wait a little bit to avoid rebounds
if pin(SENSOR2) = 1 then return
wlog "2"
return

irh3:
pause 100 ' wait a little bit to avoid rebounds
if pin(SENSOR3) = 1 then return
wlog "3"
return

irh4:
pause 100 ' wait a little bit to avoid rebounds
if pin(SENSOR4) = 1 then return
wlog "4"
return

irh5:
pause 100 ' wait a little bit to avoid rebounds
if pin(SENSOR5) = 1 then return
wlog "5"
return

irh6:
pause 100 ' wait a little bit to avoid rebounds
if pin(SENSOR6) = 1 then return
wlog "6"
return

irh7:
pause 100 ' wait a little bit to avoid rebounds
if pin(SENSOR7) = 1 then return
wlog "7"
return

irh8:
pause 100 ' wait a little bit to avoid rebounds
if pin(SENSOR8) = 1 then return
wlog "8"
return

ti:
wlog "timer"
return

end
ulli
Posts: 47
Joined: Tue Feb 09, 2021 9:48 am
Location: Monschau, Germany
Has thanked: 8 times
Been thanked: 2 times

Re: Strange behaviour of interrupts

Post by ulli »

There are 2k7 pullups on all input pins, so the internal ones are not needed. The trigger pulse comes from this circuit:

Lokdetektor_klein.jpg

It's basically a Schmitt trigger with a huge hysteresis and is triggered whenever a locomotive of my model railroad with a white spot underneath comes across. According to my oscilloscope there are no bursts, just clean pretty long level changes to low when a loco is detected.
Discharge is an open collector output, the pullups are against 3.3V, so no 10V danger.

There can be more bright spots under the train, which I want to ignore. Therefore I disable further interrupts from this source. The interrupt will be switched on again at a later stage, when the train has completely passed a while ago.

I tested this with a simple button, not the Schmitt trigger, which might be the source for this trouble.
You do not have the required permissions to view the files attached to this post.
The light at the end of the tunnel has been switched off for energy saving reasons.
Post Reply