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)

Most upvoted comments

@HHHartmann @seregaxvm, as an aside the downloaded stubs for both the Python nodemcu-uploader and the Java ESPlorer 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.