Archive for May, 2009

On many occasions, we may need to use the FFS (File Flash System) from our Cinterion  TC65 or XT65 GPRS modems to transfer data to files. A typical example is the case of the XT65 and GPS positions. We read the GPS positions every X seconds and we store them in a file to send them to the central server later. There are as many of these types of examples for the TC65 as the XT65.

It’s easy to fall into the temptation of generating files in the Flash memory to store information instead of creating files and deleting them when we think that are processed (e.g. when we have sent them to the central server via GPRS or simply erasing them when we no longer need them).

It really is the easiest way to make an application (we create files and delete them when we no longer need them) but you must be careful with this technique. Writing data onto to the Flash memory is no problem, they are saved byte by byte (as Siemens’ FLASH memory is the NOR type, unlike the NAND type you can save bit by bit. With NAND, it’s cheaper but worse as you save in blocks). However the erasing process IS critical because both the NANDs and the NORs are done in blocks. The cluster size in the Flash modem is 64Kb, this means that when we delete a file, really we are erasing a 64Kb block. So although we are deleting a file that only contains 100 bytes of data, in reality it affects the 64Kb in the modem’s Flash memory.

Blog de Electrónica Avanzada

If we consider the fact that it’s possible to save 100.000 records and a TC65’s Flash memory is around 1.7Mb in size. Taking into account that the size of a cluster is 64Kb, it’s not difficult to see that we shouldn’t abuse deleting files. Let’s look at an example, if we create a small 100 byte file and we delete it every minute, approximately every 26 minutes (1.7 / 0.064) we have “seen” all of the flash memory. This means that after 100,000 x 26 = 2,600,000 minutes (or less) we will have almost certainly loaded the flash. Every day has 1440 minutes, a year 365 x 1440 = 525,600 minutes, which means that the 2,600,000 / 525,600 = after 4.9 years our modem would die (or almost certainly before as the modem has internal processes that also write on the flash). Also you have to keep in mind that when we erase a cluster (for example when we erase a 100 byte file that is inside it), the rest of the information that’s in the cluster shouldn’t be erased, the modem’s FFS manager’s internal algorithms have to rewrite the information which shouldn’t be deleted i.e. it wears out the flash more to further minimize the added risk of a power cut at the time of copying.

What can be done then? 

If you want to use files with your Java application, you need to avoid the continuous clearing as stated above. The best way to avoid problems is to create a file in the Flash (or files you need for the application) and try to NEVER delete it. This means for example you create 2 Log1.txt and Log2.txt files and you store records (by records I mean a fixed longitude GPS frame for example).

Let’s imagine that we set a maximum of 5000 records per file. Once we have written 5000 records in Log1.txt, we start to write data in Log2.txt and then we can send Log1.txt to our central server via GPRS. After the Log1.txt sending process, we do NOT delete the file. When we have written 5000 other records in Log2.txt, we start to write in Log1.txt DESTROYING record 1 and so on up to record 5000. The trick is to overwrite records and not delete files. This is a way to really save us from nasty problems over time due to the Flash memory wearing out.

When we are programming on the TC65 and XT65, we must remember that we are working on an embedded module and not on a Core 2 DUO with HHDD. Yes, there are some very powerful modules and when programming in Java with a file system we sometimes lose the perspective of the embedded module, so we must keep it in mind.

I hope you find this post useful, see you next time! ;)

 

Tags: , , , , ,

Comments 18 Comments »