atuline/WLED

Serial interface doesn't work with 0.13.1 pre-release

Drizzt321 opened this issue · 7 comments

What happened?

When I try to use the serial interface to get data/control WLED, I get output when it boots up (see below), but when I try and send commands (e.g. v or l or L) I get no reply at all. When I use mainline 0.13.1 from https://github.com/Aircoookie/WLED/releases works fine.

rst:0xc (SW_CPU_RESET),boot:0x1b (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5816
entry 0x400806ac
AS: Analog Microphone.
Ada

To Reproduce Bug

Try and use serial interface, and send v which should return the version (e.g. WLED 2203150), but with the 0.13.1 pre-release there's no response at all.

Expected Behavior

Serial interface works as per https://kno.wled.ge/interfaces/serial/

Install Method

Binary from WLED.me

What version of WLED?

soundReactive_WLED_0.13.1_ESP32.bin

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

No response

Anything else?

No response

Code of Conduct

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

There are some preconditions

  • you need to have a build that supports "AdaLight" (-D WLED_ENABLE_ADALIGHT),
  • GPIO3 not used for any other purpose (not as LED pin, not as button input, not for I2C, etc).

If these are met, sending "v" over USB serial should give you the WLED version number as a response.

Can you please check?

@softhack007 Hm, I'm using the atuline official (pre-release) build, not sure what the build flags are.

As for GPIO, not sure, I'll have to check when I get home next week. However the main WLED trunk 0.13.1 (ESP-32) build from https://github.com/Aircoookie/WLED/releases/tag/v0.13.1 the serial works just fine. So maybe this branch has a different Serial pin configuration by default checked in or something?

@softhack007 So LED Output is set to GPIO2, Button 0 GPIO is set to GPIO0, the mic is I2C (don't see any setting to change the I2C pins), so doesn't look like GPIO3 is used for anything. Unless there's something in the code between the mic input I2C that tells it to use GPIO3?

As per the diagrams and documentation at https://www.tindie.com/products/stanleyprojects/ledbox-v2/, Serial TX is pin 35 (GPIO18) and Serial RX is pin 34 (GPIO5), and I2S for the mic are GPIO 14/15/32.

So after looking a little more, the layout for the Serial TX/RX pins are actually different physical pins on the real esp32-wroom-32 pinout, which are pins 41 & 42, GPIO 1 & 3 (UART0), so it's all correct pins. Still no idea why there's an issue with the Sound Reactive branch, vs vanilla WLED.

There is 1 TPM2 bugfix in the main codebase (Aircoookie@d1f7604), which is not in the SR branch, but I have a hard time seeing that as something that would prevent a response for the v command at least, over serial. Maybe it could?

EDIT: Something interesting I've found, if on boot I spam v into the serial terminal, I get a response for a second or two, and then I stop getting a response. Could it be that the SR code takes over the main loop and doesn't let the Serial get checked to see if there's been any input? That'd stop it from responding to serial input, if it never sees any.

Turns out that there was a little, innocent-looking line in the SR initialization code:

pinMode(LED_BUILTIN, OUTPUT);

Together with these lines that set a default for LED_BUILTIN

#ifndef LED_BUILTIN // Set LED_BUILTIN if it is not defined by Arduino framework
#define LED_BUILTIN 3
#endif

Unfortunately Serial RX is on GPIO3 on most ESP32 boards. So RX was configured as output, making it impossible for WLED to read from serial.

What a nasty little bug. Thanks for helping me to track this down 👍 .

Problem is solved in dev branch.

@softhack007 thanks so much for sticking with me and putting up with my annoying "but it should work!" and so on, glad we got it figured out and tracked down! In the meantime I'll use the .bin you got me with the fix.

@Drizzt321 Thank you, too. Also for insisting that it's not like it should be 😉