-
|
Would like to make my pc hardware in a plexiglass case with rgb fans. So am tinkering with a m5stick c plus with the fanset. Now i uploaded it with the webinstaller. That's going well until I connect to wifi. Once the m5stick gets an ip address the m5stick reboots. Could it be that dave devised this sketch so that no wifi is needed. And that is why the m5stick gets stressed out? Of course, I also uploaded the m5stick with platformio. Same story. If I turn off wifi, it goes fine. And it boots up and I can scroll through the effects with the remote or the button on the m5stick. Would be nice if wifi did work, and you could use the web server to scroll through the effects. But don't know if this is also possible with the fanset sketch? Another question to dave, the m5stick is (if I understand by some notes in the global sketch for the microphone) built into the pc cabinet. So how do you turn off the m5stick? Normally it turns off after holding down the power button for so many seconds. Am also tinkering with an esp32 devkit with a separate lcd screen. I already have this one running with the fanset sketch. I can just power this with the voltage from the pc power supply. And then as soon as I turn the pc off, the esp turns off as well. But am curious how dave powers off the m5stick. Because when I take mine off the power, it stays on until i press the button for a couple of secconds. Harrie Just tried to dissable the webserver and enable the wifi, now it does not reboot. So if i enable webserver, the m5stick keeps rebooting. |
Beta Was this translation helpful? Give feedback.
Replies: 8 comments 25 replies
-
|
@heidepiek The only way to get any meaningful indication of why the M5StickC Plus reboots is by looking at the debug logging; you could even do this in the Web Installer. My unconfirmed "educated guess" would be that the web server takes up too much memory while it tries to start, and causes a panic in the process. We recently disabled some stuff in the M5StickC Plus Spectrum project because it ran out of memory while trying to start the web server also. (That didn't actually reboot the device, but still.) But again, looking at the debug messages is the only way to be sure. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry guys, too quick to judge. Turned on the m5stick c plus again tonight. And immediately rebooted again. And in that loop the m5stick stays! Can upload it again, but after switching effects a few times reboot again. Really a memory problem as rutger said! Really unfortunate, is such a nice project. Maybe the software guys can do something about it. |
Beta Was this translation helpful? Give feedback.
-
|
@heidepiek I'll have to pull out one of my own M5StickC Plus-es and start testing with FANSET myself. For one, the logging you got from the monitor lacks a readable stack trace (I need some help converting the memory addresses to file names and line numbers. :) ) Considering work and other commitments, I expect it to be the weekend before I get round to that. I'll report back here when I've had a chance to look at things on my "workbench". |
Beta Was this translation helpful? Give feedback.
-
|
Trying to rutger, but don |
Beta Was this translation helpful? Give feedback.
-
|
�[0m(W) (NotifyJSONWriterThread)(C1) >> Notifying JSON Writer Thread Core 0 register dump: Backtrace: 0x401b18e8:0x3ffe5160 0x40128f25:0x3ffe5190 0x40128fcf:0x3ffe51d0 0x4012c46b:0x3ffe51f0 0x4012c529:0x3ffe5210 0x401249c1:0x3ffe5230 Is this of any use to you rutger? |
Beta Was this translation helpful? Give feedback.
-
|
No, the gibberish after "Backtrace: " is a list of memory addresses that correspond to the source code of the image that's flashed onto your M5StickC Plus. I need to know what source code files and line numbers within those files those addresses correspond to. The comment you just added in response to a comment Dave wrote does include this information, and that's already insightful. |
Beta Was this translation helpful? Give feedback.
-
|
Try setting MAX_BUFFERS to 5 and see if that helps. Lower NUM_LEDS to a smaller number for testing if possible. If this fixes it, it's most certainly running low on memory. FWIW I'm using the M5 today on a project and had to turn off the webserver to get enough memory (but I'm trying for 28 buffers, which is a lot of memory). Robert was going to debug this after Christmas, I think, to see what's up. For now, mine seems pretty stable when it has 60K free when running. |
Beta Was this translation helpful? Give feedback.
-
|
BTW, I don't know what the NUM_LEDS is for FANSET, but I presume it'll be much shorter than the 144*8 max that might be the default. So if you've only got 300 LEDs to work with, make sure you adjust it down to that. |
Beta Was this translation helpful? Give feedback.
-
|
Started with a clean slate, had been changing so many times in the sketch. Now have this in the globals.h: #elif FANSET Don't have extra bonus pixels, 1 led ring with 64 leds. Executing task: C:\Users\Eigenaar.platformio\penv\Scripts\platformio.exe device monitor --port COM16 Please build project in debug configuration to get more details about an exception. --- Terminal on COM16 | 115200 8-N-1
assert failed: bool StarryNightEffect::SerializeToJSON(ArduinoJson::V6214PB2::JsonObject&) [with StarType = MusicStar] stareffect.h:485 (!jsonDoc.overflowed()) Backtrace: 0x40085279:0x3ffda130 0x40090749:0x3ffda150 0x40096215:0x3ffda170 0x400e040d:0x3ffda2a0 0x400da15b:0x3ffda320 0x401d62b7:0x3ffda350 0x400e5200:0x3ffda370 0x400e5f2f:0x3ffda3a0 0x400d8bfe:0x3ffda400 0x40081fd1:0x3ffda440 #0 0x40085279:0x3ffda130 in panic_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/panic.c:408 ELF file SHA256: 0b13f5090564053a E (5690) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0
abort() was called at PC 0x40194b9d on core 1 Backtrace: 0x40085279:0x3ffddb00 0x40090749:0x3ffddb20 0x4009610d:0x3ffddb40 0x40194b9d:0x3ffddbc0 0x40194bfe:0x3ffddbe0 0x40194b3f:0x3ffddc00 0x40194fde:0x3ffddc20 0x400e3bd0:0x3ffddc40 0x400dd08f:0x3ffddcb0 0x400d854d:0x3ffddcf0 0x400d8631:0x3ffddd10 0x40081e37:0x3ffddd30 #0 0x40085279:0x3ffddb00 in panic_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/panic.c:408 ELF file SHA256: 0b13f5090564053a E (5721) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0
If I change effects too quickly or too often it reboots again. But now it starts up again. But it is not very stable. |
Beta Was this translation helpful? Give feedback.
-
|
That's interesting. This logging shows two entirely different reasons for rebooting. The first one shows that the buffer allocated for the JSON serialization of a Like I said, I'll have to look into this using my hardware when I have the time to do so. |
Beta Was this translation helpful? Give feedback.
-
|
Know you are busy rutger, (too few hours in a day and too many commitments) you have a few requests completed. Including the m5stick c plus spectrum. I uploaded that again today on my m5 as well. Works properly! The mesmerizer also has three new animations! But am curious if you also looked at the fanset? I also tested this one again today after a fresh download of the code. But still reboots when I log it in with wifi. Maybe wait and see, dave said robert would look at it after Christmas. It's so time consuming too! Wish I could help with the software, sometimes sit here for hours tinkering to get the fanset working on an esp32 s3 for example. But keep getting error messages, and yet it should be possible! Other people here in the discussions get it done too. But this dummy can't! greetz harrie |
Beta Was this translation helpful? Give feedback.
-
|
@heidepiek No, I haven't properly looked at Fanset yet. The reason is that I am almost 100% certain it's a low memory situation that's causing the crashes, which means it's a matter of finding out which set of services (web server, socket server, IR remote control handler, ...) can still run with how many buffers without overloading the on-board RAM. That's an iterative process with longer testing times (the M5Stick needs to run at least one full effect cycle without crashing before it's safe to say we're probably good), which I indeed haven't had the time for yet. Other things take less time to review or test, which means I have been able to squeeze those things into the schedule. You have my pinky promise that I will look at Fanset when I have the time.
Haha, I'll take that as a compliment! I am a pro at something, but when it comes to this I'd say that I'm a somewhat educated amateur. :)
Happy holidays to you too, and "een goed uiteinde"! |
Beta Was this translation helpful? Give feedback.
-
|
@heidepiek So, I looked into this now and the long and short of it is that it's just not possible to run the web server on Fanset. With all other servers (socket, color data, audio serial, ...) disabled there's 47K of RAM left, with the reported biggest block being 31K. That's just not enough to start the webserver successfully. I'll open a PR to update the Fanset configuration to not attempt to start the webserver, but has the IR remote and the socket server enabled. That does seem to address the reboots on WiFi connect, at least. |
Beta Was this translation helpful? Give feedback.
-
|
Is it possible to convert the fanset configuration from a m5stick to for example an esp s3 with more ram? So that it wil run with webserver enabled. |
Beta Was this translation helpful? Give feedback.
-
|
Not without changing the hardware you have to buy to make it run. :) Fanset is one of Dave's original projects, which means he's running the configuration on an M5StickC Plus in his actual PC (the one you see in the videos). I'm not going to pull the M5StickC Plus away from underneath him if that's what he's using. We could add additional Fanset configurations on other devices, but I'm not going to do that blindly, i.e. untested. I don't have the ability or the inclination to test that myself, which means someone else will have to dedicate the hardware (ESP board, fans/LEDs, etc.) and the time/energy to figure out the exact configuration (platformio.ini and globals.h) to use to actually get Fanset running with the webserver on a different board - and see with their own eyes that the final result indeed works and is stable. |
Beta Was this translation helpful? Give feedback.
-
|
So I forgot one very obvious thing: reducing MAX_BUFFERS to the low-memory "default" value of 5. With that done, I am able to start Fanset with the web server enabled. I'll leave it running during the night to be sure it's stable, but already opened #573 to update the FANSET project configuration. |
Beta Was this translation helpful? Give feedback.
-
|
We were dealing with two problems at the same time, which makes debugging a bigger challenge than usual. I've now discovered what both problems were/are:
|
Beta Was this translation helpful? Give feedback.
-
|
Haha, wow, talk about barking up the wrong tree. There was a bug in I've uploaded the proper fix to my M5StickC Plus just now and pushed an update to my staging branch - which should end up in the staging web installer in an hour, as before. @heidepiek I'll let you know when I think it makes sense for you to retest with my updates on your M5StickC Plus. |
Beta Was this translation helpful? Give feedback.
-
|
Know you didn't notify me of the benefit of testing your staging branch. But am doing some tinkering myself here. With these settings I have a fanset that I can tease by changing the effect every two seconds, but remains stable! in effects.cpp #elif FANSET en in Fanneffects.h { But if I uncomment starry night effect again (5x starry night) Then I have a faneffect that reboots every time near little blooming rainbow So with this settings: in effects.cpp #elif FANSET and in faneffects.h { I get this in the serial: --- Terminal on COM16 | 115200 8-N-1
abort() was called at PC 0x40194ccd on core 1 Backtrace: 0x400852e9:0x3ffddc60 0x400907b9:0x3ffddc80 0x4009617d:0x3ffddca0 0x40194ccd:0x3ffddd20 0x40194d2e:0x3ffddd40 0x40194c6f:0x3ffddd60 0x4019510e:0x3ffddd80 0x400e3864:0x3ffddda0 0x400dd0b7:0x3ffdde10 0x400d8509:0x3ffdde50 0x400d85ed:0x3ffdde70 0x40081e3f:0x3ffdde90 #0 0x400852e9:0x3ffddc60 in panic_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/panic.c:408 ELF file SHA256: 2a259c138231b04d E (6360) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0
abort() was called at PC 0x40194ccd on core 1 Backtrace: 0x400852e9:0x3ffddc60 0x400907b9:0x3ffddc80 0x4009617d:0x3ffddca0 0x40194ccd:0x3ffddd20 0x40194d2e:0x3ffddd40 0x40194c6f:0x3ffddd60 0x4019510e:0x3ffddd80 0x400e3864:0x3ffddda0 0x400dd0b7:0x3ffdde10 0x400d8509:0x3ffdde50 0x400d85ed:0x3ffdde70 0x40081e3f:0x3ffdde90 #0 0x400852e9:0x3ffddc60 in panic_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/panic.c:408 ELF file SHA256: 2a259c138231b04d E (9095) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0
At little blooming rainbow stars it keeps rebooting greetz harrie |
Beta Was this translation helpful? Give feedback.
-
|
Final result: Fanset on the M5StickC Plus is stable... but we lost not only the webserver, but all networking. The reason is that a number of dependencies - including the Espressif base framework - recently received updates. They stuck to their pattern of chewing up more memory than in the previous releases. In this case it's another ~30K of memory that evaporated, which was enough to once again make the M5StickC Plus start crashing due to out-of-memory conditions (look for "bad_alloc" in the logging - it's a dead give-away). Even disabling the webserver wasn't enough to compensate for it, this time. So, where we are is that we now have 150K RAM free when Fanset has been running for a while, but no other means to communicate with the M5StickC Plus than the serial port or the IR remote control - provided you've hooked up an IR receiver module to it. I'm quite sure it's possible to pin some dependencies to earlier versions that are less memory-hungry for the M5Stick projects, but figuring that out is an exercise I'll leave to someone else. It would most likely be a temporary workaround as well. I say that because it's almost inevitable that at some point we will use something that's only available in the then-current versions of the dependencies. So, I think in this project we're reaching the practical EOL for devices that have as little memory as the M5Sticks do. I'm going to check now what happens with the Spectrum project - I can only assume that's also unstable with current dependency versions. I'll update the PR accordingly and merge it when ready. @heidepiek You can try flashing your M5SStickC Plus with Fanset in about an hour (noon our time) using the web installer at this location: https://rbergen.github.io/NightDriverStrip. |
Beta Was this translation helpful? Give feedback.
-
If you search the logs you posted you'll find the |
Beta Was this translation helpful? Give feedback.
-
|
They stuck to their pattern of chewing up more memory than in the previous
releases.
They're not unique in this regard. On any given week, we add more code than
we remove ourselves.
again make the M5StickC Plus start crashing due to out-of-memory
Is m5stick unique in some way, or is this really "anything without PSRAM
that has a non-trivial effects configuration"?
I'm going to check now what happens with the Spectrum project - I can only
assume that's also unstable with current dependency versions. I'll update
the PR accordingly and merge it when ready.
The spectrum effects aren't skimpy on memory and mapping 768px isn't cheap.
On the same board, I'd expect a violent death. On a board with PSRAM, it's
likely happy; I ran rainbox with 2kpx on one data line not long ago. (Yes,
I understand but refresh limits. I didn't care for the task at hand.)
@heidepiek <https://github.com/heidepiek> You can try flashing your
M5SStickC Plus with Fanset in about an hour (noon our time) using the web
installer at
I just confirmed. StickCPlus has no PSRAM.
If we're unable to use the screen and/or the buttons anyway, what if you
just treat it like a base dev_esp32 device? I see it builds and links magic
libraries:
build_flags = -DUSE_SCREEN=1
-DM5STICKC=1
${base.build_flags}
lib_deps = ${base.lib_deps}
m5stack/M5StickC @ ^0.2.3
Try testing with
build_flags = -DM5STICKC=1
${base.build_flags}
lib_deps = ${base.lib_deps}
Maybe we have something like screen requesting buffers for the SPI (i2c?)
that we aren't even using.
I know, this makes your fancy $20 board into a dumb $5 board, but maybe we
can at least get a few more quarters out of it for you.
I'm not one to hold onto platforms after they're expired (i have no pity on
the guys trying to do 2,000 WS2812's on an 8266 and wondering why it flips
out during network I/O) but this still passes the approximate "seems like
it SHOULD work" test. 512MB and two 240Mhz 32-bit cores should be enough to
blink some lights.
I think we DO need to have some kind of a defined floor of "you NEED PSRAM
(I think that comes no smaller than 2MB on these)" that gives us some
breathing room so that every monthly PIO update isn't a death watch but it
also IS on my list to dig deeply into this. Maybe we have something dumb
fragmenting memory, or something that's not allowing adjacent block
reclamation (https://www.freertos.org/a00111.html) for example.
So I'm playing both sides of the fence:
1) We need a plan for some configurations to just not work.
2) Once we've reached our steady state, 50K of free RAM should be "enough".
(Boards where we don't have 50K? See #1)
My instinct says we have something weird and I plan to dig deeply into in
and take some steps to quantify our uses and needs. We may not be able to
do anything tangible about it, but at least we'll have charts and reasons.
Message ID:
… <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/562/comments/7937257
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
I was observing, not accusing - but I understand it may have come across that way.
The latter. And to be fair to ourselves, we haven't recently added much (any?) code to the FANSET and SPECTRUM scenarios. For these, it mainly is the slow-ish but steady increase in memory use by the dependencies that has pushed us under the ~50K free RAM threshold that seems to be where things fall apart.
Exactly. I recently disabled everything except WiFi and the webserver to keep it afloat, but I seriously doubt that will be enough now. On the other hand, Spectrum lines up 12 effects and Fanset 26(!). Which means I'll just have to test and see.
The screen and buttons do work. To the comment that there are "no other ways left to interact than serial and IR" I should have added "without touching the device". I apologize for the omission and confusion caused.
I agree. And we can, but from more or less now onwards without network connectivity - unless we find and fix places where we leak memory we can better use elsewhere, and/or figure out what the deal is with issue #565.
I would greatly appreciate that. That type of low-level analysis I'm not that good at, nor do I enjoy it much (yes, there may well be a circular reference between those two things.)
That would already be very useful in itself, and worth the effort in my humble opinion. |
Beta Was this translation helpful? Give feedback.
-
|
I just checked memory usage on a locally built Spectrum project. With MIN_BUFFERS and MAX_BUFFERS both set to 1 and WiFi, IR remote and the webserver enabled the M5StickC Plus seems to be running stable with free RAM hovering around 67K. I'll push my changes and test again with a Spectrum image flashed using the staging web installer. |
Beta Was this translation helpful? Give feedback.
-
|
Just flashed Spectrum with the staging Web Installer. Memory patterns are identical to what I mentioned. I'm trying a couple of more things with the Web Installer itself and I'll merge #573 when I'm ready with that. |
Beta Was this translation helpful? Give feedback.
-
|
so I had to buy the m5 stickc plus 1.1 then I connect it to blueto and my pc but on the m5 it doesn't appear that it's connected then I connect the usb to the pc but it doesn't appear that something is connected to the pc then I can't do it I can't even connect to the M5's WiFi and it doesn't appear that the M5 is connected to the USB on the PC. Can anyone help me? |
Beta Was this translation helpful? Give feedback.
-
|
After looking into the low memory situations we were seeing in various configurations - credits for the actual work relating to that go to @davepl - it seems we have a new situation when all dependencies are updated to their current versions using I have pushed a commit to my staging branch to update the staging Web Installer with the webserver-enabled Fanset configuration. @heidepiek Could you maybe try flashing Fanset using the staging Web Installer to confirm things work again for you as well? It's available here: https://rbergen.github.io/NightDriverStrip. |
Beta Was this translation helpful? Give feedback.
-
|
Don't know what you wizards have done!👌 But fanset runs like a charm now! Kudo`s for dave💪 . And probably some other bright minds too🤘 . This dummy can only test🙈 . Mighty fine project that nightdriver strip! Best wishes for this new year guys. Hope we stay a little healthy and can keep tinkering. Thanks guys |
Beta Was this translation helpful? Give feedback.
-
|
We actually didn't do anything wizardy yet - we just updated the project dependencies to their latest versions. We lost several tens of kilobytes of RAM to dependency updates in the past few months, and it seems we got a lot of that back with updates that took place in the past couple of days. I did say no wizardry was done "yet" because @davepl managed to clear up another ~25K of RAM (on Mesmerizer at least) during an investigation of memory use that was triggered by the low-memory conditions we were seeing. Those changes should reach the main tree within the next few days and should give us a little more memory breathing room still. |
Beta Was this translation helpful? Give feedback.
We actually didn't do anything wizardy yet - we just updated the project dependencies to their latest versions. We lost several tens of kilobytes of RAM to dependency updates in the past few months, and it seems we got a lot of that back with updates that took place in the past couple of days.
I did say no wizardry was done "yet" because @davepl managed to clear up another ~25K of RAM (on Mesmerizer at least) during an investigation of memory use that was triggered by the low-memory conditions we were seeing. Those changes should reach the main tree within the next few days and should give us a little more memory breathing room still.