Hi Greg_ZA,
the problem is probably the underlying block driver: the actual flash page is 256 bytes, if cluster size is larger, the block driver needs to be able to split the cluster to multiple page writes.
Make sure this is not the problem. If it is, adjusting the block driver is quite easy.
Cheers
@ Greg_ZA - When you get that exception, can you go back on the call stack to āBlitter::GetStringā and check the content of the buffer being passed in? I suspect that the data is corrupt and outside the ASCII range.
I have recently been experiencing a problem with my module that sometimes the bits are not switching on the device, normally just one bit on a write every so often. I am working on enhancing the file system to be more resilient if the writes fail. My module has seen a lot of use as I have run 24 burn tests etc. so I expect that might be why I am seeing this.
@ maoli, you are correct, the writes are splitting the data and writing 256 byte at a time if the data exceeds the page size.
I had a look at the buffer before it gets encoded to UTF-8. I can not see anything wrong with the data. It looks like it should be properly encoded to UTF-8. I will try to investigate this further.
@ taylorza:
[em]I have recently been experiencing a problem with my module that sometimes the bits are not switching on the device, normally just one bit on a write every so often. I am working on enhancing the file system to be more resilient if the writes fail. My module has seen a lot of use as I have run 24 burn tests etc. so I expect that might be why I am seeing this.[/em]
Actually, I have seen the exact problem. Hours of debugging showed some bits where just not flipping. It turned out to be a defective flash ship. I worked around by implementing a read after write at the block driver. If some error happens, a delegate is fired so the app can respond accordingly.
Adding this to the FileSystem as a configurable option seems to make a lot of sense.
Interestingly, the flash chip I saw this on, is supposed to indicate write failures in the status register. But even though the module was clearly behaving wrong, the status register did not indicate so. So it seems that (for at least some modules) reading after a write is the only realy reliable option.
Cheers.
@ maoli - That is exactly what I am getting, the status register indicates that the write succeed but randomly some bits are not being flipped. Thank you for confirming that, I have been pouring over the code to see if I am donāt something silly so it is great to have independent confirmation.
I have been playing with a few ideas to make it more resilient and I will defnatly include your suggestion to raise an event to the application, thanks.
Hi, IĀ“m using your filesystem code and it works so fine 
Thks for sharing it!!! ,
Iām using it with a g120 and a microship Flash Memory āSST26VF064Bā, I changed the MXā¦BlockDriver for a SST26VF064BBlockDriver and everything is cool, except for one thingā¦ Iām implementing this in a plattformthat it requires to be reset everydayā¦ or it can loose the supply power ā¦so everytime I restart it a need to Format and Mount again and Iām loosing the informationā¦ do you know if this ca be fixed? I tried a lot of thingsā¦ but anyone works ā¦
You should not need to format after each restart. You should only need to format the first time you use the file system on the flash device and after that you just need to mount the file system. If that is not working for you, you should confirm that you are using the latest version of the code. If you are using the latest version of the code, it might help if you create a little test program that demonstrates the problem and I will gladly take a look.
@ taylorza - thanks for TFS, it works a treat! I am using to store webpages to FRAM.
To load the webpages I am sending them from the PC over a serial port. Text files load in fine, but graphics seem to be not saving correctly. After some brief investigation (downloading the file after it was saved to FRAM and comparing to the original) it looks as though a number of bytes, especially NULL bytes are not being written.
Also, Iāve noticed that if the text files (html pages, CSS, .js, etc) are not saved in UTF-8 encoding similar errors occur.
Is this a limitation of TFS, or is there something Iām doing incorrectly?
Thanks again for the awesome library!
Hi;
Your FileSystem has been working greatly for us; we are using AT25DF641A from Atmel.
Atmel has since sold there flash business to Adesto. Then Adesto comes up with the same part AT25DF641A but which unfortunately does not work at all.
Although the two version are said to be identical but that not really true. The Adesto chip additionally requires data to be update only if it has been previously erased (All bits 1s)
The quote below is from the datasheet and I beleive that were the nightmare comes:
The internal programming operation of the AT25DF641A occurs on a nibble-wide basis, and all four bits of
the nibble must be in an erased state (Logic 1 state) prior to the programming of any of the four bits.
What I would like to know if we can still write a IBlockDriver to support that? Or do we need to alter the filesystem codes? Please help!
Hi Chapre,
I am glad that the code has been useful to you.
I took a quick look at the datasheet for the part you mentioned and unfortunately it does look like they do not support multiple writes to take place within a single nibble. The TinyFileSystem is designed to update the status of a block by programming individual bits as the state of a cluster changes, so as it stands I do not believe you could easily write a block driver for the part you are using.
I have not looked at this in detail, but since the only part of the file system that relies on this capability to program the same byte more than once is the tracking of the cluster status. This is currently a single byte that transitions through one of four values, FFh, 7Fh, 3Fh, 1Fh, so it might be possible to split this over 2 bytes and use separate nibbles to track the status and get the file system to function with your device.
But again, I have not looked deeply into this.
Let me know if you want to explore that option further.
Hi taylorza;
Thanks for quick response.
We are fine exploring the further option proposed.
An additional question that I have, When opening and updating a file, does the code overwrite always the same location in the flash or does it dynamically fetch an unused location where the update file will be stored?
Thanks,
Hi,
When modifying data in the file, the modified data is always written to a new location and the location with the previous version of the data is flagged as unused. This ensures that even if you update the same location of a file over and over you will not wear that area of the flash. When the file system runs out of space to write to a new location it will initiate a garbage collection, where all the available locations are gathered and compacted.
Let me know if you need more detail.