“Gesloopte” NodeMCU weer herstellen

Gisteren heb ik klaarblijkelijk twee NodeMCU’s “gesloopt”. De eerste wilde niet meer reageren door een combinatie van de automatisch ladende init.lua en een programmeerfout die de NodeMCU na een halve seconde deed herstarten. Normaal voldoet dan het opnieuw laden van de firmware, maar na het opwaarderen van de firmware ging de blauwe LED van de ESP12 in hoog tempo knipperen en spuwde met een baudrate van 74880 herhaald het volgende bericht uit:

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 26096, room 16 
tail 0
chksum 0x0c
load 0x3ffe8000, len 2232, room 8 
tail 0
chksum 0x7a
load 0x3ffe88b8, len 8, room 8 
tail 0
chksum 0x5f
csum 0x5f
rf_cal[0] !=0x05,is 0xFF

Da’s niet goed. Ik dacht direct aan een elektrisch defect en heb een tweede (nieuwe, goed werkende maar met een verkeerde firmware) NodeMCU voorzien van dezelfde firmware. En ook deze gaf “de blauwe flitsende LED ter bevestiging van een totale ondergang”. Zucht. En dat kost je dan een halve dag om dat uit te zoeken. Ik heb, na het halve internet te consulteren, de volgende dingen tevergeefs geprobeerd om de boel weer opnieuw aan de gang te krijgen:

  • Het 4MB flashgeheugen eerst volledig wissen met
    python ./esptool.py --port=/dev/cu.wchusbserial1420
     erase_flash
  • Andere firmware laten aanmaken via de NodeMCU custom firmware build service en die installeren
  • Andere instellingen voor de flasher gebruikt: de gebruikte NodeMCU’s hebben 4MB flashgeheugen (32mbit) en werken met de “Dual IO SPI” (DIO) flash methode, maar toch maar met andere instellingen geprobeerd, zoals 4m en “detect”; flashmode veranderd van dio naar qio
  • Andere USB kabel
  • Eerst een niet-NodeMCU firmware geladen, zoals de oorspronkelijke boot_v1.1.bin. Deze deed het prima en maakte na het booten een sprong naar het
  • Andere firmware flasher (ik gebruikte esptool.py onder OS X, maar heb een Windows tool van electrodragon geprobeerd onder Windows 10 op de PC

Uiteindelijk bleek de oplossing erg simpel en bleek het probleem goed gedocumenteerd, echter zonder het noemen van de symptomen. In het 4MB geheugen van de NodeMCU zijn blokken voor zowel de firmware als voor instellingen gereserveerd. Deze instellingen hangen samen met de versie van de ESP12. De firmware en de instellingen hebben een grote samenhang en blijkbaar zat daar iets in verkeerd. Door het uploaden van instellingen die beter bij de master build van de NodeMCU firmware passen, namelijk die uit SDK patch 1.5.4.1, kon ik de NodeMCU weer terug naar het land der levenden brengen. Bij het laden van die instellingen nog even om de juiste parameters van het esptool.py denken, en wel specifiek de geheugenplaats 0x3fc000 waar de instellingen moeten landen:

python ./esptool.py --port=/dev/cu.wchusbserial1420 write_flash -fm=dio -fs=32m 0x3fc000 ./esp_init_data_default.bin

En dan de gewenste versie van de firmware (in mijn geval de 20 modules variant met floating point ondersteuning) flashen op geheugenplaats 0x00000:

python ./esptool.py --port=/dev/cu.wchusbserial1420 write_flash -fm=dio -fs=32m 0x00000 ./nodemcu-m20-float.bin

Een van beide NodeMCU’s leek het in eerste instantie niet goed te doen. Toen ik van 74880 bits/seconde overschakelde naar een baudrate van 115200 bits per seconde zag ik de melding “Formatting file system. Please wait…” voorbij komen. Dat duurde een minuutje en vervolgens kwam de melding:

NodeMCU custom build by frightanic.com
	branch: master
	commit: 7b83bbb2ea134cd85ac9d63108603cc02c4e20f7
	SSL: false
	modules: adc,bit,cjson,coap,dht,file,gpio,i2c,mqtt,net,node,ow,pwm,rtctime,sntp,spi,tmr,uart,wifi,ws2812
 build 	built on: 2016-11-25 08:30
 powered by Lua 5.1.4 on SDK 1.5.4.1(39cb9a32)
lua: cannot open init.lua

>

Blijkbaar was de gebruikte Geekcreit Doit NodeMcu voorzien van een oudere versie van de NodeMCU firmware die niet (meer) compatible was met de SPIFFS versie die voor het bestandsbeheer zorgt. Probleem opgelost!