search

claudeheintz / LXDMXWiFi_Library

Library for ESP8266 implements Art-Net and sACN with example DMX input/output to/from network
BSD 3-Clause "New" or "Revised" License
76 stars 17 forks source link

WDT resets #16

Open jamesgbahr opened 6 years ago

jamesgbahr commented 6 years ago

loaded stock code for esp lxdmxwifi example and in AP mode im getting hard reset and WDT error on reboot

claudeheintz commented 6 years ago

What board / upload settings are you using where this happens? Which of the example sketches did you try where you get this problem?

jamesgbahr commented 6 years ago

https://github.com/claudeheintz/LXDMXWiFi_Library/blob/master/examples/ESP-DMXNeoPixels/ESP-DMXNeoPixels.ino

This sketch on a nodemcu v3 it gets the artnet data but after a short amount of time freezes and reboots with a wdt error in serial monitor

jamesgbahr commented 6 years ago

upload settings are 80mhz, 4m (1 spiff), v2 lower memory

claudeheintz commented 6 years ago

How many NeoPixels do you have hooked up? Are they powered from USB through the board?

In AP mode, the board can consume a lot of power and low voltage can cause a reset. Not all USB ports are capable of delivering 500 mA either.

If the restart happens with no LEDs on, just with receiving Art-Net, then its not the power. However, if the restart happens after a number (>2 or 3) of LEDs are powered on (especially if all three colors are at full intensity), then try powering the NeoPixels with their own power source, not running off the board's supply.

jamesgbahr commented 6 years ago

only have 4 pixels hooked up, grounded on board separate power.. i am however powering the nodemcu v3 through usb.. The restart happens while the leds are working and receiving data but only work for 10-30seconds then wdt reboot

jamesgbahr commented 6 years ago

the usb port i was powering the nodemcu from was a 5v 1a wall charger

claudeheintz commented 6 years ago

Power does not sound like the issue then. It could be that the issue has something to do with the control source. Are you sending Art-Net or sACN? What application is originating these packets?

It could also be the specific pin you are using. In trying to test to see what could be happening for you I hooked up a NeoPixel feather wing to an Adafruit ESP8266 feather board. The data signal would be sent from the feather's pin 16. However, for some reason pin 16 is unable to control Neo Pixels. I could use other pins with other NeoPixels--just not with the 4x8 feather wing which requires pin 16 (unless you cut and solder jumpers).

jamesgbahr commented 6 years ago

I did try moving pins. Having a bit more success with station mode and e131, Although is only working using unicast, cannot get it to see multicast

jamesgbahr commented 6 years ago

im using pixelcontroller and also tried jinx, does it need to be in a class D network to see those multicast packets?

claudeheintz commented 6 years ago

I have an Adafruit ESP8266 feather Huzzah that works without WDT problems streaming sACN via multicast. I'm not sure what is different about your board. You can try separating the NeoPixel code to make sure that your board can run NeoPixels without the network control. You might do this by commenting out the copyDMXToOutput(); call in the main loop. And, inserting some code that does something like fading some pixels up and down: (in setup) uint8_t test_level =0; (in loop) setPixel(1, test_level); setPixel(2, test_level); setPixel(3, test_level); setPixel(4, test_level); test_level++; sendPixels();

This leaves the WiFi/UDP listening running. You can see if the pixels are stable just with this. Then, connect to the WiFi. Then add in the control. This might give a clue about what causes the crash as in does it crash in step 1, 2, or 3?

Alternatively, you can replace copyDMXToOutput(); with a serial print to isolate the network portion and see if there's a problem with that.

For me, the example runs straight as it is with no problems. So, there has to be something different in your setup. It could be something with the firmware on your board that is different than the Adafruit Huzzah. But, that's just speculation and without some detective work, I can just guess at why you'd be having a problem.