I am in the midst of porting existing code from some of my earlier projects to a "Wemos D1 mini pro". Unfortunately it seems that (for whatever reasons) the compiled binary may put the device into some "crashed" state.
Once the device is in this state, it seems to be very difficult to bring it back to life, i.e. to
upload some different/functioning binary to it. I have a separate "known good"/"hello world" type project that I am using for this purpose..
I am using the Sloeber IDE (with "default" upload protocol for "WeMos D1 R2 & mini" board): The LED on the device flickers as if the new binary is actually uploaded and the IDE's "0.4.9/esptool.exe" reports that "Uploading.." is 100% finished.
However the device stays "crashed" even after the upload of the "known good" program. Occasionally I managed to get the upload to work, by manually resetting (trial & error) the device just before the upload (something that I would expect the IDE to do anyway..) but right now the device seems to be in some state that makes it re-crash more quickly than in can be re-flashed..
Is there a reliable way to reset the device into a "receptive mode"? And is there some pattern that could be used in the program code (e.g. some delay in the "setup" function) to make sure the device can always to easily re-flashed even if something is "wrong" with flashed program?
it is not about the IDE version, but about the esp8266 SDK version used with esp8266 arduino core package version. there is some settings compatibility broken between the SDK versions. the SDK setting are on the flash
Juraj:
it is not about the IDE version, but about the esp8266 SDK version used with esp8266 arduino core package version. there is some settings compatibility broken between the SDK versions. the SDK setting are on the flash
In the Arduino-IDE's "Boards Manager" I see "esp8266 by ESP8266 Community version 2.3.0 INSTALLED". And my Sloeber-IDE refers to "Location": http://arduino.esp8266.com/stable/package_esp8266com_index.json from which I am using the board "esp8266/2.3.0".
Doesn't that mean that I am using the exact same esp8266 SDK in both IDEs?
One difference is that in the Arduino-IDE I am using a CPU frequency of 80Mhz while I am using 160Mhz in the Sloeber-IDE.. (I want my device to run as fast as possible..) Also I am using a different upload speed: 921600 from the Arduino-IDE but only 115200 from the Sloeber-IDE..
you have a 'pro' version without usb and attached reset circuit, so the flashing tool (not ide) can't set the board into flashing mode
to set the board into flashing mode, io 0 must be low at power-up or reset
I have this model here: https://wiki.wemos.cc/products:d1:d1_mini_pro
and I am using the built-in USB connector to flash it (which works most of the time - unless the device does not like the uploaded .bin and goes into "crash"-mode - which is the scenario that I am refering to in this post)
Add-on: I meanwhile realized that it might just be the LCD display (or it's respective I2C controller) that ends up in some crashed state: I found that I could upload code like the "LED blink" example that would actually work - even when I could not get my LCD based example code to display anything (from which I had earlier had the impression that the complete device might be crashed). It seems that the LCD's "crashed" state can last for a while and it even persists when the power supply is disconnected for some seconds..
So the root cause here might actually be I2C related - or whatever puts the LCD in that "crashed" state.