Closed pjsg closed 2 months ago
I have tested the module and noticed a strange behavior. If a large amount of information is printed inside the callback function, the ESP restarts, or the rotary module freezes. If output message is short, the module works fine.
-- Test script
local CLK = 5 -- pin a
local DT = 18 -- pin b
local SW = 19 -- 'NO' pushbutton switch
local eventNumber = 0
local eventType = {
[1] = "PRESS",
[2] = "LONGPRESS",
[4] = "RELEASE",
[8] = "TURN",
[16] = "CLICK",
[32] = "DBLCLICK",
[63] = "ALL"
}
local sw = rotary.setup(CLK, DT, SW)
sw:on(rotary.ALL, function(type, pos, when)
-- print(eventType[type]) -- no restart
-- print(eventType[type], eventNumber) -- restarts after ~150 - 200 events
print("All Events. Position=" .. pos .. " event type=" .. eventType[type] .. " time=" .. when) -- restarts after ~20-50 events
eventNumber = eventNumber + 1
end)
*****
Sometimes the module stops processing events,
but the ESP responds to commands
EXCVADDR: 0x00000003
That's effectively a null pointer dereference crash. Probably into the second element of a struct with a 32bit first element.
If you use idf.py monitor
you'll probably get that stack backtrace decoded and the offending function pinpointed.
What is interesting is that something is reconfiguring the GPIO just before the final print. I wonder if you try and initialize the rotary module twice on the same set of gpios, then maybe it dies. I'm away from my dev environment at the moment, but I'll definitely try this when I get back to it. Thanks for trying this....
On Thu, Feb 8, 2024 at 4:47 PM J Mattsson @.***> wrote:
EXCVADDR: 0x00000003 That's effectively a null pointer dereference crash. Probably into the second element of a struct with a 32bit first element.
If you use idf.py monitor you'll probably get that stack backtrace decoded and the offending function pinpointed.
— Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/pull/3625#issuecomment-1935158380, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTKILQTZDB6XHYOIUSTYSVW3JAVCNFSM6AAAAABCXTWHCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZVGE2TQMZYGA . You are receiving this because you authored the thread.Message ID: @.***>
Second calling rotary.setup() causes the module to hang.
I found the issue. If rotary object is global the module works fine. local sw = rotary.setup() causes rebooting after a few events. I ran module under debugger. Result is:
Ok. It is something in the GC that is causing the problem. I can definitely take a look at that
On Sun, Feb 11, 2024, 07:33 serg3295 @.***> wrote:
I found the issue. If rotary object is global the module works fine. local sw = rotary.setup() causes rebooting after a few events. I ran module under debugger. Result is: Screenshot
11-02-24_18-24.png (view on web) https://github.com/nodemcu/nodemcu-firmware/assets/75196080/788fadf0-b6d3-4377-b3f9-005eeb004efe
— Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/pull/3625#issuecomment-1937786862, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTKPRABCKX7Z5QDJRL3YTDQDTAVCNFSM6AAAAABCXTWHCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXG44DMOBWGI . You are receiving this because you authored the thread.Message ID: @.***>
Sorry for the delay. This should be fixed now. Now, if you lose access to the switch object it will continue to work. If you want to get rid of the object entirely, you have to :close
it first and then lose access to it.
I have tested the latest version of module. It works fine now. Thank you.
Fixes #3624
dev-esp32
branch rather than for therelease
branch.docs/*
.This is a pretty straight port of the module from the esp8266 version. I did make it object oriented.