update() crashing when using WiFi.softAP

[RykWaters]

dmx.update() never completes when i'm using softAP to run an access point on the esp32.

Having debugged as far as i can, the important line in the library seems to be:

pinMatrixOutDetach(txPin, false, false); //Detach our

in the update() function.

If i comment this line (and subsequent lines) my program continues to run. but the moment this line is re-enabled, the whole thing halts.

I'm obviously going to keep digging to see if i can find a workaround to make them both play nicely together.

[AndyEngland521]

Does your program succesfully output DMX data? Try moving that DMXSerial .begin() until after the matrixAttach line, then you might even be able to get rid of the matrix attach and detach lines all together

[RykWaters]

Hi, no luck unfortunately,

If i put DMXSerial .begin()after pinMatrixOutDetach of after pinMatrixOutAttach or comment out pinMatrixOutDetach and pinMatrixOutAttach then i get no DMX output at all.

If i leave it as is, then everything crashes.

[AndyEngland521]

My next course of action would be to move your WiFi Stack to another core, sometimes WiFi calls don't like playing with time sensitive/interrupt related stuff. Also, what type of error is your ESP32 throwing on reset? Check out the following article for some info on separating tasks out to a different core https://www.sparkfun.com/news/2872

[pkarnia]

Even though this is a little stale...

I was having the same issue. Moved wifi to core0, no effect. Whenever I would write data out at real time speed, update() would cause a crash within minutes. Adding delays like in the DMX library examples made the bug less apparent, but it would eventually occur. Try using esp32 core files from:

https://github.com/espressif/arduino-esp32/commit/80418fadcfb91c75d5100a8fddeb9318a8ef7d42

Seems to have fixed the issue for me.

[Kezzsim]

Hey everyone, just wanted to chime in and say I'm encountering more or less the same issue.

Everything works great, I've got a webserver at a fixed mdns address that I can HTTP POST the JSON values I want my DMX Light to have, and then it sets global variables which are readable by the DMX write methods in the loop.

You can even take a look at the source code here and confirm everything looks as it should, my main.cpp isn't that different from @AndyEngland521 's write example

Should be good, right? The presence of dmx.update() kills the loop dead in its track, it runs ONCE at boot and then never again.

Commenting out dmx.update() fixes everything... but then my light does not light up for obvious reasons.

I'm using Platform.io to manage this project so I don't have the luxury of jumping to a newer commit of arduino-esp32 as @pkarnia suggested, I'm pretty much stuck with The Platformio build for my ESP32Thing+

Can I change something in the sparkFunDMX library perhaps that will free the loop? I've run out of ideas for the time being.

[pkarnia]

You should be able to use custom versions of the modified core files in platformio. If you include the modified versions in your SparkfunDMX library or in your project directory I would hope that it would use that version over the espCore version when compiling. Unfortunately I don't use platformio personally so I can't say for sure. If not you could always rename the files (ex. HardwareSerialNew.h, etc...) and modify the includes in these files:

• https://github.com/sparkfun/SparkFunDMX/blob/master/src/SparkFunDMX.cpp
• https://github.com/espressif/arduino-esp32/blob/master/cores/esp32/HardwareSerial.h
• https://github.com/espressif/arduino-esp32/blob/master/cores/esp32/HardwareSerial.cpp
• https://github.com/espressif/arduino-esp32/blob/master/cores/esp32/esp32-hal-uart.c

to reference the new versions.

Unfortunately since the issue appears to be at the esp32 uart implementation level I don't think there is any work around at the SparkfunDMX library level.

[Kezzsim]

Thanks @pkarnia ! I've swapped in the core from that repository and sure enough the main loop no longer stops for the update function! And as a neat side effect of the verbose debug level I've been running the serial monitor in I even get this line about what the hardware interface is doing [V][HardwareSerial.cpp:91] end(): pins 17 16

• UPDATE Connector was loose! It works now!