Port of the rotary module to ESP32 #3625
Conversation
|
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. -- 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)Log_1:node.restart() rst:0xc (SW_CPU_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT) I (824) wifi:wifi driver task: 3ffc7ef4, prio:23, stack:6656, core=0 NodeMCU ESP32 build unspecified powered by Lua 5.3.5 [5.3-int32-doublefp] on IDF v5.0.2 I (41424) gpio: GPIO[5]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:3 Core 0 register dump: Backtrace: 0x4018c826:0x3ffbb770 0x400dd630:0x3ffbb790 0x400f8585:0x3ffbb7c0 0x400d7a67:0x3ffbb7f0 0x4019252b:0x3ffbb810 ELF file SHA256: 9b716118424d3445 Rebooting... Sometimes the module stops processing events, but the ESP responds to commands Log2:All Events. Position=0 event type=PRESS time=5273872 |
|
If you use |
|
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
<#3625 (comment)>,
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. Log 3:NodeMCU ESP32 build unspecified powered by Lua 5.3.5 [5.3-int32-doublefp] on IDF v5.0.2 COMMENT: The module is not responding to events at this moment =node.heap() |
|
I found the issue. If rotary object is global the module works fine. Screenshot
|
|
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
<#3625 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALQLTKPRABCKX7Z5QDJRL3YTDQDTAVCNFSM6AAAAABCXTWHCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXG44DMOBWGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
…lled and any queued messages have been flushed.
|
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 |
|
I have tested the latest version of module. It works fine now. |
Fixes #3624
dev-esp32branch rather than for thereleasebranch.docs/*.This is a pretty straight port of the module from the esp8266 version. I did make it object oriented.