ESP32-DMX_rdm STATION_MODE

[ririfonfon]

hello i have a problem with esp32dmxrdm when i go in station mode the esp32 ce connect to the network then shows me this error:

config read OK. wifi connecting to RIRI-DMX-WiFi... wifi started 2.0.0.111 starting DMX interfaces created, udp started listening, setup complete. number of tasks is 13 E (117455) esp_pthread: pthread_getspecific: not supported! E (117455) esp_pthread: pthread_setspecific: not supported! abort() was called at PC 0x400d6593 on core 1

Backtrace: 0x40087650:0x3ffd6360 0x4008774f:0x3ffd6380 0x400d6593:0x3ffd63a0 0x400d65da:0x3ffd63c0 0x400d6cde:0x3ffd63e0 0x400d6d67:0x3ffd6400 0x400d6232:0x3ffd6420 0x400d61e9:0x3ffd6440 0x400d3ad8:0x3ffd6460 0x400d4da5:0x3ffd64a0 0x400d4ddf:0x3ffd64c0 0x400d1b11:0x3ffd64e0 0x4011b9b0:0x3ffd6500

Rebooting... ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (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:0x3fff0010,len:4 load:0x3fff0014,len:572 load:0x40078000,len:0 load:0x40078000,len:9880 entry 0x400789d8

config read OK. wifi connecting to RIRI-DMX-WiFi... wifi started 2.0.0.111 starting DMX interfaces created, udp started listening, setup complete. number of tasks is 13 E (126324) wifi: error malloc bcn_param

I just changed that in LXDMXWIFIConfig.cpp in line 76 _wifi_config->wifi_mode = STATION_MODE ; // AP_MODE or STATION_MODE _wifi_config->protocol_flags = MULTICAST_MODE; // sACN multicast mode // optional: | INPUT_TO_NETWORK_MODE specify ARTNET_MODE or SACN_MODE // optional: | STATIC_MODE to use static not dhcp address for station // eg. _wifi_config->protocol_flags = MULTICAST_MODE | INPUT_TO_NETWORK_MODE | SACN_MODE; strncpy(_wifi_config->ssid, "RIRI-DMX-WiFi", 63); strncpy(_wifi_config->pwd, "riridmxwifi", 63);

it connect this on another esp32 in ap mode with ssid and pwd, of course with esp32-dmx_rdm

[claudeheintz]

Is it the case that this works for you on one board and not another?

It appears that the sketch made it all the way through the setup() function, ran into an error, and then restarted, made it all the way through setup and ran into another error. The errors look memory related to me. Are the boards you are running this on identical?

[ririfonfon]

632/5000 it works in ap on my two esp32 mh and live esp32devkit. I was also thinking about a card problem. So I reversed my cards. and therefore the error is only in the station. it is sure that it does not come from the map because I even try on a third esp32 card. yes I still have the same mistake whether it is a card or another. E (117455) esp_pthread: pthread_getspecific: not supported! E (117455) esp_pthread: pthread_setspecific: not supported! abort () was called at PC 0x400d6593 on core 1 this error is constant. E (126324) wifi: error malloc bcn_param and this is rare. did you notice these mistakes.

[claudeheintz]

I have not noticed this problem and I mostly use the ESP32 in station mode. It seems like you are asking the ESP-32 board in station mode to connect to another in access point mode. Have you tried instead to connect to a non-esp WiFi network? Also, it could be that this is an issue with the arduino-esp32 library. The one I have been using is from somewhere around a month ago. There have been a lot of changes to the master on github since then. I updated my copy today (espressif/arduino-esp32) and will try uploading the rdm example using the latest when I get a chance next week. There's only one file that is changed from the espressif/arduino-esp32 library for DMX input to work and that is cores/esp32/esp32-hal-uart.c. I don't believe that any changes to this have been made in the last month. But there may have been changes to the WiFi that are causing this problem. (That's entirely speculative as to why you might see this when I don't.)

[ririfonfon]

actually I connect this esp in station on another in ap. I did not try to connect it to another network. I will try that and keep you results. I will also see your new version. thank you. and good end of the year

[claudeheintz]

Also, you can try to comment out line 612: checkConfigReceived(sACNInterface, &sUDP); The stack trace points to this. However, the decoder gives the wrong line number (which may be a result of differences in the espressif library I have vs. the one you are using) and so the decoded trace is not accurate.

[ririfonfon]

I updated (espressif / arduino-esp32) and it's been 12 minutes that the esp are connected and no error. I'll let them run all night and I'll let you know tomorrow. It seems to be working. thank you

[ririfonfon]

Well, no, I was too optimistic. it does not work.I will try to comment on line 612:

[ririfonfon]

it does not work. it is but worse. reboot on reboot.

[ririfonfon]

so i try to connect them to my home wifi.freebox network. but that's the same.

[ririfonfon]

the esp which is in dmx input does not reboot is stable on my home network. it is thus in station and stable but in input. ???

[claudeheintz]

Can you post the backtrace now that the arduino-esp32 library is updated? Perhaps the decoder will be more accurate if I can duplicate your source files.

Also, can you diagram the setup, something like this:

dmx -> ESP-32(AP/input) ----Art-Net-----> ESP-32(STA/output) -> dmx

I'm want to be clear which is input/output and which is access point/station and which network protocol you are using. And, of course, which one is crashing.

[ririfonfon]

of course,

my diagram is the one:

dmx -> ESP-32 (AP / input) ---- Art-Net -----> ESP-32 (STA / output) -> dmx

it's ESP-32 (STA / output) reboot

I add a screen on esp32 AP / input and buttons

config but the one works very well.

ESP32-DMX-rdm_riri_node_004 is AP

ESP32-DMXNeopixels_riri_007_3 is STA

De : Claude Heintz [mailto:notifications@github.com] Envoyé : dimanche 31 décembre 2017 01:23 À : claudeheintz/LXDMXWiFi_Library LXDMXWiFi_Library@noreply.github.com Cc : richard fontaine ririfonfon10@gmail.com; Author author@noreply.github.com Objet : Re: [claudeheintz/LXDMXWiFi_Library] ESP32-DMX_rdm STATION_MODE (#12)

Can you post the backtrace now that the arduino-esp32 library is updated? Perhaps the decoder will be more accurate if I can duplicate your source files.

Also, can you diagram the setup, something like this:

dmx -> ESP-32(AP/input) ----Art-Net-----> ESP-32(STA/output) -> dmx

I'm want to be clear which is input/output and which is access point/station and which network protocol you are using. And, of course, which one is crashing.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/claudeheintz/LXDMXWiFi_Library/issues/12#issuecomment-354577043 , or mute the thread https://github.com/notifications/unsubscribe-auth/AYX5coSIkhj6Y_PwH7DNgBFokU7mSVMRks5tFtP-gaJpZM4RPY1z . https://github.com/notifications/beacon/AYX5cvmpm6Af-V6zi6eP5TVluSXKh7paks5tFtP-gaJpZM4RPY1z.gif

---

L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus

[claudeheintz]

I thought that you were using the ESP32-DMX_rdm example which acts as an Art-Net node and outputs regular dmx. But, your post suggests that might not be the case, that you are receiving Art-Net to drive NeoPixels rather than regular DMX.

If you were using the ESP32-DMX_rdm example exactly as it appears on GitHub, with only modifying the LXDMXWiFiConfig.cpp file, (and the latest arduino-esp32 hardware library with just the modified esp32-hal-uart.c file), then I can decode the backtrace to see where in the code the error is happening. The backtrace looks like this:

Backtrace: 0x40087650:0x3ffd6360 0x4008774f:0x3ffd6380 0x400d6593:0x3ffd63a0 0x400d65da:0x3ffd63c0 0x400d6cde:0x3ffd63e0 0x400d6d67:0x3ffd6400 0x400d6232:0x3ffd6420 0x400d61e9:0x3ffd6440 0x400d3ad8:0x3ffd6460 0x400d4da5:0x3ffd64a0 0x400d4ddf:0x3ffd64c0 0x400d1b11:0x3ffd64e0 0x4011b9b0:0x3ffd6500

The decoder (https://github.com/me-no-dev/EspExceptionDecoder) converts these hex addresses into function names:

Decoding 13 results 0x40087650: multi_heap_assert at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/heap/./multi_heap_platform.h line 53 : (inlined by) merge_adjacent at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/heap/./multi_heap.c line 226 0x4008774f: multi_heap_malloc_impl at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/heap/./multi_heap.c line 372 0x400d6593: rtc_isr at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/driver/./rtc_module.c line 1664 0x400d65da: rtc_isr_ensure_installed at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/driver/./rtc_module.c line 1664 0x400d6cde: tcpip_adapter_ipc_check at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/tcpip_adapter/./tcpip_adapter_lwip.c line 1065 0x400d6d67: tcpip_adapter_start_ip_lost_timer at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/tcpip_adapter/./tcpip_adapter_lwip.c line 1065 0x400d6232: __divdf3_aux at /Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libgcc/config/xtensa/ieee754-df.S line 1337 0x400d61e9: __divdf3_aux at /Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libgcc/config/xtensa/ieee754-df.S line 1301 0x400d3ad8: WiFiSTAClass::config(IPAddress, IPAddress, IPAddress, IPAddress, IPAddress) at /Users/claude/develop/Arduino/hardware/espressif/esp32/libraries/WiFi/src/WiFiSTA.cpp line 604 0x400d4da5: LXWiFiSACN::initialize(unsigned char) at /Users/claude/develop/Arduino/libraries/LXDMXWiFi_Library/src/LXWiFiSACN.cpp line 137 0x400d4ddf: LXWiFiSACN::initialize(unsigned char) at ?? line ? 0x400d1b11: checkConfigReceived(LXDMXWiFi, WiFiUDP) at /Users/claude/develop/Arduino/libraries/LXDMXWiFi_Library/examples/ESP32-DMX_rdm/ESP32-DMX_rdm.ino line 525 0x4011b9b0: rcUpdateTxDoneAmpdu2 at ?? line ?

For this to work and to match address to function, the compiled code must be the same. For me to do the decoding, I need to match what you have compiled and are testing. However, you could use the EspExceptionDecoder tool on your code, after an exception has occurred and that will give you a more precise location of what function is causing the error. In the above decoded stack trace, the addresses in the backtrace obviously do not match the functions in the source code.

[ririfonfon]

0x40087650: invoke_abort at /Users/ficeto/Espressif/ESP32/esp-idf/components/esp32/./panic.c line 553 0x4008774f: abort at /Users/ficeto/Espressif/ESP32/esp-idf/components/esp32/./panic.c line 553 0x400d595f: cxxabiv1::terminate(void ()()) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc line 112 0x400d59a6: std::terminate() at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc line 112 0x400d60aa: __cxa_get_globals at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_globals.cc line 133 0x400d6133: __cxa_throw at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc line 65 0x400d55fe: operator new(unsigned int) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_op.cc line 54 0x400d55b5: operator new[](unsigned int) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_opv.cc line 32 0x400d3008: WiFiUDP::parsePacket() at F:\Documents\Arduino\hardware\espressif\esp32\libraries\WiFi\src/WiFiUdp.cpp line 129 0x400d3935: LXWiFiArtNet::readArtNetPacket(UDP) at F:\Documents\Arduino\libraries\LXDMXWiFi_Library-master\src/LXWiFiArtNet.cpp line 499 0x400d3975: LXWiFiArtNet::readDMXPacket(UDP) at F:\Documents\Arduino\libraries\LXDMXWiFi_Library-master\src/LXWiFiArtNet.cpp line 499 0x400d18cc: loop() at F:\Documents\Arduino\ESP32-DMXNeoPixels_riri_007_3/ESP32-DMXNeoPixels_riri_007_3.ino line 585 0x4011ad4c: loopTask(void) at F:\Documents\Arduino\hardware\espressif\esp32\cores\esp32/main.cpp line 18 (discriminator 1)

[ririfonfon]

Hello and good year. I followed your instructions. When I updated yesterday arduino-esp32, I forgot to change esp32-hal-uart.c. it's done but still the same mistake. so I change:  _wifi_config-> ap_address = IPAddress (10,110,115,10); // ip address of access point   _wifi_config-> ap_gateway = IPAddress (10,110,115,10);   _wifi_config-> ap_subnet = IPAddress (255,255,255,0); // match what is passed to dchp connection from computer   _wifi_config-> sta_address = IPAddress (10,110,115,15); // station's static address for STATIC_MODE   _wifi_config-> sta_gateway = IPAddress (192,168,1,1);   _wifi_config-> sta_subnet = IPAddress (255,0,0,0);   _wifi_config-> multi_address = IPAddress (239,255,0,1); // sACN multicast address should match   _wifi_config-> sacn_universe = 1;   _wifi_config-> sacn_universe_hi = 0;   _wifi_config-> artnet_portaddr_lo = 0;   _wifi_config-> artnet_portaddr_hi = 0;   _wifi_config-> device_address = 1; _wifi_config-> input_address = IPAddress (10,255,255,255); LXDMXWIFIConfig.cpp in my two sp32. and I have more artnet on the network? but I still have the same mistake on the station.

[ririfonfon]

ok why do I have to change that: _wifi_config->ap_address = IPAddress(10,0,0,10); // ip address of access point _wifi_config->ap_gateway = IPAddress(10,0,0,10); _wifi_config->input_address = IPAddress(10,0,0,255); so that I find artnet on the network

[claudeheintz]

I updated the example today. Using the remote config app to setup 2 ESP32 boards, the following ran for a couple of hours:

dmx -> ESP-32(AP/input) ----Art-Net-----> ESP-32(STA/output) -> dmx

Its not clear what you are asking about in terms of the network addresses. The input address is that address that Art-Net is sent to when the mode is input to network, which reads DMX from the UART and sends out Art-Net packets. In my test, the station had the default static address 10.110.115.10. The gateway address is used to resolve addresses and the subnet determines what portion of the IPv4 address belongs to the network and what part is unique to the host. Addresses beginning with 10. are class A addresses so the that is the network portion. The other three octets form the host's unique address. If you use the subnet mask 255.0.0.0 then the broadcast address that goes to all hosts is 10.255.255.255. If you use the subnet mask 255.255.255.0, then the broadcast address is the first three octets followed by 255 in the last one. Any computer that can receive the broadcast must have the same first three octets in its address. In my test, the receiving ESP-32 in got its network setting using DHCP. The node doing the inputting sends Art-Net packets to the broadcast address so that any Art-Net receiver on the same network gets them. This strategy is used so the node does not have to use polling and maintain a list of potential receivers. Because it is sending and not listening, it does not respond to Art-Net polls. You'll see the other ESP-32, the output node, because it is listening for Art-Net packets from the network. When it receives a poll, it responds to it. It is possible to modify the example so that packets are received in input mode and the library would respond to ArtPoll packets on its own. In that case, you'd also see the input node in the list. The fact that in input mode, the example does not read packets from the network is also why you can't locate it with the config utility. And, the design of a button to start in default in access point/output mode is exactly for this reason. In this mode, you can connect a computer, locate the node and re-configure it with the config utility.

[ririfonfon]

if I understand correctly, with the application of remote configuration there is no bug of the receiver? as far as network addresses are concerned, I know these terms very well. brodcast etc .. but luminet luminex application. http://www.luminex.be/ which in Europe is the refrence of the artnet network does not find any noeux? you can download it here http://www.luminex.be/support/product-support/ I will try to configure my esp32 with the remote application but for my part I do not find it very convenient your application because it takes a computer and change the pull up in pull down etc ... so a big uzine has gas for what parameter change then the reboot with the pull up ... in short it's a bit hell for a non-geek. what i am trying to develop with your code is a emitter node with a config screen and 4 buttons: menu, up, down, enter. to configure. and 4 receivers integrated in the scenic device which controls each 4 ribbons ws2812 and 2 leds in pwm 16bits. all this must go on tour in early March 2018. with a non-geek light regulator. on a rock and roll tour it means the director has from 4 to 6 hours max.to do are show. when he is not in festival. so you need a simple and efficient solution.

thank you for all.

[ririfonfon]

so I followed your instructions: use the configuration application. and I still have the same problem: the decoding of the back trace: Decoding 13 results 0x40087650: invoke_abort at /Users/ficeto/Espressif/ESP32/esp-idf/components/esp32/./panic.c line 553 0x4008774f: abort at /Users/ficeto/Espressif/ESP32/esp-idf/components/esp32/./panic.c line 553 0x400d6593: cxxabiv1::terminate(void ()()) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc line 112 0x400d65da: std::terminate() at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc line 112 0x400d6cde: __cxa_get_globals at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_globals.cc line 133 0x400d6d67: __cxa_throw at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc line 65 0x400d6232: operator new(unsigned int) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_op.cc line 54 0x400d61e9: operator new[](unsigned int) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_opv.cc line 32 0x400d3ad8: WiFiUDP::parsePacket() at F:\Documents\Arduino\hardware\espressif\esp32\libraries\WiFi\src/WiFiUdp.cpp line 129 0x400d4569: LXWiFiArtNet::readArtNetPacket(UDP) at F:\Documents\Arduino\libraries\LXDMXWiFi_Library-master\src/LXWiFiArtNet.cpp line 181 0x400d45a9: LXWiFiArtNet::readDMXPacket(UDP) at F:\Documents\Arduino\libraries\LXDMXWiFi_Library-master\src/LXWiFiArtNet.cpp line 181 0x400d1aed: loop() at C:\Users\ririf\AppData\Local\Temp\arduino_modified_sketch_265940/ESP32-DMX_rdm.ino line 604 0x4011b9b0: loopTask(void) at F:\Documents\Arduino\hardware\espressif\esp32\cores\esp32/main.cpp line 18 (discriminator 1) ????

[ririfonfon]

just to be really sure. at home does it work?

[claudeheintz]

Yes, it does work.

The problem is not in the config at all. It is in the call to parsePacket() in the ESP32 WiFi library. Inside parse packet there's an allocation: 210] char * buf = new char[1460]; (The line number on your backtrace is different but this is the only call to new that I see) This allocation fails and that is what is causing your crash.

I have never seen this problem. But I have plenty of memory on my board(s). You are running out for some reason. Assuming that your board has memory available and it is not physically running out, you could try increasing the stack size of the app_main function in hardware/espressif/ESP32/cores/ESP32/main.cpp

extern "C" void app_main() { initArduino(); xTaskCreatePinnedToCore(loopTask, "loopTask", 8192, NULL, 1, NULL, ARDUINO_RUNNING_CORE); }

You could try increasing the 8192 to 10240 and see if that allows parsePacket to allocate its buffer.

[claudeheintz]

Another way of freeing up memory (if you are sticking to Art-Net only) is to remove:

69] LXWiFiSACN* sACNInterface; 73] WiFiUDP sUDP;

and any code that uses these objects.

sACNInterface allocates over 1500 bytes just in the DMX buffers alone.

[ririfonfon]

ok it works for now (30min) I remove all that is from the sACN

thank you

[ririfonfon]

well no after 45 minutes it does not work

[claudeheintz]

I've had the Art-Net->DMX example running for hours with the latest hardware/espressif/esp32 and no issues whatsoever.

What you might try is running the example with regular DMX output instead of driving LED pixels to insure that it works on your hardware with the libraries you have included.

You can add:

Serial.println(uxTaskGetStackHighWaterMark(NULL));

after line 662, vTaskDelay(1); in the main loop.

This should let you see how large the stack for the main loop was when it was at its largest. On my ESP32 it constantly shows 6600 from the first time through the loop. But, if something in your use is leaking memory, it might show up by doing this.

Sending an update to LED pixels takes quite a bit of time. It is quite possible that it takes enough time that it is impossible to keep up at the same rate as the DMX. Art-Net should not be faster than 44 DMX frames/sec. But, it may be that the ESP is busy sending pixel data and packets are piling up waiting to be parsed by the WiFi UDP object. If this is the case, it means slowing down the rate of the DMX so that it is no faster than you can send the pixel data out.

[ririfonfon]

hello i compile another code. which works very well . with the library: esp32_digital_led_lib.h, wifi.h, WiFiUdp.h, ArtnetWifi.h. many more simple and very stable. the more is the multi output for ws2812 . another track for what the bug is that I use the whole universe the 512 parameters. I think that's the problem that says. I saw that you have updated your lib. what are the new functions or bug fix. As for the emitter dmx => I will stay on your code it looks stable and well transmits the 512 parameters. thanks again.