Florent Clairambault

Ricardo Schmidt made a great multi-platform TC65 control and file management tool called JOBextFTP. This can be used for anyone whose Module Exchange Suite (MES) doesn’t work or doesn’t work correctly.

The biggest effort is put on managing the OBEX file transmission protocol, but it also does offer some simple methods that can be integrated in your development process, like “turnOn”, “turnOff”, “getTime”, “runApp”.

I’m really sorry but I didn’t take the time to test it as I’m currently not making some TC65 development. But it looks very operational to me.

Maybe I should start a list of useful TC65 applications. I can already see this one to help you deploy programs and files locally and my SMSOTAP to help you deploy programs remotely.

Here is the email Ricardo Schmidt sent me :
I modified and formated some parts of the original mail.

When you want to locally deploy software on your TC65 chip, you need the Module Exchange Suite (MES). If it doesn’t work, it won’t tell you why, finding out why can be quite tricky.

If you want to find out why the communication with your TC65 failed, the best way is to use the portmon tool and see what is exchanged between the MESServer.exe and the chip.

I collected 3 portmon captures that could help you diagnose your MES communication problems :

• Here is a successful MES files listing at 19200 bps. You can see that it sends the “AT+CGMM” at different bit rates unless it gets a good response. Then it sets some serial communication options. And then it sends the “AT^SQWE=100″ commands which fails and then establish a successful link using the “AT^SQWE=3″ command.
• Here a failed MES file listing. Here, after the “”AT^SQWE=3″” is sent, MES sends a 26 bytes message and receives a 41 bytes message from the chip. Then it should request the file listing. But here, MES doesn’t request anything. Maybe MES doesn’t work well, or maybe the reply from the chip doesn’t satisfy his requirements.
  Anyway, after that it should send a 27 bytes message containing : “x-obex/folder-listing”, and it should get the file listing. But it doesn’t. It reads on the serial port like if it was still waiting for something. And finally, it closes the connection (with “+++”).
• Here a totally failed communication. Here it’s because the modem gets stuck on waiting for the modem hardware flow control (“IOCTL_SERIAL_GET_MODEMSTATUS”) when it’s only a 3 wires (TX,RX,GND) communication. So MES never reads or writes anything.

If you have the same kind of problem, you can send me your portmon capture file.

I have just made a little update to the SMSOTAP program so that the little message generation wizzard can add the NETUSER and NETPWD parameters in the OTAP SM sent to the TC65. Thank you John for this little feature request. This pretty useful, without it you could end up adding a new SM and editing each message.

By the way, I have tested this program on Linux with mono and it works fine.

You might have faced this error with your X765 chip. The program crashes with this error :

1
2
3

^EXIT 00010000,02d6414253485f4c434c2c70726f6365647572655265636f72645f702d3e6e756d6265724f66526567697374657265645461736b73203c3d204d41585f4e4f5f524547495354455245445f5441534b53
 
^SHUTDOWN

If you convert the hex array to some text, that will give you :

1

#ABSH_LCL,procedureRecord_p->numberOfRegisteredTasks <= MAX_NO_REGISTERED_TASKS

Which might mean something to someone. But the point is, you won’t find any help. Mostly because it’s an uncommon error.

The error comes from the GPRS connection management. I had it when I was using a wrong APN (with the “AT^SJNET” command) to connect to a host. In my program, connection failed with a classic IOException (“Profile not found”) but 1 or 2 minutes later, the chip was ALWAYS crashed (with the “^EXIT” URC). So, the only solution I found to correct this problem was to automatically detect which APN is required.

This might also improve the ease of deployment of your programs. I like putting as much as possible auto-detection / auto-configuration code as possible. It takes a little time to write it but saves a lot of troubles (last minute configuration, human errors, human explanations, etc.).

The APN auto-detection code is like that :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

public static String AutoDetectApn( ATCommand atc ) {
 
    String[] apnList = {
        "\"gprs\",\"objcobytel.com\",\"\",\"\",\"88.191.11.20\",0", // Bouygues Telecom : "Objet communiquant" / "ObjetCo" / "ObjCo"
        "\"gprs\",\"m2minternet\",\"\",\"\",\"88.191.11.20\",0",
        "\"gprs\",\"internet-entreprise\",\"orange\",\"orange\",\"88.191.11.20\",0",
        "\"gprs\",\"a2bouygtel.com\",\"\",\"\",\"88.191.11.20\",0",
        "\"gprs\",\"b2bouygtel.com\",\"\",\"\",\"88.191.11.20\",0",
        "\"gprs\",\"ebouygtel.com\",\"\",\"\",\"88.191.11.20\",0",
        "\"gprs\",\"movistar.es\",\"movistar\",\"movistar\",\"88.191.11.20\",0",
        "\"gprs\",\"orange\",\"orange\",\"orange\",\"88.191.11.20\",0",
        "\"gprs\",\"orange.fr\",\"orange\",\"orange\",\"88.191.11.20\",0",
        "\"gprs\",\"websfr\",\"\",\"\",\"88.191.11.20\",0"
    };
 
 
   synchronized (atc) {
        System.out.println( "Waiting 30s..." );
        try {
            Thread.sleep( 30000 );
        } catch (InterruptedException ex) {
            ex.printStackTrace();
        }
 
        for (int i = 0; i < apnList.length; ++i) {
            try {
                String apn = apnList[i];
                System.out.println( "Trying apn " + apn + "..." );
                atc.send( "AT^SJNET=" + apn + "\r" );
 
                SocketConnection conn = (SocketConnection) Connector.open( "socket://88.191.11.20:80" );
                conn.close();
                return apn;
            } catch (Exception ex) {
                System.out.println( "Failed : " + ex.getClass() + " : " + ex.getMessage() );
            }
        }
    }
 
 
    // We couldn't find any APN
    return null;
 
}

And it is only launched when the SIM Card has been changed. To detect that, I have some simple code like this :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{ // APN auto-detection
 
    String imsi;
 
    synchronized (atc) {
         imsi = Common.getIMSI( atc );
    }
 
    if (settings.confLastImsi.compareTo( imsi ) != 0) {
        System.out.println( "Sim card changed ! Auto-detecting APN..." );
 
        synchronized (atc) {
            String apn = Common.AutoDetectApn( atc );
 
            if (apn != null)
                reg.confAPN = apn;
        }
 
        settings.confLastImsi = imsi;
 
        // Whatever happens, we still need to save the current IMSI
        settings.Save();
    }
}

Reference :
- The forum that helped me solve this problem
- Translating Hex to Text

I was looking at my analytics stats (which are not so great, but I don’t really care) and I saw that some of you were accessing this blog by searching for “at^sjotap error codes”. This is quite weird.

The only thing you need to test your Over The Air Provisioning (OTAP) is the command :

1

AT^SCFG="Trace/Syslog/OTAP","1"

But you have to make sure you type it right after you typed the “AT^SJOTAP” command. So, if you do it in a terminal. You should copy the syslog enable command, write the “AT^SJOTAP” command and immediatly past the syslog enable command.

What you should have is something like that :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

--> AT^SJOTAP
<-- OK
--> AT^SCFG="Trace/Syslog/OTAP","1"
<-- SYSLOG ENABLED
<--
<-- [OTAP] GPRS connection established.
<-- [OTAP] Try to get http://www.yourwebsite.com/software.jad ...
<-- [OTAP] Connected.
<-- [OTAP] Transfer finished.
<-- [OTAP] Try to get http://www.yourwebsite.com/software.jar ...
<-- [OTAP] Connected.
<-- [OTAP] Transfer finished.
<-- [OTAP] JAM status: 900 Success.
<-- [OTAP] Reboot now.
<-- ^SYSSTART

For those who still want the answer to the “AT^SJOTAP error codes”, you can find it in “Java_UserGuide.pdf” file provided by Cinterion TC65 SDK, page 61 :

• 900 Success
• 901 Insufficient memory in filesystem
• 902 – not supported-
• 903 – not supported-
• 904 JAR size mismatch, given size in JAD file does not match real size of jar file
• 905 Attribute mismatch, one of the mandatory attributes MIDlet-name, MIDlet-version, MIDlet-Vendor in the JAD file does not match those given in the JAR manifest
• 906 Invalid descriptor, something is wrong with the format of the .jad file
• 907 invalid JAR, the JAR file was not available under MIDlet-Jar-URL, files could not be extracted from JAR archive, or something else is wrong with the format of the file.
• 908 incompatible configuration or profile
• 909 application authentication failure, signature did not match certificate
• 910 application authorization failure, tried to replace signed with unsigned version
• 911 -not supported-
• 912 Delete Notification

The most common error you can make is to have a wrong JAD file, this what it should look like :
The most common error you could make is to do not specify the complete path of your jar file in your jad file. You jad file should look like that :

1
2
3
4
5
6
7
8

MIDlet-1: Midlet, ,MySoft.Midlet
MIDlet-Jar-Size: 29180
MIDlet-Jar-URL: http://87.106.206.30/TC65/mysoft/mysoft.jar
MIDlet-Name: MySoft
MIDlet-Vendor: Cinterion
MIDlet-Version: 1.0
MicroEdition-Configuration: CLDC-1.1
MicroEdition-Profile: IMP-NG

If you still have problems with OTAP, you can leave me a comment.

Program updated !

As I told you in the comment where I released this TC65 SMS OTAP program, it didn’t support serial communication. Well, I have added this feature. The program is now able to directly send OTAP SMS, using a GSM modem.

The “config.bin” with your settings file isn’t compatible anymore.

Please tell me if it works for you and/or if you find bugs. You can also ask me questions about the TC65 if you need some help.

So, to use this program :
1. Extract at least SMSOTAP.exe from SMSOTAP.zip
2. Launch “SMSOTAP.exe”
3. Connect your TC65/XT65 modem to your serial port (or virtual serial port using USB interface)
4. Build a short message (take care about the class and the PID)
5. Click on the “Send” button

Note : When your type your message, the “\n” and “\r” are replaced by ‘\n’ and ‘\r’ chars. The carrier-return (CR) chars typed in the textbox are not sent. No other chars than ‘\n’,'\r’ are converted (but I might change that if you need it).

Note 2 : You should always remember that the “AT^SJOTAP” parameters always override the SMS ones. So, if you want to be sure you will always be able to remotely update your chip, you should reset all parameters by sending the “AT^SJOTAP=” command.

Note 3 : There’s a pretty good chance that this program works on a lot of other GSM modems than the Cinterion TC65 chip. It has never been tested on any other chips but it uses standard AT commands (you can see them in the window).

If you use the TC65 to transmit some frequent (with a transmission interval of less than 700 ms) data, you should know that the TC65’s has a poor TCP implementation considering the ACK management of sent messages.

When the TC65 sends a TCP packet, it waits for the ACK packet of this transmitted packet before sending any other packet. That means that if you have a delay 400 ms between the TC65 and your server (which is very quite common), the TC65 will wait for 800 ms (400 ms for the data packet from the TC65 to the server and 400 ms for the ACK packet to return) before sending any data.

I discovered it because I wanted to send real-time GPS tracking data, and at a rate of 20 positions per second it was way above the minimal delay of 800ms. My positions came by packet of 5 to 20.

I asked for help to the french Cinterion’s support with complete description of the problem, “AT^SCFG” complete view and some libpcap network captures. And they couldn’t give me any real solution to this problem.

I think this is a chosen restriction. The chip has a memory of 400 Kb, to use this the chip would have to use a more complex TCP stack and to consume some RAM to store the last not yet aknowledged messages. I might be wrong, there might be a way to activate this, but right now Cinterion isn’t able give me any answer.

The only solution I found is to send data from the TC65 using UDP and to receive data using TCP. And receiving in real-time (I mean short time) DOES work perfectly with the chip (no need for increasing the receive buffer). You just have to disable Nagle’s algorithm (TCP_NODELAY=TRUE) on the remote host (most probably the TCP server).

Update anything

Cinterion gives specifications on how to send SMS messages to launch a remote Over The Air Provisionning (OTAP) operation.

Recently, someone asked me : We have a little program on some TC65 chips that only send SMS, we would like to connect it to the software that you built. What would we have to do. Well that where the magic comes. You don’t have to touch any of the hardware. The only concrete thing you might have to do is enable GPRS on the sim cards of your M2M fleet.

Let’s say the current little program’s name is “little.jar” (+ its “little.jad”). You have to build a program called “little.jad” that :

• Change the name of the starting program from a:/little.jad to a:/m2msoft.jad
• launches a local OTAP operation (with the “AT^SJOTAP” command)

Then you publish it on your HTTP server, send an SMS to every TC65 chip with the address of your HTTP server, and HERE IT IS ! Your whole M2M equipments fleet is updated with your brand new software.

Note on the SMS

According to Cinterion’s specifications, it’s pretty easy to send the software update SMS. But, when the time comes where you actually have to do it, you might get stuck, because it has to be precisely forged. I built a little (english+french) program that enables me to send SMS update to any TC65 ship I like.

It looks like that :

I updated the program. More details here.

A little bit deeper

You should remember that whatever parameter is sent by SMS, it is overridden by the “AT^SJOTAP” setting. The only way to have a remote complete control over the chip is to send the “AT^SJOTAP=” command.

That means that if you want to just put your chips where they have to act and then do a little OTAP to install the first program on it, you have to set :

• AT^SJOTAP
• AT^SCFG=”Userware/Autostart”,”",”1″

M2M projects are the type of project I like to work on. Connecting remote devices, making them work together, and controlling everything remotely are things i love !

I discovered the Cinterion TC65 (which belonged to Siemens then) 3 years ago. And it was a dream come true. I’ve been mostly working on it to build some powerfull GPS tracking software over GPRS. But I have also worked on some other projects making it communicate with some equipments using GPIO or serial port.

Some things you might like with the TC65 Chip :

• Java Virtual Machine (J2ME)
• Only requires a serial or a virtual serial link over a USB cable to program
• You can easily build powerful, multi-threaded programs
• Easy management of GPIO, SPI, I2C ports
• Easy management of TCP/UDP connections
• Quite powerful (400 KB of RAM, 1.7 MB of memory)
• You can update your code remotely with at commands or specially formated SMS
• It’s fast enough for most of your M2M usages (but it’s not well suited for sound or video transport)

I’m quite disappointed to see how only few people/companies are interested in this product. The product is great, developers tools are great and the over the air updating feature is great too ! I think it costs around 60/70 € ($95). One reason might be that the first version of the chip was pretty buggy. The only safe solution was to add a hardware watchdog.

There’s a pretty interesting feature that I would love to use : libraries that are downloaded and updated separately from the main program. But sadly, it isn’t compatible with some old v1 chips I still use.

I’m planning on building a little M2M platform software with a network (with its dedicated protocol) component and .Net (running on Windows and Linux/Mono) server. This is the most difficult part, because you have to make it stable, efficient and low-bandwith consuming.

Available TC65 software versions are :

• TC65 v1 : First version. Very unstable. It could crash for days. It also happened that the software was suddenly deleted. Couldn’t get standard output to the virtual serial port on USB. Sometimes OTAP SMS could save the chip, sometimes we just had to wait for days before it decided to come back to life.
• TC65 v2 : New hardware (HW v2). Seems more stable. Thought, I have one chip where it sometimes crash just 20 seconds after startup.
• TC65 v3 : Can be upgraded from a software v2 (needs a HW v2). Offers a software watchdog.
• TC65i v1 : Cinterion has bought it. Smaller, better power saving mode

And for the XT65 chip :

• XT65 v1 : TC65 v2 with GPS
• XT65 v2 : TC65 v3 with GPS

Vendors selling their TC65 with a watchdog often don’t have one. They just rely on the software watchdog of the TC65 v3 chip.

• Where can I find technical support for the TC65 ?
  You have to ask your TC65 supplier. It will redirect you to a company in charge in your region. Some companies seem better than other, some won’t even know that the chip can be used with java programs and some can give you precise technical informations.
  If you want a quick, unofficial support, you can contact the javacint group or directly subscribe to it :
  Email:
  
• Can i use a GPRS connection with both a running java program and my PC ?
  No. The chip either does java or modem. You could eventually simulate a modem within a java app. But I doubt that it would be very useful.
• How can I upgrade a program remotly ?
  You can :
  - Execute an “AT^SJOTAP” command triggered by an SMS, a network command or any special event you want
  - Send an OTAP SMS. This will launch the update on any chip you want. You can do that by using my little software and an other GPRS modem.
• Can I prevent the chip from shutting down and not waking up ?
  This problem of the chip shutting down with the “^SHUTDOWN” URC and not waking up is a big a one. Some people send a restart command in the destroyApp method. It has the obvious drawback of preventing the chip of being remotly upgraded.
  In fact you CAN upgrade your program even with this fix. You have to set your chip to wait for the maximum time before program starts (AT^SCFG=”Userware/Autostart/Delay”,”250″ ie 25 seconds) at startup. You make the chip restart with a first OTAP SMS (or any other restart command) and then send an other OTAP SMS within this 25 seconds restart time.

  I personally only use trackers with hardware watchdog to prevent this problem.

• I have this error :

  1	^EXIT 00010000,008e504c4b4d4552522c353030333a306334303a65303130204d6f6e61636f3a2053504f5254733a204253504f5254204c6f636b7570

  This can be hextranslated to “PLKMERR,5003:0c40:e010 Monaco: SPORTs: BSPORT Lockup”. Like most of these errors, it only means something to some few people within Cinterion (Siemens). It’s a know issue with the first version of the v3.0 firmware. You should flash your chip.

• Debugging on TC65 doesn’t work
  First of all, make sure you debug with the tools intended for your chip. Debugging might not work or work weirdly (no variable state visible for instance) with incompatible versions.
  You also have to make sure the “remote debugging connection” works fine. Everytime you change something in your configuration, make sure to use Cinterion (or Siemens) setup utility to “repair” the debugging connection.
• How can I get a .jar file from the TC65
  You can’t. As you may not know, jar files can be very easily decompiled and even obfuscated reveal the logic of your chip. This is a very basic and powerful way to prevent your software from being reverse-engineered. You can upload jar file on the chip but never download jar file from the TC65.
• Can we save a lot of data on the chip ?
  I has 1.7 MB of memory. Chances are you are only using 5 to 100 kB for your java code. So it enables you to save a lot of data.
  Note : I have never been faced wit this problem but the memory used by the TC65 chip is limited to approximatively 100 000 read/writes. So you should avoid to write things too often.
  What you can and you should save are settings required to communicate with the chip.
• Can we use an SD-Card or any kind of flash storage system with the TC65 ?
  In the SDK documentation, the AN_17_FOTA.pdf file describes this. You have to use an Flash storage system connected to the SPI port. It is in this document related to the Firmware Over The Air update process, but you can use it for anything else.
• Why can’t I use the TC65 or/and AT commands when a program is launched ?
  The TC65 can act in two modes : Modem or software execution. In modem, it supports AT commands on any port (ASC0, ASC1, USB). In software execution mode, all the ports (ASC0, ASC1, USB) can only be used for communications. In this mode, you execute AT commands within your software, using the ATCommand class.
• Why is MES not working ?
  It’s very likely that is is for one of these reasons :
  - You didn’t set a fixed baudrate (at+ipr=115200 for 115200 bps for instance)
  - The cable or the serial connector you use doesn’t permit to send the RS232 modem DTR and DSR signals.
• Can I use a serial over USB converter ?
  Yes, but for transfers, you need MES to work. The only serial over USB converter that are proven to work are the ones embedding an FTDI chip.
  I also have an other converter, based on a CP210x chip, it won’t work for transfers.
• I have the TC65 but my supplier didn’t give me the SDK. What should I do ?
  This happens a lot. Some suppliers don’t even know that the TC65 can be programmed in java. You can ask them (because they are the one supposed to give it) or download it here.
• Can I make my developments on a Linux hosts ?
  Not officially but you can. Someone made a page on TC65 Development on a Linux host about this. I’ve never tested it thought.
  Ricardo also gave some programs and files to use MES on Linux on the javacint group files (I haven’t tested it).
• What are the network protocols supported by the TC65 ?
  • In AT Commands : Socket, FTP, HTTP, POP3, SMTP
  • In Java environment : Socket, SSL, HTTP/HTTPS, UDP

  If you need FTP, you can’t do it in java directly unless you implement the FTP protocol in your code.

• How can we make the chip go in sleep mode ?
  For the chip to be able to sleep, you have to make all your threads die, sleep or wait for an I/O to be performed.
  The chip really goes in sleep mode 30 seconds after everything is ready to make it sleep.
• How can we save settings on the TC65 ?
  The best way is to save your parameters in a file using a settings abstraction class. I’ve seen people saving parameters in the SIM Card, it’s very constrictive and you lose everything when you need to change the SIM card. I think this is totally useless.
• How are we supposed to manage the life program’s lifecycle ?
  - The midlet starts in the “startApp” method and it snould let the startApp call end by creating a new thread.
  - When the “destroyApp” method is called by the system, you have 5 seconds to close everything and call notifyDestroyed. If you don’t, your program will quit and it will display a warning on the console.
  - The “pauseApp” method (and its “notifyPaused” linked method) are optionnal.

  Keeping the program’s loop in the “startApp” method is wrong. It seems it creates instability and update problems.

• The OTAP process is working fine but how can I remotely enable the AutoStart on brand new TC65 chips ?
  I haven’t figured this out yet. I’m not sure there is a solution. I personally built a little program that check for new TC65 chip presence on the serial ports and setup them.
  This isn’t much of a problem thought because I like to detect & test the chips on a PC to identify it.
• How can I identify each chip ?
  You can identify each chip with the “AT+GSN” AT command. you can identify its SIM card with the the “AT+CIMI” AT command.
• Is there any recommendation around the use of files with the TC65 flash memory storage ?
  The flash memory is approximately limited to 100 000 R/W cycles. You should save data in RAM memory as much as possible. But when absolutely required, you can still write things on flash storage. Let’s say you save a file each 20 minutes and each file save makes 2 R/W cycles.
  We get 100 000 / 2 * 20 = 1 000 000 minutes of life. That means 1 000 000 / 60 / 24 = 694 days. That means a little bit less than 2 years.
  That’s not very long, so this isn’t too good.
• Can we build TC65 programs with Windows Vista or Windows 7 ?
  Yes but the Module Exchange Suite will only work on Windows XP. So I recommend you use Windows XP on WMWare workstation to do this.
• Java program starts with the chip, how can I disable it ?
  When autostart is enabled and the autostart delay is set to 0, you cannot disable the autostart by AT Command. You have to use the “Switch Autostart off” program given with the TC65 SDK.
  As described in the Java_UserGuide.pdf :

  Using the graphical “autoexec_off.exe” tool:
  1. Connect the module to the PC
  2. Make sure, that the module is switched off
  3. Start the “Autoexec_Off” program
  4. Select the COM-Port
  5. Press the “AutoExec Off” button
  

• How can the TC65 switch on automatically as soon as it is powered ?
  You have to connect the ignition input (IGT_IN) to the power input.

Last update : Mars 09, 2010. Updated this FAQ again with the questions received personally or from the javacint group.

Last update : November 28, 2009. I updated this FAQ with the questions received personally or from the javacint group. For any question, please contact the javacint group.

GD Star Rating
loading...