TM1814 lights revert back to cycling colors

[rjmcfadd]

What happened?

I made a new power supply for my outdoor string lights that use 12v TM1814 leds using a outdoor rated 12V power supply and a QuinLED-Dig-Uno as the controller. Everything is working great for a while but then I loose connection to WLED and the lights revert back to the TM1814 default of cycling colors. When it’s connected I have a good WiFi connection. I’ll have it working for a couple of hours then when I wake up in the morning the colors are cycling and WLED is offline.

To Reproduce Bug

Just wait for it to happen again. It seems random when it happens. The lights will either be on or off at the time when the colors start cycling.

Expected Behavior

WLED to stay connected and controlling these lights.

Install Method

Binary from WLED.me

What version of WLED?

WLED v0.13.0-b6 2112080

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

No response

Anything else?

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[rjmcfadd]

I've noticed that it is happening even when not attached to the lights. When TM1814 is selected as the type of LED, eventually WLED goes down and doesn't start back up. It requires a power cycle to reconnect.

I switched the output to WS281x (without the lights attached) and WLED stays connected. Now it stays connected.

I have 6 other WLED controllers, all WS281x, that have no issues. I've had this issue with TM1814 selected on 3 different ESP8266s, 2 ESP32s, and the QuinLED-ESP32 that comes with the QuinLED-Dig-Uno. I thought it was the specific controller I was using so I kept trying new ones.

[boiler54]

I just setup a new system with a string of TM1814 and I'm seeing the EXACT same issues. Running 0.13.1 on ESP32. Power supply is clean and strong and works fine on WS281x lights. It will work fine for awhile and will randomly crash with WLED frozen, webpage not accessible and requires a power cycle to get it back. When this happens the lights go into their default cycle. It seems to crash much more frequently if segments are defined.

[rjmcfadd]

@boiler54 I fixed mine by switching to GPIO3. After doing that, it has been working great!

Are you using a QuinLED-Dig-Uno or just an ESP32?

[boiler54]

@rjmcfadd I will try switching pins to see if that helps, thanks. I'm using a bare ESP32 with level shifters on the data lines.

[rjmcfadd]

In case you run into another issue I had where the lights would start flashing when they were off. Since my cable from the controller to the LEDs was fairly long, I replaced the 249 ohm resistor on the data line with a 33 ohm resistor which completely fixed that issue.

[boiler54]

@rjmcfadd unfortunately I tried switching to GPIO3 and it locked up again after about 5 minutes. I'm going to try another new power supply tonight and meter some voltages just to triple check. Can you think of any other settings you may have changed that improved this? What code version are you running? Thanks.

[blazoncek]

TM1814 revert to demo mode if there is no data on data line. WLED implemented such "refresh" sometime after 0.12.0 was released and since 0.13 it allows to manually enforce "off refresh" in LED settings.

If you are seeing crashes when used with TM1814 LEDs (which enforces "off refresh") please compile source with debug enabled and monitor serial output to catch exact crash log. Once you have it post it here. Best GPIOs to use on ESP8266 or ESP32 are laid out in knowledge base.

[boiler54]

Thanks for the info @blazoncek. It appears I had a bad/intermittent ESP32 board which was brand new. I swapped the board for a different one with the same lights, code version, power supply and GPIO and it works fine. Rock solid.

[dfparent]

There seems to still be some bug in the latest version of WLED that effects the TM1814.

When I use version 0.13.0-b4 it works great. Some effects have the data refresh problem, but most do not.

When I upgraded to 0.13.3, it no longer works correctly. Using an effect that works great on 0.13.0-b4, that same effect has the refresh problem on 0.13.3 i.e. it regularly switches into its demo mode and then back into the proper WLED effect repeatedly every few seconds or so. I tried saving the config from 0.13.0-b4 and restored that onto 0.13.3 and it did not help. When I downgrade back to 0.13.0-b4 things work again.

Hoping someone can shed light on what changed after 0.13.0-b4 that is causing this.

[Aircoookie]

@dfparent what effect(s) specifically does this happen with? It might be that the 3 FPS target for Solid is just on edge and bumping that to 4-5 could fix it.

[dfparent]

@Aircoookie I tried a handful of effects with 0.13.3 and the problem happened with every one of them. The effects I tried were:

• Dynamic
• Candy Cane
• Chase
• Solid
• Chunchun
• Lighthouse
• Saw

I can try them all if you need.

Conversely, the ONLY effect that I have noticed exhibiting the problem on 0.13.0 is ICU. I verified that all the above effects work fine on 0.13.0.

[blazoncek]

Can you test 0.14 version as it has some modifications in LED driver code?

Warning, it is still in beta phase and features of functions may change or not work.

[dfparent]

@blazoncek I built version 0.14.0 from source and ran it. It exhibits the same problem with the TM1814 that I am seeing in version 0.13.3.

[blazoncek]

Can you find the commit where it stopped working?

[dfparent]

Version 0.13.0-b7 introduced the bug. The bug does not exhibit in 0.13.0-b6.

Note: I used WLED_0.13.0-b7_ESP32.bin using OTA install.

[blazoncek]

I need a commit. I reviewed the code but I cannot find the issue logically. Refreshing seems in order.

[blazoncek]

I have reviewed most of the commits between b6 and b7 release. There were 3 that touched bus handling directly (#2444, #2463 and 97f8eea) but none of them seem to cause refresh to misbehave. There was a change in ESP core which may affect many things but that is out of WLED scope.

@dfparent please find the exact commit that causes TM1814 to misbehave or send a sample strip for testing.

[dfparent]

Will do. It may be a few days before I can get back, though.

[dfparent]

Having some difficulty with this task. I am using GIT Desktop to grab the source code for a particular commit. I am currently using VSCode with PlatformIO according to the instruction given. I have tried building esp32_dev for a number of different commits, but they are all failing. I appears that it can't find "vfs_api.h". Any ideas what I am missing? Are there dependencies that I'm supposed to get that are not in the WLED code base?

[blazoncek]

remove .pio folder and verify your platform is installed correctly. This is a PIO issue.

[dfparent]

So it turns out it was a bug in LITTLEFS which I could get past by adding a third parameter to the open command. Now that I am past that I am getting other bugs in arduinoespressif

.platformio/packages/framework-arduinoespressif32@src-fbe5021e7ea7f03467af534cfd3a479b/tools/sdk/esp32/include/hal/include/hal/i2s_types.h:87:31: error: expected ',' or '}' before 'attribute'

When I run a build with the newer version of platformio.ini, everything compiles correctly. When i use the newer platformio.ini with the older source, everything compiles correctly, but the LEDs don't light up at all.

Something wierd happened somewhere it seems that has broken the builds for the older platformio.ini. Either that or there are steps I am supposed to take that are not documented in the wiki.

Either case, I appreciate the help, but I am beyond my depth at this point with this platform. My guess is that the change in the dependencies is causing the problem. So I would bet it is not a change that WAS made, but one that was NOT made. Just a guess.

[softhack007]

So it turns out it was a bug in LITTLEFS which I could get past by adding a third parameter to the open command.

Are you trying to build with a newer IDF or framework version? Because this "LittleFS bug" typically shows up when you try to use "Lorol LittleFS" together with arduino-esp32 v2.0.x. Did you also get a warning message to "Use builtin LittleFS"?

In general, better don't use newer framework versions, unless you absolutely have to do it. The new frameworks are full of bugs, don't know what's happening at exspressif as they seem to fail regularly with making usable frameworks...

To use the builtin LittleFS in newer frameworks:

• remove -D LOROL_LITTLEFS from build_flags
• remove https://github.com/lorol/LITTLEFS.git from lib_deps

[dfparent]

Yeah... I literally branched the source at a few random commits, commented out the default_envs variable, uncommented the esp32dev default_env variable and ran the build. I was just trying to get binaries to test to see what commit introduced the TM1814 problem, but I can't get it to build before the change to the platformio.ini file. Plain vanilla PlatformIO, out of the box everything.

[softhack007]

did you try already to simply select env:esp32dev_qio80 as compile env, then hit the "build & upload" button? That should be sufficient to give you a firmware for generic ESP32.

After that is working, you could copy the [env:esp32dev_qio80] section from platformio.ini into platformio_override.ini. Then give it a new name, like [env:my_own_esp32dev]. Now add any extra build_flags and lib_deps that you want. From my experience, that's the easiest way to get compilation to work.

In case you see strange "include file not found" errors, that might be a limitation of cmd on Windows, and you can switch to powershell (v7.2.x) as described here: https://community.platformio.org/t/the-command-line-is-too-long-windows/16406

If you are using VSCode, open the settings page and search for “terminal.integrated.shell.window”. I believe you can select cmd.com, the default, or choose PowerShell.

Edit: might be necessary to delete .vscode\c_cpp_properties.json after changing the shell, to clean up any broken paths that could still be in the VSCode cache.

[blazoncek]

@dfparent use esp32dev environment provided with each commit to compile and upload. Just checkout each commit in succession and upload. It should work w/o issues. If you keep getting compile errors your PIO installation has been corrupted. Be careful not to update platforms from within PIO configuration and only use those provided in platformio.ini.

[dfparent]

@softhack007, thanks for the tips. I am trying to build a commit from Jan 25, 2022 and that version does not define the esp32dv_qio80 environment. If I try to build a commit from Feb 9, it builds but exhibits the problem that is the subject of this ticket.

If I take the changes to platformio.ini from Feb 3, 2022 and apply them to platformio.ini in the Jan 25 build, it builds, but the TM1814 demo mode problem exists and now the config page is gone so I have to reflash the CPU with a USB. (So never do that).

As far as I can tell, this problem is due to the dependency changes, but I can't prove it. All I know is that what is in Git Hub prior to Feb 9 will not build and anything after Feb 9 is broken for TM1814 on ESP 32.

[blazoncek]

Looks like commit https://github.com/Aircoookie/WLED/commit/97f8eea302f1ad123fd60f3050cbe6dea687501b is directly responsible for handling off refresh.

[dfparent]

OK. So a couple of surprising developments.

1. On a whim I started using Tortoise GIT to switch branches (instead of GIT Hub Desktop) and when I did that the build started working. I mean I uninstalled PlatformIO, deleted the .pio folder, restarted VSCode, reinstalled PlatformIO, etc and nothing worked until I switched branch using Tortoise GIT. Makes me want to pull out whatever hair I have left.
2. Somewhere along the way I installed a Frankenstein build that did not have a working Config page, so I could not OTA install. So I opened the box and flashed a new version via USB. It seems once I did that and could actually build (see above), the problem has gone away (for the most part). I installed 0.13.3 and things seem to be working. Could the flash via USB have updated the File System? Could I have had the old file system and an incompatibility with that cause the problems?

Dunno. At this point the only effects that I can see that are exhibiting this problem are

• Dissolve
• Dissolve Rnd
• ICU

Which would imply an issue with those specific effects. Interestingly other very similar effects have no problem.

Let me know if you would like me to create a new ticket for these 3 effects or if you just want to keep this one open. But I can say that once the FS is upgraded, the latest release works well with TM1814 (at least mine).

[dfparent]

BTW, thanks for the help and your patience with me. WLED is an amazing project.