- Wed Nov 19, 2014 10:54 pm
#2959
I've made contact with the chip manufacturer Espressif.
the tmr.delay() issue is caused by watchdog, and so is the long time loop issue.
since Espressif doesn't offer function to init/disable/enable watchdog in SDK, there is little we can do.
they do give me a method to clear the watchdog count.
I have tested it by separate delay time into several 1-second, it worked.
when I delay more than 3 seconds(say 5s), no hardware reset caused,
but a "beacon timeout" occurred, the chip lose connection to AP, and will reconnect to AP, obtain a IP using DHCP, again.
if you have a tcp connection, it will disconnect.
and there is no function to deal with "beacon timer" neither.
Anyway, it's better than hardware reset.
I will release a update soon, fix tmr.delay(), and may add a tmr.wdclr() or something.
scargill wrote:Ernie - I don't agree. That is a function call - I don't think there should be a space where you suggest. If it IS necessary surely that's a bug?
All -
I've done some more tests.
In each case I am blowing the BLANK file and then the nodemcu_512k.bin file just to be sure.
In each case after doing this.. If I send the file below to the unit.. it works... BUT the delay is too short to show the IP address.
When I say WORKS I mean one initial message and one run of the code.
There are TWO things wrong.
Firstly If I then RELOAD the file - subsequent powerup goes wrong - there is something wrong with your file.remove() command
Secondly if I try to change the time delay HERE...
file.writeline([[wifi.sta.config(ssid,pw)]])
file.writeline([[tmr.delay(500000)]])
from half a seconds to 2 seconds....
EITHER by making it longer OR using it 4 times..
i.e.
file.writeline([[wifi.sta.config(ssid,pw)]])
file.writeline([[tmr.delay(2000000)]])
or
file.writeline([[wifi.sta.config(ssid,pw)]])
file.writeline([[tmr.delay(500000)]])
file.writeline([[tmr.delay(500000)]])
file.writeline([[tmr.delay(500000)]])
file.writeline([[tmr.delay(500000)]])
Either way this FAILS and the unit ends up in a loop - Am I right in guessing this is some kind of WATCHDOG issue?
Is it possible to fix these two issues - we are SO CLOSE!!
file.remove("init.lua")
file.open("init.lua","w")
file.writeline([[print("Petes Tester 4")]])
file.writeline([[tmr.alarm(15000, 0, function() dofile("thelot.lua") end )]])
file.close()
file.remove("thelot.lua")
file.open("thelot.lua","w")
file.writeline([[print("Stopping timer")]])
file.writeline([[tmr.stop()]])
file.writeline([[tmr.delay(500000)]])
file.writeline([[print("creating function")]])
file.writeline([[connecttoap = function (ssid,pw)]])
file.writeline([[print(wifi.sta.getip())]])
file.writeline([[wifi.setmode(wifi.STATION)]])
file.writeline([[tmr.delay(500000)]])
file.writeline([[wifi.sta.config(ssid,pw)]])
file.writeline([[tmr.delay(500000)]])
file.writeline([[print("Connected to ",ssid," as ",wifi.sta.getip())]])
file.writeline([[end]])
file.writeline([[print("Running function")]])
file.writeline([[connecttoap("loft-east","1921681974")]])
file.writeline([[print("Done")]])
file.close()
I've made contact with the chip manufacturer Espressif.
the tmr.delay() issue is caused by watchdog, and so is the long time loop issue.
since Espressif doesn't offer function to init/disable/enable watchdog in SDK, there is little we can do.
they do give me a method to clear the watchdog count.
I have tested it by separate delay time into several 1-second, it worked.
when I delay more than 3 seconds(say 5s), no hardware reset caused,
but a "beacon timeout" occurred, the chip lose connection to AP, and will reconnect to AP, obtain a IP using DHCP, again.
if you have a tcp connection, it will disconnect.
and there is no function to deal with "beacon timer" neither.
Anyway, it's better than hardware reset.
I will release a update soon, fix tmr.delay(), and may add a tmr.wdclr() or something.
