TC65 Flash Corruption

[Ricardo Guilherme Schmidt]

Florent Clairambault said:
- TC65 uses flash and any flash memory is limited to a limited
number of R/W cycles. This is true for any usb key or the latest
SSD drive. SSD drives isolate corrupted sectors and they have a
lot of space. TC65 flash memory doesn't have a lot of space and
I'm not sure the filesystem can isolated corrupted sectors. Some
equipments are supposed to work for years (or even decades),
having a memory that is very likely to get corrupted in the
first 3 years isn't a good choice. Example : If your write
something each 15 minutes on the chip. It means you will do
60/15 * 24 * 30 * 12 = 34 560 R/W cycles per year. Meaning
you're chip is likely to live 100 000 / 34 560 = 2.9 years. Now
you've written on your chip "as much as you like", let's say
every minutes. It makes : 60 * 24 * 30 = 43 200 R/W cycles per
month. And well, your chip shouldn't last more than 100 000 / 43
200 = 2.3 months. I'm not sure everybody will be pleased with
this situation. But well, you can still say "chips just
die...".

yes, the Chips just dies if you write too much on their memory, we got
some of them dead here, and Cinterion wont give guarantee for that kind
of problem, we just tried with like 10 modules. They say is bad use,
anyway is not in the documentation telling explicit "Don't write a lot
in flash", but they claim users fault, saying the problem is "corrupted
flash memory".
Other developers have also reported the same problem. I'm sad to tell
that there is no solve for that, we need to avoid the writing.

I try my best to write the less possible in this chips and in my hands
none ever died so far, but in my brother a lot of them just stopped
working.. Some with like 3 hours of use. It surely don't had the 100000
R/W operations, but no chip exchange from Cinterion.

[Florent Clairambault]

Hi Ricardo,

    That's pretty interesting. Did you do some complete diagnostics on the dead chips, like what AT commands can still be executed, if the java program can still run sometimes. What were the exact errors? What were the versions of the chip that died? I'm really interested by the error as it help everyone diagnose their own.

    You're right about the writing, but the problem is that some clients absolutely want to have their data saved and some don't want to put a battery (it helps a lot because you can choose to only write stuffs when you run out of battery [even the destroyApp lets you 5 seconds to save everything]). And I have to say that I've deployed some programs that only write in some specific situations and they don't seem to have harmed their host chip as they still work.

    By the way, the group is more than 1 year old (I missed the birthday) and has 63 members. That's not much but a lot more than what I expected when I created it.

Best regards,
--
Florent Clairambault

--
You received this message because you are subscribed to the Google Groups "Cinterion Java enabled chips support" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javacint+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javacint?hl=en.

[John van Drunen]

I haven't experienced flash wear so far. Some of the devices I use
must have been written to for 150000 times and are still running
happily. But keep in mind that it is not the reading or even the
writing that causes flash wear. It is the erasing of flash memory that
causes the wear.

So the amount of wear that will occur also depends a lot on how the
TC65 manages its flash memory. I wish I knew more details about it. It
could be very well that if you are writing to a small file of say 1kB
and are writing updates to this file every 15 minutes that the flash
controller of the TC65 does not really overwrite the old file but just
chooses a different position in the flash memory to write the updated
information. So in that case with 1.7MB flash available it is still
possible to frequently write data to the flash memory before a block
of memory needs to be erased. A lot depends on how smart the flash
memory is managed.

[Florent Clairambault]

Hi Johh,

    It looks like people are getting very interested by the write thing. Flash memory requires to be erased before we can write on it. And it's done by erasing the whole block. So writing means erasing.

Source : http://sources.redhat.com/jffs2/jffs2.pdf : "These types of flash share their most important characteristics | each bit in a clean flash chip will be set to a logical one, and can be set to zero by a write operation. Flash chips are arranged into blocks which are typically 128KiB on NOR flash and 8KiB on NAND fash. Resetting bits from zero to one cannot be done individually, but only by resetting (or erasing) a complete block. The lifetime of a flash chip is measured in such erase cycles, with the typical lifetime being 100,000 erases per block. To ensure that no one erase block reaches this limit before the rest of the chip, most users of flash chips attempt to ensure that erase cycles are evenly distributed around the flash; a process known as wear levelling".

We could reach a number of 1 000 000 writes on the device if there's a fine wear levelling but the idea for me is to define the worst case scenario. We can't really build programs that "should" work for a long time. Wear leveling mechanism can't provide any guarantee.

The 100 000 write limit seems like a pretty reasonable number we should stick too when trying to define the good practices about writing.

Yes John, we can't be too confident on how the chip manages its memory. And yes, this is well explained from the JFFS2 document too : there can been two layers of wear leveling :hardware through a translation layer (the host hardware sees the same block but it is written at a different physical space) and software through the filesystem (jffs2 for instance uses a new inode for each write and just garbage-collects old ones).

As you said, 1.7 MB is plenty of space, we could destroy 50% of it with corrupted and still be happy with it.

BUT, we currently don't know how the TC65 chip manages its memory. So we might as well stick with the max 100 000 write operations. 

If someone know the answer, he's very welcomed to the discussion. Because this is somehow an unsolved matter. As a TC65i developer, I can't guarantee how long the memory should last to clients that want / require some frequent writes.

Best regards,

--

Florent Clairambault

--