nodemcu-firmware: Uploading LFS.img with ESPlorer does not work anymore
Expected behavior
Uploading LFS image using ESPlorer should work.
Actual behavior
The device sometimes reboots and ESPlorer displays
> Uploading to ESP file luac.out...Waiting answer from ESP - Timeout reached. Command aborted.
Test code
This seems to be a problem for binary files only, as a 6K binary file cannot be uploaded but a 60K textfile can.
The code used by ESPlorer to receive the file looks like this:
_up=function(n,l,ll) local cs = 0 local i = 0 print(">".." ") uart.on("data", l, function(b) i = i + 1 file.open("Large File.txt",'a+') file.write(b) file.close() cs=0 for j=1, l do cs = cs + (b:byte(j)*20)%19 end
uart.write(0,"~~~CRC-".."START~~~"..cs.."~~~CRC-".."END~~~") if i == n then uart.on("data") end if i == n-1 and ll>0 then _up(1,ll,ll) end end,0) end file.remove("Large File.txt")
_up(270,250,145)
It then sends n
blocks with the length of l
and one last block with length ll
.
NodeMCU version
NodeMCU 3.0.0.0 branch: dev commit: f3044e1aff432ca48f6511554b317e0c80207d1c release: 2.0.0-master_20170202 +451 release DTS: SSL: false build type: float LFS: 0x0 modules: adc,bit,dht,file,gpio,i2c,mqtt,net,node,ow,spi,tmr,uart,wifi build 2019-11-13 07:09 powered by Lua 5.1.4 on SDK 3.0.1-dev(fce080e)
Hardware
Generic Dev board ESP8266SXD
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 44 (22 by maintainers)
@HHHartmann @seregaxvm, as an aside the downloaded stubs for both the Python
nodemcu-uploader
and the JavaESPlorer
implementation could really do with reworking; e.g. in this second case the code does a file open, append, close per block; this strategy badly fragments the SPIFFS pages compared to just leaving the file open and writing to it serially, in which case the FS buffers the data stream and writes out complete pages. Updating the Python is straightforward, so long as Peter or one of his committers agrees to commit the PR, but doing the Java build is a PITA.Always feeding the UART input through the stdin pipe is reasonably straight forward, but we do have to deal with the two input modes: text for Lua command input (this must correctly process <BS>, <CR> and <LF>) and the raw mode for UART input.