I started a project using the esp8266 library 2.0.0 (I believe) and it seemingly worked OK.
The target board is an ESP-07 with 1M flash. So I have selected "Generic esp8266 board".
Later I put my work into subversion and checked out to a new directory for testing, this time the board library setting was not included so I had to do it again and by that time I had forgotten what I had used so I selected the latest 2.4.1 version. (I probably did not correctly select the files to be part of the version control)
Now the project did not build and the error was right inside the library, which of course I can do nothing about.
So then I backed down to the version 2.0.0 and now the sketch verified and could be loaded to the board.
So my question is which version one should use and if there are some problems with sticking to the 2.0.0 library?
When you encounter an error you'll see a button on the right side of the orange bar "Copy error messages". Click that button. Paste the error in a message here USING CODE TAGS (</> button on the toolbar).
Best is to find a solution to the problem so you can use the latest version. There has been a ton of work done since 2.0.0.
There were some features in 2.0.0 that were later removed by Espressif because people were using them for malicious purposes. Maybe you're one of those people?
I no longer use the 2.4.1 library as described so I cannot inspect the error messages....
Maybe later when I have gotten the main bulk of work done I can check what switching back to 2.4.1 will do.
My question was really a general one since I have not used Arduino or the ESP8266 before in a real product.
I have mostly done Microchip PIC24 projects using their MPLAB-X dev system.
I wonder why you would need to implicitly accuse me of being a malicious person?
Is it likely or on what do you base that?
Now I went from 2.0.0 to 2.4.1 again to see what could be causing my problem, which now is that shortly after a client connects to the module there is a wdt reset! This time I had to set a number of config items before I could use the new library, but the build afterwards succeeded.
So after I uploaded the sketch to the ESP-07 and power cycled it the Wifi AP appeared as normal and I could connect to the network. Then I ran my configuration application, which connects to the config TCP port.
I get a message about this on the serial line.
But then almost immediately the unit resets from the watchdog!
Here is what is shown on the serial line when this happens:
BosseB:
I wonder why you would need to implicitly accuse me of being a malicious person?
I didn't "implicitly accuse" you. I asked a question.
BosseB:
Is it likely or on what do you base that?
Considering that 99.99% of people using ESP8266 core for Arduino 2.0.0 are doing so to make a "WiFi jammer" that will be used to ruin peoples' day by making their WiFi not work, yes it's a reasonable suspicion. However, your error indicates this is not the case since I believe you would get a completely different error from trying to use the "promiscuous mode" functions in 2.4.1.
BosseB:
What could I do to troubleshoot this problem?
Try installing the ESP Exception Decoder, following these instructions:
Then continuing with the usage instructions. That will give you more information on the case of the problem which you can then post here and hopefully someone will have an answer.
PROBLEM FOUND!
After putting a lot of serial diagnostic output into the code and switching between versions of the SDK I nailed the problem!
As almost always it was a programming error.... No blame on the sdk level!
What happened was that I had started from the TCP_UART_Bridge example and explored the ways it worked.
Then I started adding in configuration via the EEPROM store and finally I added in a configuration TCP server on a new port. I copied much of the existing code and created defines for this in the same way as what already existed.
And here I made the copy/paste error by forgetting to change the name of one usage of a define within the config TCP server from the original to the config one.
So in the end the array holding clients was dimensioned with the define for the config max client number (1):
#define MAX_SRV_CLIENTS 2 //how many server clients should be able to communicate this ESP8266
#define MAX_CONF_CLIENTS 1 //How many config clients can simultaneously configure the module?
....
WiFiClient tcpConfigClients[MAX_CONF_CLIENTS]; //<== Array contains 1 element
But then in the loop() function I used the serial server define (2):
//check if there are any new Config clients
if (tcpConfigSrv->hasClient()) {
for (i = 0; i < MAX_SRV_CLIENTS; i++) { //<== HERE WRONG DEFINE!!! 2 elements
//find free/disconnected spot
if (!tcpConfigClients[i] || !tcpConfigClients[i].connected()) {
if (tcpConfigClients[i]) tcpConfigClients[i].stop();
tcpConfigClients[i] = tcpConfigSrv->available();
SerialDebug.print("New Config client: "); SerialDebug.println(i);
continue;
}
}
//no free/disconnected spot so reject
WiFiClient tcpConfigClient = tcpServer->available();
tcpConfigClient.stop();
}
Unfortunately roundabout that time I had done major dev IDE changes as well and moved from the default 2.0 sdk to 2.4.1 and written a lot of support code before actually uploading the sketch to the ESP. But when I did I did not have the config application written either, which took some time too. The sketch ran fine as it was until I finally connected to the config port when it bombed out with the exception....
Last night when I finally found the cause I had come to sdk level 2.3.0.
Is there any reason not to switch to 2.4.1 now? Is that level more secure in the way it operates?
Unfortunately I still have occasional resets at totally irregular times. It can sit idle without resetting for hours on end (overnight too) and then when I am close to it it will suddenly have reset even when I am not touching anything connected to the dev system. At one time I was exchanging the batteries in my keyboard when it reset after having run for over 12 hours. I am currently on the esp firmware level 2.3.0.
I will have to check with 2.4.1 if that will help, but it is hard to prove when there is no obvious trigger for the problem like it was with my bug above that triggered the reset 100% of the starts...
Is it solved if there is no rest in 24 hours, or a week?...
It could be a hardware issue. The ESP8266 draws a lot of current at times and if you don't provide a good enough power supply this could happen. The other thing you always need to watch out for is that there is a watchdog timer running on the ESP8266. If you don't return from loop(), call delay(), or call yield() regularly then the watchdog times out and resets the microcontroller.
OK, what is the timeout time of the wdt?
At all out-of-the-blue reset times I have looked at the report always stated that it was the wdt...
Regarding power I am running on a breadboard with a breadboard adapted power supply plugged into the power rails.
I have a 0.1 uF cap soldered right across the ESP power pins on the breakout board and a bigger electrolytic on the breadboard power rails. and the power supply itself is fed from a regulated 12V PS. Should be good on that point.
OTOH at every time I have had this (except when I actually had a code bug causing exception) the resets happened randomly at times with no activity so the loop() should not have gotten stuck anywhere...
Yesterday I switched to library 2.4.1 again and then I let my config app connect to the config port, ran a few commands and went to bed. Now in the morning it all just works as yesterday and there is no reset message on the terminal.
And it works ok to communicate with it.
So hopefully switching to this latest library has solved the problem.
But not.... >:(
While I was working on my computer on something unrelated the ESP-07 reset twice.
So it seems like it was OK until about 10-11 hours had passed and then it crashed....