File size Limitation SDK1.4.0 / 1.5.0

[lorenz24]

File size limitation on LUA based on SDK1.4.0

Any file upload bigger than 26857 bytes will stop with a error message
The remaining bytes on the flash are identical with the uploaded data but incomplete.
->When I test it on SDK0.9.6 there is no problem.
The flash size on the ESP-03 module is 1 Mbyte.

I can download many files to the chip, the limitation is only for the file size.

adresse         : 26857 bytes ->failed
feuer.out       : 26857 bytes->failed
glediator file1 : 18624 bytes
muster.out      : 10944 bytes
ws2812-laufbild.lua : 794 bytes

The original file size is: 33,5 KB (34.368 Bytes) file name "

Upload on SDK1.4.0

NodeMCU custom build by frightanic.com
    branch: master
    commit: c8037568571edb5c568c2f8231e4f8ce0683b883
    SSL: false
    modules: node,file,gpio,wifi,net,pwm,i2c,spi,tmr,adc,uart,ow,bit,mqtt,coap,u8g,ws2812,cjson,crypto,rc,dht,ws2801,rtcmem,rtctime,rtcfifo,sntp,bmp085,tsl2561,ucg,enduser_setup,hx711
 build  built on: 2016-01-02 18:16
 powered by Lua 5.1.4 on SDK 1.4.0

lua: cannot open init.lua
> file.format()
format done.
> Uploading to ESP file adresse...Waiting answer from ESP - Timeout reached. Command aborted.

=node.heap()
40792
> 
----------------------------
adresse         : 26857 bytes
----------------------------
Total file(s)   : 1
Total size      : 26857 bytes

> r,u,t=file.fsinfo() print("Total : "..t.." bytes\r\nUsed  : "..u.." bytes\r\nRemain: "..r.." bytes\r\n") r=nil u=nil t=nil
Total : 444521 bytes
Used  : 27610 bytes
Remain: 416911 bytes

Upload on SDK0.9.6

NodeMCU 0.9.6 build 20150704  powered by Lua 5.1.4
lua: cannot open init.lua
> file.format()
format done.
> Uploading to ESP file adresse...Success

> =node.heap()
33640
> 
----------------------------
adresse         : 34368 bytes
----------------------------
Total file(s)   : 1
Total size      : 34368 bytes

> r,u,t=file.fsinfo() print("Total : "..t.." bytes\r\nUsed  : "..u.." bytes\r\nRemain: "..r.." bytes\r\n") r=nil u=nil t=nil
Total : 504761 bytes
Used  : 34889 bytes
Remain: 469872 bytes

Regards

Lorenz

[devsaurus]

Thanks @lorenz24 for bringing this this up in the ESP8266 forums. In the meantime I tried to upload also on a recent 1.5.0 build with same result: 26857 appears to be a magical border. The firmware seems to restart during the upload but I wasn't able to nail down the issue any further.
I'll be off for the next days - any volunteers?

[TerryE]

Have you tried creating a file on the ESP itself just using a file.write() loop? It's just that I'd prefer to decouple Esplorer from this equation. If the write loop works OK, then it's almost certainly a bug with Esplorer and therefore belongs on the Esplorer issues list.

[lorenz24]

Yes I tried it just to double confirm.

I wrote 200 x 192 byte to file name "testfile".
This is the result:

dofile("ws2812-create-leer.lua")
�ü!�ÿ�•œÿ1ä·¤äÎÆJ„vcÃÿÐ

NodeMCU custom build by frightanic.com
........

I got a reset of the module.

testfile : 26857 bytes
should be 38400byte.

I tested it on a ESP-03 with a 1Mbyte flash and on a ESP-12e with 4Mbyte flash
allways same SDK version.

One more information. If I reopen the file and try to add some more data to the file a get
immediately an RESET on the module.

[TerryE]

@lorenz24, thanks. In this case, this supports it being a firmware issue, rather than an Explorer one. However, I've got other priority issues that I am working on, so perhaps one of the other committers or contributors can look at this one?

[danlu01]

I ran into this issue also. Anyone making progress on this? Thanks.

[devsaurus]

I've checked this case with #923 applied and it still crashes with the same symptoms:

• dd if=/dev/zero of=null.bin bs=1024 count=40
• upload null.bin with ESPlorer
• upload stalls at ~65%:
  
  Last log msg prior to error recovery is Uploader: receiving checksum 107/164 check: Success
• firmware resets
• uploaded file size is 26857

Interestingly, I get 2, exception reset as the reset reason:

> Uploading to ESP file null.bin...Waiting answer from ESP - Timeout reached. Command aborted.=node.heap()
44344
> =node.bootreason()
2   2   9   1076243336  0   0   1073671949  0
> 

According to the mapfile, EPC1=0x40262B88 points to

 .text.spiffs_fd_return
                0x40263b64       0x3e spiffs/.output/eagle/debug/lib/spiffs.a(spiffs_nucleus.o)
                0x40263b6c                spiffs_fd_return

and EXCVADDR=0x3FFEEF0D to

.bss.spiffs_work_buf
                0x3ffeef08      0x200 spiffs/.output/eagle/debug/lib/spiffs.a(spiffs.o)

No clue yet what's going wrong...

[jmattsson]

> =node.bootreason()
2 291076243336 0 0 1073671949 0

That "9" is the exception cause, which is EXCCAUSE_UNALIGNED. In short, this looks like yet another case of SPIFFS making faulty assumptions about how it can use its work buffer.

We should probably try to upgrade to the latest SPIFFS and then retest both this and the multiple-write bug scenario. And if any issues remain, chuck them upstream.

[devsaurus]

Ok, we'll see then.

I've isolated ESPlorer's routine to a simple testcase and added error handling, just in case. Though there are no errors reported until the exception is thrown.

b = " "

for i = 1, 8 do
   b = b..b
end

file.remove("test.bin")
for i = 1, 128 do
   if file.open("test.bin",'a+') then
      if file.write(b) then
         file.close()
      else
         print("write failed in iteration "..i)
         break
      end
   else
      print("open failed in iteration "..i)
      break
   end

   tmr.wdclr()
end

[pjsg]

The new version of spiffs fixes this problem. It will be resolved by a PR soon.

[marcelstoer]

Fixed by #1226.