BL602 - More problems with the file system

[delay0]

Today I wanted to create new files. I now have 6 files and already had 7 with content. I couldn't insert any content into file number 8. I thought it might be due to lack of memory. Because when I wanted to insert something into a file and it didn't work, I reduced the number of letters to be added until saving worked. so I shrunk my autoexec. But to do this I had to delete the autoexec and create it again because it could no longer be edited. Now I have a smaller autoexec, but it doesn't change anything. the problem remains. and then the log says something like this...

Error:API:Failed to write to v.bat with error -28 Error:API:Failed to write to 123.txt with error -28

I just made a video and saw that it could somehow have to do with more than 16 bytes.

https://github.com/openshwprojects/OpenBK7231T_App/assets/151743958/a73546bf-bd8a-4d97-a059-9476496140eb

Tested on V1.17.601 and 602

"vendor": "Tuya", "name": "Surplife APP RGB+WW+CW bulb WiFi+BLE E27", "chip": "BL602", "board": "BL-M5 V1.2"

[giedriuslt]

You are likely running out of space. You can see and increase that size using lfs_size command. Please backup your files before doing that, because they WILL BE deleted

[delay0]

I was thinking the same thing. That's why I reduced my autoexec.bat by a few hundred bytes. But after that I could only create a new file with a few bytes. Another one could no longer be saved with content. And to make my autoexec.bat smaller I had to delete it and recreate it. The old file could not be saved, even though it would have had less content. There is more to tell, but I think the error message is the first time I have something that is somewhat meaningful. I didn't have any such problems at the beginning. Maybe this only starts when you do something more with the file system.

lfs_size... Info:CMD:unchanged LFS size 0x8000 configured 0x8000

That's 32KB. I haven't reached more than about 3KB so far.

[giedriuslt]

Regardless, -28 is out of space error. There is file system structures and other metadata which takes space.

[delay0]

Ok, but I can only describe what is happening here. I have now successfully executed lfs_format 0x8000 and copied my files back again. then I created a 123.txt with content 123451234512345. That works. then copied the same series of numbers again and it doesn't work. Again it has to be reduced to 16 bytes for saving to work. All files together currently occupy 2379 bytes.

I can also create several more files with 16 bytes, but none with more than 16 bytes of content.

[openshwprojects]

I am wondering if this filesystem may suffer frm the same thing that old hard drivers do? The fragmentation? It can't alloc new blocks because all blocks are so fragmented there is no space for one continues new...?

[delay0]

In any case, this is the worst defragmentation I know of :D

Another test... Formatted, new file created. This received over 2KB of data directly. Saving works. Then the backup of my files was copied back. Also OK. Then the whole thing starts again. New file max 16 bytes.

New thing... I delete a file to still free up disk space. Then I try to save 17 bytes in one of the existing new files. This works surprisingly. But not 18 and new files only accept 16 bytes again.

[openshwprojects]

i didn't do the lfs porting to bl602, but maybe it could be forfmatedd by command with a bigger size?

[delay0]

I formatted with 0x32000 today. How big is the memory actually? Anyway, it worked and large files can be uploaded. At the moment I can't reproduce any of the errors. But I haven't had any problems for a while and I suspect that formatting didn't fix any errors, it just delayed them from happening again. Now I can only wait and see if I get confirmation. All we can remember is that increasing the size helps at least for a while. Reformatting with the original 0x8000 doesn't help, even though that's far more memory than my files need.