Recently I have been asked a lot about the RAM memory in GPRS TC65 and XT65 modules (and their corresponding terminals) so I am going to post a small article relating to this topic.

As you know the TC65 module has a total of 400Kb of RAM memory and 1.7MB of FLASH memory. Obviously the FLASH memory, FFS (File Flash System) will be occupied partly by your Java application (i.e. .jad and .jar files) and by all extra files needed for your application as well as files generated by your Java application i.e. log files, history etc.

Blog de Electrónica Avanzada

Well… I can make a huge program with 1.7Mb and still have some leftover so why am I wasting time reading this? 

It’s true that you can make pretty large programs but it will depend a lot on how you do it and what tools you are using. If your program isn’t put together well you may have serious problems with your memory.

Wow I don’t understand, when I ran my Java application it says “out of memory”, it was working before. The only thing that I have done is add a few more codes. My .jar file occupies 150Kb and I see that the bigger my .jar file, the less RAM memory is free. How is that possible? But the program isn’t in the flash memory and isn’t the 400Kb of RAM exclusively for my application’s variables and data? 

Obviously not, obviously your .jar and .jad files are in your flash memory, if not it would be deleted when you turn the modem off. But he thinks that the .jar file is a zip file (you can open it with winrar if you want) and the bytecodes, files, .class and the compiled Java code files are inside it. The modem will unzip these files and load what is necessary onto the RAM memory. Therefore the bigger your Java program, the less free space you will have in your RAM memory (or not, depending on your programming).

If for example you are old school and despite allowing Java object orientated programming language, you do linear programming, type C programming this means that if your application consists of a single, huge .java file filled with methods (which you will see as functions of C), you could have serious problems as your application grows. If you work in that way, when you boot up your Java application, you are going to have to load the entire program code permanently in the RAM memory and you could have serious problems with your memory in the long term.

The best way to save yourself from those problems is to use structured programming i.e. object oriented programming. Before you write your code map, structure you application into objects creating a .java file (and therefore a .class file) for each of your application’s objects. This way you will only load small .class files onto memory when needed by your application i.e. you create a certain object when you need it and destroy it when you don’t or you free up memory when you no longer need the object stored. If you make a huge, single .java file program you will have the entire code and all of the methods whether they are necessary or not stored in your memory at any given time.

It’s too late… I’ve already made my application and I’ve got memory problems. I can’t do it all again, it would take weeks and my boss would kill me. Can I do anything? 

You’re in luck, yes (but when you make another application, structure it better). You can use a Java obfuscator. For example, to obfuscate the compiled code is to compress .class files even further. In fact, if you create a package through an obfuscator you will see how the .jar file occupies a lot less space, even half. This is going to give you an advantage as your won’t have to redo the entire application but I recommend more structured programming in the future.

Which obfuscator do you use? 

Personally I use the integrated Proguard in Eclipse. Another day I’ll talk about it in more depth in an article, that’s it for today.

Today is Saturday, let’s see I will finish an outstanding project that I have never had chance to finish off as I have been overworked lately. It’s a little online project that I launched a few days ago in the domain:, a portal for rental apartments, as the name indicates in Spanish.

The truth is that it’s one of the best domain names that I have (and I have more than a hundred). I say that it’s the “Great Reserve of 2002” as that was the year that I acquired the domain. Over the years, I have nearly sold it on several occasions as I have received a few offers to buy it. The last offer was 3,000€ which made me hesitate but finally, seeing as it’s in the yard of the Spanish house that I made, the rent will increase, so I kept it. Time will tell if I did the right thing.

I hope you have a great weekend. ;)

Post relacionados:

  1. Using Flash correctly with Cinterion TC65 and XT65 modems On many occasions, we may need to use the FFS (File Flash...
  2. Locating Difficult Reproduction Failures in TC65/XT65 Cinterion Modems If you develop applications in Java for GPRS TC65, XT65 (or their MTX65 or MTX65+G terminals...
  3. Java FTP example for Cinterion GPRS modems TC65 and XT65 You will possibly at some point have to make a...
  4. J2ME File Compression in Siemens TC65 GPRS Modems With lots of GPRS modem applications, data needs to be...
  5. Adding Data to Files from Java with Siemens-Cinterion Modems On several occasions I have been asked how to add...

Tags: , , , ,
8 Responses to “Ram and Flash Memory in TC65 and XT65 modems”
  1. Ernesto says:

    Cuidado con los ofuscadores y la reflection …

  2. Victor says:

    Hola Blogelectronica!

    Antes de nada quería felicitarte por el esplendido trabajo que haces en este blog!

    Te comento una duda a ver si me puedes orientar:
    Necesito almacenar unos parámetros en la memoria flash del tc65 y que se mantengan aunque se apague el equipo. Estos parámetros son contadores, teléfonos autorizados o variables de control que pueden cambiar una vez grabado el .jar.
    ¿Cómo puedo mantenerlos?¿tengo que crear un archivo para almacenarlos en memoria?

    Gracias de antemano.

    Un saludo!

    PD: no se si este es el lugar mas adecuado para la pregunta.

  3. Jose says:

    De nuevo, felicitaciones por tu blog precioso.

    Una pregunta que tengo sobre el flash: es cierto que esta memoria
    tiene un número limitado de lectura / escritura 100.000 veces?
    En situaciones que nuestro aplicación JAR hace un registro de varias veces al día puede ser muy problemático.

    Me pregunto cuál es su opinión.

    • blogElectronica says:

      Hola Jose, es cierto.

      Pero no es cosa de esta memoria, en general una memoria FLASH tiene un límite de 100.000 escrituras.

      Pero no te preocupes, obviamente los algoritmos de escritura de los módems Cinterion en memoria FLASH hacen que no se guarden los datos en el mismo lugar, sino que se va distribuyendo equitativamente por toda la memoria flash. Es decir, que en la práctica podrás hacer muchas más escrituras. Lo único que tienes que tener presente, es usar la memoria flash tal y como te indico en este post, NUNCA borrar ficheros de LOG, siempre sobreescribir.


  4. Abraham0208 says:

    Hola Jose

    Oye nuevamente con una duda sobre la flash files system, una vez que me carca el error como puedo liberar el espacio?? por que apago el modulo pero no se libera he notado que si se libera pero pasando mucho tiempo.

    Creo saber por que es pero no se como solucionarlo una vez que sale y no esperar mucho para que se libere.

    Como le puedo hacer???

    hay algún comando que desde la Hyperterminal pueda ejecutar y que se me libere??


    • blogElectronica says:

      Hola Abraham,

      entiendo que te refieres a la memoria RAM, no FLASH. Para liberar un poco más rápido la memoria RAM puedes pasar más a menudo el garbage collector llamando desde tu programa a System.gc();


Leave a Reply

Puedes publicar un comentario aquí si quieres, pero te recomiendo que uses el nuevo para introducir comentarios. Te contestaré más rápido. Recuerda que debes registrarte si no lo estás para publicar un comentario.