ESP8266 NodeMCU v3 - BUSY module, problem with flash memory after many cycles

Hello, have you perhaps encountered a problem with ESP8266 modules and their flash memory ? I'm starting to get to know these modules (I have a ready-made NodeMCU v2 with USB and a dedicated 3v3 power supply on board, I'm uploading firmware that supports lua scripts and using the module's controller capabilities, as this is enough for many things, without an arduino) but things are weird with the memories, i.e. one of the module's FLASH memories "crashed" after a few hundred software upload cycles (I was writing various scripts and generally speaking "playing" with this little box) - at some point during one of those flashings the module went completely stupid, it was throwing errors, bushes in the ESPlorer monitor, it started resetting and only came to an end after soldering another flash from the second module...

Another problem popped up is that the program works but I can no longer upload anything new / different - ESPlorer claims when trying to enter a new script that the module is busy (BUSY) and neither reset nor format helps, uploading new firmware can be done and wake it up in AT command mode but when trying to upload LUA again the same problem happens - so something strange is going on with these modules. Has anyone had a similar effect ?

Unfortunately, the memories are flying. Replacement is not worthwhile. I already have two such modules, and I have well over 1,000 of them in circulation, in the damaged modules I used SD cards instead of memory bones. They serve as servers with a large database of information.

i found the memory cubes at a wholesaler , the price is quite bearable , don't you want to sell your broken modules at the price of scrap metal ?

As above, if the Flash fails I insert SD cards instead of the dice, I have a full Refurbisch

@piotr411 could you describe how the module works afterwards?

Exactly the same as with flash memory. It works reading and writing slightly slower. As I have tiny files ranging from a few bytes to a maximum of 3kb, this has absolutely no effect on the perceptibly slower operation of the ESP. The card is seen as standard Flash.

and you want to solder the SD port to the module ? because I guess the lines for working with serial flash are dedicated and not brought out ?

@Adrian1978 Depends on module version.
@piotr411 So just unsolder the EEPROM connect the SDIO lines and you can program with the bootloader?

@piotr411 I see that you upload various tutorials for ESP. Maybe you could do a quick tutorial like this for beginners - how to get started?

This was/is the intention, from the beginning with the NodeMCU LUA environment in mind, to provide simple examples for popular layouts. This is supposed to be part of a larger project, which, with enough time and enthusiasm, will see the light of day. This is also the reason for blocking topics, so that in time I can add interesting realised projects or parts of them under specific modules, as well as point out some nuances of ESP LUA. I try to write most of the applications so that they work on any firmware, i.e. without using special modules, and also so that over time they can be easily ported to ESP BASIC, which is unique in its own way. I spent hours looking for simple examples on the Internet, but unfortunately the authors usually abandon the topics and there were no concrete solutions, or the examples were heavily overgrown and "plucking" parts of the code from them was difficult, so from scratch, I created my own basic database of examples, which as functions can be used for larger projects.

Hello , the BUSY issue has cleared up - I actually had all the resources used up and the module controller was issuing busy. After correcting the script it is working.

However, another bizarre issue - namely PWMs set on specific GPIO lines are generated ... but not on those pins that are declared (sic!) - I'm using ESP8266-12E modules now, the ones with the sheet metal on and solder fields even on the edge opposite to the antenna, and there's some hiccups... i have downloaded the circulating information about these modules and their pinout on the net , the most real is the one I add to this message, all nice but ....

My code which generates 3 PWM but partly on legs which , if the pinout picture is to be believed should not act as PWM :

pwm.setup(4, 1000, 005) --initialisation of the PWM output on leg GPIO04
pwm.setup(5, 1000, 005) --initialisation of PWM output on GPIO05 leg
pwm.setup(12, 1000, 005) --initialisation of the PWM output on GPIO12 leg

and PWM are generated for me, yes... but on the legs of the module labelled GPIO02, 10, 14 - a complete mystery.

Some vendors state that this module has the ability to generate PWM waveforms on all available GPIOs, but it doesn't work for me, and trying to run PWM on any GPIO above number 12 gives me an error when uploading the script to the module in ESPlorer, as if the uploaded firmware doesn't have these GPIO declarations that the module has them at all.

I thought maybe I generated the firmware wrong, but on the website where it is done (http://nodemcu-build.com/) there is no option to select the module model, which means it should work with both ESP8266-01 and ESP8266-12 modules and any module with this chip.

Can you explain this GPIO phenomenon ?

Lua has a pinology not like the ESP8266 12, but the NodeMCU V3. In principle it is logical since you have won the NodeMCU firmware, you should use such documentation.

Take a look at the description of pins D0 to D10 and everything will be clear. This is exactly the same problem you can encounter with the Arduino

Link

Thank you Peter , I will check right away

PWM as well as gpio.serout() can be defined on ports D0 to D10 - you can find what GPIO is assigned to the corresponding D in the link above. You can also define a software UART on any port, etc.... LUA is very flexible here.

Peter , did the DHT-11 work for you ? using the lua firmware ? I've compiled firmware with DHT support and floating point number support, I've written the script according to what the creators of these components themselves suggest, and unfortunately it won't talk yet - I've got a response timeout from the sensor all the time. The connection is OK, everything is physically OK, the sensor is new, the oscillogram shows that the ESP wants to poll the DHT sensor and the sensor itself is transmitting something (I've tested it now and in the absence of DHT it is low, the pin is high and then low again, and when DHT is connected then after the low call data from DHT is transmitted, so it sends data) - but unfortunately all the time the DHT poll function returns "sensor timeout" as if this part of the uploaded firmware was not working.

Below is a fragment of my script :



Unfortunately I have a timeout all the time.

You are definitely connected to D5=GPIO14

yes, the DHT is connected to GPIO14 which is the leg described on the nodeMCU module (Amica) as D5. All in all, the oscillogram confirms this - the moment I try to poll the DHT it jumps low on the expected leg , then lets go high for a moment and low again. If you look closely, there is data from the DHT sensor at the location of this pin. But the firmware , even though it is supposed to contain DHT support does not see this sensor

Added after 53 [seconds]:

i will try in a moment to rewire , out of pure curiosity on D2 that is GPIO04.

Added after 8 [minutes]:

unfortunately , nothing. when I comment out the status check condition and tell it to send the sensor data it has read via the UART anyway, I get a temperature of -999 and a humidity of -999 as well, which is probably from what I recall the values substituted in the library as start values

That is, the DHT function, is not working properly. Give me a few days, I have 3 pcs of DHT11 at home, I will write a new function I will send the ready. No time to play for now.

It looks like this. Out of curiosity I pasted the script described on the page Link and the sensor is read but the data is completely unreliable, once it shows the temperature of 3 degrees, in a second 52 degrees, the same with humidity. The author uses this code for DHT11, but this is a de facto script for DHT22, something occurred to me that the handling of DHT11 is different, maybe that is why it does not want to read the measured values correctly.