gpio_isr_handler_remove(480)

Recurrent H/W and software problems
Post Reply
User avatar
Electroguard
Posts: 945
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 310 times
Been thanked: 352 times

gpio_isr_handler_remove(480)

Post by Electroguard »

Any idea what could cause the high-lighted gpio error from the Online Flasher, Francesco ?

I've tried re-flashing the 16Mb S3 Uno clone several times with the latest firmware, and also with previous versions, but get the same error every time.
Everything works ok on the device, except the interrupts do not work.
So I tried re-flashing a similar device to use instead, but that also comes up with the same error.
I definitely have other similar devices whose interrupts do work ok, and with the same script and hardware, (this was an exact replica of a working prototype which has been going perfectly for a couple of weeks).

These 2 which fail seem to initially flash ok, but then the firmware seems to check something which then causes it to remove the gpio isr handler for some reason (twice).
Any ideas what might make it do that ?

gpio_isr_handler_remove(480).jpg
You do not have the required permissions to view the files attached to this post.
User avatar
cicciocb
Site Admin
Posts: 2194
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 470 times
Been thanked: 1461 times
Contact:

Re: gpio_isr_handler_remove(480)

Post by cicciocb »

This message is not really an error (is more a warning) and exists since when I changed the way the interrupts are managed.
Briefly the message says that the Interrupt handler has been requested to be removed but it was not installed previously.
It appears only at the first run of the program and do not happens anymore.
I'll try to remove this message in the future.
Anyway, this should not have any impact on the interrupts.

Can you give me more details on the pin and how you are managing the interrupt ?
Maybe there is a snag to fix.

This shou
User avatar
Electroguard
Posts: 945
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 310 times
Been thanked: 352 times

Re: gpio_isr_handler_remove(480)

Post by Electroguard »

It is basically the same as the script I posted in the PIR + Radar project [Local Link Removed for Guests]
They use Radar on D7 (14) and PIR on D6 (3).
I have had a similar 'test' PIR+Radar N16R8 S3 Uno running 24/7 (or 24/24 as shown at French services) faultlessly sending interrupt changes via EspNow to a monitoring receiver.
The sender and receivers use the same basic script but with different flag settings which selects the appropriate functionality...

Code: [Local Link Removed for Guests]

if pir=1 then
  pirled = 1
  pirpin = d6
  pin.mode pirpin, input, pullup
  interrupt pirpin, pirtrigger
endif

if radar=1 then
  radarled = 1
  radarpin = d7
  pin.mode radarpin, input, pulldown
  interrupt radarpin, radartrigger
endif
It was evolved into the replacement gate Sentry shown in the project pic.
But then I needed to temporarily disable the Radar sensor cos it kept doing weird things, which I thought might be due to the radar being housed in the ext PIR case.
So I disconnected the ext radar and plugged a different one directly on the uno proto shield, but that also misbehaved.
So I disabled the radar again in order to keep the PIR working ok, until I had opportunity to build a replacement proto shield.
Then I tested the replacement pir+radar shield locally on a different s3 n16r8 to ensure it worked properly... but it didn't, so I spent several days swapping out sensors and hacking at the code trying to get even just 1 sensor to work, but without success.
Everything else worked, except for changing state of a sensor which never triggered an interrupt.
That was when I decided to re-flash the firmware, then noticed the two gpio_isr_handler_remove(480) messages.
I assumed it must be a hardware fault, so re-flashed another s3 n16r8 to use, then noticed it too showed the same two gpio_isr_handler_remove(480) messages.
That caused me to post the question on the forum.

So in vague hindsight, I think I have one or two S3 n16r8 uno clones whose interrupts have been working correctly, and three that have been giving sensor problems even though the sensors all tested ok on other devices.

I am out today, but eventually I will focus on the behavioural differences of the various s3 n16r8's rather than the sensors, and try to pinpoint what the problem devices may have in common.
User avatar
cicciocb
Site Admin
Posts: 2194
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 470 times
Been thanked: 1461 times
Contact:

Re: gpio_isr_handler_remove(480)

Post by cicciocb »

Robin,
don't care, I'll check the interrupts later tonight and I'll confirm is working or not
User avatar
Electroguard
Posts: 945
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 310 times
Been thanked: 352 times

Re: gpio_isr_handler_remove(480)

Post by Electroguard »

Originally I had a gate1TX sender being received by a gate1RX receiver, but the sender was only sensing PIR interrupts correctly.
So the plan was to duplicate a gate2TX sender and gate2RX receiver pair, then after they were debugged and working properly, to duplicate them back to the faulty gate1 pair.
I did the gate2RX first cos it could be tested with triggers from the gate1TX sender without interference, other than adding its MAC for EspNow.
Then did the gate2TX sender, but couldn't get it to locally read its sensors.

Diagnostic update:
Tonight I swapped the gate2TX to be the receiver, and the gate2RX to be the sender ... literally copying the scripts from one to the other, and moving the sensor shield.
And to my surprise, both the devices are now working correctly in their new roles.
There are no obvious differences, they are both S3 N16R8's using Annex32-S3 CAN DMT VGA HID 1.53.7 qio opi LFS, so the only logical explanation I can think of why sensor interrupts are ok on one device but not on the other, is that maybe the internal pin timings are slightly different, causing one to fail some fast initial pin confirmation tests which the other passes.

Anyway, I am pleased to report that I now have a local working sender and receiver pair, which I can now progress from.
Post Reply