Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Bert Melis
@bertmelis
Is it something architectural? I thought the PROGMEM strings are "global" which is in conflict with the inline use.
Martin Ayotte
@martinayotte
@brutzler , just follow this esp8266/Arduino#2351
Zombo
@zombodotcom
Hey, I was using a nodemcu and a wemos d1 mini for an led project. I was powering them with a TP4056 with parallel 18650s. I was powering the boards and the leds with the TP4056 and 18650s. The webserver I used to change patterns programmed with fastled worked for a good 30 minutes, then when I changed to a certain pattern the nodemcu and wemos d1 mini both crashed and started doing watchdog resets.
after it tries to start up the webserver. Did I fry the 1117 voltage regulator
or the shokkty diode?, I need to get a 9v battery for my multimeter, but I am wondering if anyone else has had this issue powering ws2812b led lights and a nodemcu and or a wemos d1 mini with 18650s and a TP4056
i also tried another setup with the led lights getting their own 18650s with a TP4056, and the nodemcu / wemos d1 mini with its own 18650 and TP4056, and the same thing happened after a few minutes.
Michael Miller
@Makuna
@bertmelis What is the signature of your println function? Where are you calling this from?
The progmem are global, the __c is static and defined within a scope making them global and unique.
Did you search for section type conflict error?
Bert Melis
@bertmelis
It is called from within a library I created. I'll try to reproduce in a simple example.
(library = class + )
Bert Melis
@bertmelis
I can't reproduce using a simple example (maybe it's too simple, but I don't know where my error comes from). My real life example is residing in https://github.com/bertmelis/VitoWifi. I can't put any PROGMEM debug messages in Optolink.cpp inside the inline checksum methods.
Bert Melis
@bertmelis
for example: adding _debugPrinter->println(F("just checking"));to https://github.com/bertmelis/VitoWifi/blob/develop/src/Optolink.cpp#L421 generates the error.
(you may find the lib written badly, but I'm only auto-didacting since a couple of months)
Lars Englund
@larsenglund
Hmm, I'm getting this stackdump:
https://pasteboard.co/g2nmn9aYz.png
Should I dig for the problem in ESP8266mDNS.cpp?
(line 261 contains the closing bracket for the addServiceTxt method so I'm guessing the line numbers are incorrect or refering to some other file?)
Lars Englund
@larsenglund
The code for sending out querys has worked fine before so I'm thinking something in my network might cause it?
Myles Eftos
@madpilot
I found wireshark pretty handy for debugging this stuff as mDNS packets are broadcast. You might find a massive packet is locking up the parsing and causing the watchdog to trigger. What CPU speed have you set?
Lars Englund
@larsenglund
160mhz
Lars Englund
@larsenglund
Hmm, after some debugging in ESP8266mDNS.cpp::_parsePacket() I found that it enters an infinite loop trying to add a new answer to answer list (around line 644)
It adds the three first answers to the list without any problem but when the fourth is parsed and ready to be added while (answer->next != 0) { never exits..
Could answer->next have been corruptedhow?
Since every new answer gets intialized to answer->next = 0;...
Myles Eftos
@madpilot
Could be a bad packet that is causing a buffer overflow, stopping the traversal from terminating. Hard to say with out looking at the packet
Lars Englund
@larsenglund
Reading answers RX: REQ, ID:0, Q:0, A:4, NS:0, ADD:0
 4 5f 65 73 70 
found matching service: esp
 4 5f 74 63 70 
 5 6c 6f 63 61 6c 
type: 000c rdlength: 28
0a 65 73 70 5f 44 41 33 35 45 41 04 5f 65 73 70 04 5f 74 63 70 05 6c 6f 63 61 6c 00 
 10 65 73 70 5f 44 41 33 35 45 41 
 4 5f 65 73 70 
found matching service: esp
 4 5f 74 63 70 
 5 6c 6f 63 61 6c 
type: 0010 rdlength: 0

 10 65 73 70 5f 44 41 33 35 45 41 
 4 5f 65 73 70 
found matching service: esp
 4 5f 74 63 70 
 5 6c 6f 63 61 6c 
type: 0021 rdlength: 24
 10 65 73 70 5f 64 61 33 35 65 61 
esp_da35ea
 10 65 73 70 5f 64 61 33 35 65 61 
 5 6c 6f 63 61 6c 
type: 0001 rdlength: 4
All answers parsed, adding to _answers list..
else
It's after this packet the loop starts so it does not look like a buffer overflow
Also I have checked that I have lots of heap space left (>28K)
Lars Englund
@larsenglund
I see now that the problem occurs when _parsePacket has returned after parsing the first three packets and is then called again in MDNSResponder::update() and continues to add a fourth answer to the same answer list.. if that has any significance.. also the next-pointer of the last element in the answer list has changed from 0 to pointing to the last item itself when entering parsePacket the second time (thus causing the infinite loop)
Boggle.. what could be causing the next-pointer to be overwritten between two calls to _parsePacket
I've pasted a sample serial output and the parsePacket that generates it there
Lars Englund
@larsenglund
Crap, It has already been fixed esp8266/Arduino#2347
I really need to switch to using the latest github code.. sorry for spamming with already answered questions..
Lars Englund
@larsenglund
Hmm, after following the instuctions to use the git version on https://github.com/esp8266/Arduino#using-git-version i get fatal error: SoftwareSerial.h: No such file or directory when compiling my code..
Lars Englund
@larsenglund
an-erd
@an-erd
Is there a way to do a OTA update and do some stuff in the loop(), too.
OTA is working fine, the callback functions are called, but I didn't get it working to update the display which is called from the loop().
Me No Dev
@me-no-dev
with current version, no
if we move the TCP part to Async, then yes
an-erd
@an-erd
can I spend some time in the ArduinoOTA.onProgress() function to update the display?
Me No Dev
@me-no-dev
yes
not too much though
an-erd
@an-erd
Ok thanks, I'll try
an-erd
@an-erd
Works pretty good, the OLED display update does not cause any problems! Thanks
Myles Eftos
@madpilot
@me-no-dev Is using async something you are working on at the moment? As I was thinking of looking in to this.
Me No Dev
@me-no-dev
@madpilot my async libs are fine, if that is what you are asking, else I'm working on esp32
James
@WanaGo

Hello
Does anyone have any experience with doing UDP NTP Time stuff with the ESP8266?
I am using the PJRC time library, and based my sketch on the ESP8266 example.
I get the NTP server IP on startup, and it gets the EPOCH time no problem. But the next time to goes to sync (set for 5 minutes, but tried 30 minutes also), it fails.
I enabled the Debug, and I get the following:

connected with ROUTER, channel 11
ip:192.168.178.99,mask:255.255.255.0,gw:192.168.178.1
wifi evt: 0
wifi evt: 3
Connected - 192.168.178.99
Setting Up UDP
scandone
Transmit NTP Request
[hostByName] request IP for: pool.ntp.org
[hostByName] Host: pool.ntp.org IP: 202.6.116.123
pool.ntp.org: 202.6.116.123
Receive NTP Response

And then next time I get:

Transmit NTP Request
[hostByName] request IP for: pool.ntp.org
[hostByName] Host: pool.ntp.org lookup error: -5!
pool.ntp.org: 0.0.0.0

James
@WanaGo
tried DHCP, Static, defining DNS and not defining DNS, results are the same. I cant figure out what is going on.
it uses the exact same code the first attempt as with every other attempt
James
@WanaGo
esp8266/Arduino#3150
That looks to be the same thing