Locating Difficult Reproduction Failures in TC65/XT65 Cinterion Modems
Posted by blogElectronica in 2.DISPOSITIVOS (práctico), 4.PROGRAMACIÓN, Comunic. GSM/GPRSIf you develop applications in Java for GPRS TC65, XT65 (or their MTX65 or MTX65+G terminals distributed by Matrix), perhaps you will be interested in debugging your application on occasion in the way that I’m going to show you here.
What happens (or what should happen) at the end of any development program is that there is a test phase, a phase where you must thoroughly test the application for any type of error that could have been made. If there are errors in our application, they are easily reproducible so we will find them relatively easily. But occasionally there are errors that are caused by an accumulation of things or due to some very specific situations which are not reproduced in the laboratory but they are in the street.
Debugging such problems can be really tricky, when they occasionally occur they are very difficult to locate.
One way to try and find out what happens with a program could be having a HyperTerminal connected to the serial port to save the errors that we are going to receive via System.out.println, but it doesn’t seem to be the most suitable method for every situation, right? It’s a little contraption if we have to put a PC in a car, in a vending machine or wherever our modem is…
An alternative method that we can use with Siemens/Cinterion modems is redirecting the standard output to a file i.e. instead of receiving the errors through the device’s serial port (to do a System.out.println), they will be thrown into a log text file in the modem’s flash memory. This way, when something strange occurs we can see it in the log and try to see which method or part of the program is going wrong. It’s very useful.
So how do we do this?
We do it with the super command AT^SCFG. With this command you can specify the standard output destination (in this case we will define a file, the file size, the file name and the storage mode).
When we define the file size you need to keep in mind that two files are actually created. For example, if the file name is log.txt, log.txt.0 and log.txt.1 will be created. When log.txt.0 reaches half of the size that we have specified, it starts to write in log.txt.1. Similarly, when log.txt.1 reaches half of its specified size, log.txt.0 will be overwritten and so on. They will take it in turns.
As for storage, we have two modes: “buffered” and “secure”. With “buffered” the output isn’t directly written in the flash, instead it is temporarily stored in an intermediate buffer (in RAM) and when the timer rings the data is saved in the Flash. In “secure” mode it’s directly written onto the Flash. It depends on the type of situation and the severity of the problem whether we should use one mode or another.
Do you have any examples?
Of course, configure the modem with:
AT^SCFG=”Userware/Stdout”,”FILE”,20000,”a:/log.txt”,”secure”
If afterwards (at any time) we do this from our Java application:
…
System.out.println(“Hola”);
…
we will see in A:/log.txt.0 that we have the “Hola”.
Well, I’ll be back on another day. I hope that this helps someone out who has trouble finding errors. Now I’m going to do one of my least favourite tasks of the year, the income. And to think that there are some people who like doing it… (I know a couple)
Post relacionados:
- Java FTP example for Cinterion GPRS modems TC65 and XT65 You will possibly at some point have to make a...
- Using Flash correctly with Cinterion TC65 and XT65 modems On many occasions, we may need to use the FFS (File Flash...
- Ram and Flash Memory in TC65 and XT65 modems Recently I have been asked a lot about the RAM...
- Adding Data to Files from Java with Siemens-Cinterion Modems On several occasions I have been asked how to add...
- J2ME File Compression in Siemens TC65 GPRS Modems With lots of GPRS modem applications, data needs to be...
Tags: cinterion, j2me, java, mtx65, mtx65+g, Siemens, tc65, xt65
hola
Se puede redirgir la salida estandard a un socket, para poder debugear a distancia?
Salu2
Pua
si, si se puede
try{
//your code here
}
catch(exception ex)
{
fnSendBySocket(ex.message());
}
fnSendBySocket(String strMsg)
{
Global_InputStream.write(strMsg.getBytes());
}
Con algunos errores de sintaxis ¬¬