Florent Clairambault

I did this program because I had to reprogram some chips without a working MES deployment environment. I could deploy the TC65 program on a server but not upload it on the chip. And then I thought it could do a nice application for all the people deploying TC65 programs in a production environment.

What this program basically does is to respond to “^SYSSTART” messages coming from the TC65 chip to launch an OTAP update and/or launch the program. But in the details it does a little bit more as it can auto-detect the port of the chip.

Some of the features might not be working great or even not working at all. The program will be improved with the time, my testings and your comments but it’s currently used for my own needs.

You can download it.

Here is the “-h” output :

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

TC65FM 0.1 - Fast Manager - Copyright WebIngenia 2010
 
 -b  --behavior <behavior>     Behavior, can be : 
       i  / install              Install only
       r  / run                  Run only
       ri / run-and-install      Run and install
       n  / none                 Nothing
 -na --net-apn <apn>           Network APN
 -nu --net-user <user>         Network User
 -np --net-password <password> Network password
 -nd --net-dns <dns>           Network DNS
 -au --application-url <url>   Application url
 -sA --serial-autodetect       Serial auto-Detect
 -sp --serial-port <port>      Serial port (default: COM4)
 -ss --serial-speed <speed>    Serial speed (defau:t 9600)
 -tp --target-program          Target program
 -ni --no-ipr                  Desactivate IPR command (not recommended)
 -ae --autostart-enable        Enable autostart
 -ad --autostart-disable       Disable autostart
 -at --autostart-time          Time before autostart
 -pc --password-current        Current password
 -pn --password-next           Next password
 -h  --help                    This help

There’s also a “network autodetection” feature which is in a very early stage. So if you want to test it you can using the “-nA” option (but you shouldn’t).

Let’s say you want to automatically install the program each time a chip (configured with a serial baudrate of 9600) connects to the COM4 port :

1

tc65fm -sp COM4 -ss 9600 -na "m2minternet" -nu "http://webingenia.com/myPath/myApp.jad" -tg "a:/wim2msoft.jad"

The program creates two types of log files. One for the complete running time and one for each communication with the chip occuring after a restart (and the identification of the chip by its IMEI).

Here is the logs of what you should get at each chip startup with this app :

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

TC65FM v0.1 - Copyright Webingenia - www.webingenia.com
2010-07-17 09:43:25.682 | <-- AT
2010-07-17 09:43:25.733 | --> AT
2010-07-17 09:43:25.748 | --> OK
2010-07-17 09:43:25.766 | <-- AT+IPR=9600
2010-07-17 09:43:25.828 | --> AT+IPR=9600
2010-07-17 09:43:25.829 | --> OK
2010-07-17 09:43:25.847 | <-- AT+CFUN=1,1
2010-07-17 09:43:25.908 | --> AT+CFUN=1,1
2010-07-17 09:43:26.932 | --> OK
2010-07-17 09:43:30.164 | --> ^SYSSTART
2010-07-17 09:43:30.169 | <-- AT+CGSN
2010-07-17 09:43:30.228 | --> AT+CGSN
2010-07-17 09:43:30.292 | --> 353234023540741
2010-07-17 09:43:30.292 | --> OK

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

TC65FM v0.1 - Copyright Webingenia - www.webingenia.com
2010-07-17 09:43:31.174 | <-- ATE1
2010-07-17 09:43:31.236 | --> ATE1
2010-07-17 09:43:31.253 | --> OK
2010-07-17 09:43:31.256 | <-- AT^SJOTAP=,http://webingenia.com:8080/myPath/myApp.jad,a:,,,gprs,m2minternet,,,,,,
2010-07-17 09:43:31.413 | --> AT^SJOTAP=,http://webingenia.com:8080/myPath/myApp.jar,a:,,,gprs,m2minternet,,,,,,
2010-07-17 09:43:31.461 | --> OK
2010-07-17 09:43:31.477 | <-- AT^SJOTAP
2010-07-17 09:43:31.540 | --> AT^SJOTAP
2010-07-17 09:43:31.573 | --> OK
2010-07-17 09:43:31.578 | <-- AT^SCFG="Trace/Syslog/OTAP","1"
2010-07-17 09:43:31.668 | --> AT^SCFG="Trace/Syslog/OTAP","1"
2010-07-17 09:43:31.685 | --> SYSLOG ENABLED
2010-07-17 09:43:47.622 | --> [OTAP] GPRS connection established.
2010-07-17 09:43:47.702 | --> [OTAP] Try to get http://webingenia.com:8080/myPath/myApp.jad ...
2010-07-17 09:43:51.812 | --> [OTAP] Connected.
2010-07-17 09:43:51.861 | --> [OTAP] Transfer finished.
2010-07-17 09:43:51.941 | --> [OTAP] Try to get http://webingenia.com:8080/myPath/myApp.jar ...
2010-07-17 09:44:01.781 | --> [OTAP] Connected.
2010-07-17 09:44:02.340 | --> [OTAP] Transfer finished.
2010-07-17 09:44:05.541 | --> [OTAP] JAM status: 900 Success.
2010-07-17 09:44:11.524 | --> [OTAP] Reboot now.
2010-07-17 09:44:11.540 | --> ^SYSSTART
2010-07-17 09:44:11.544 | <-- AT+CGSN
2010-07-17 09:44:11.605 | --> AT+CGSN
2010-07-17 09:44:11.652 | --> 353234023540741
2010-07-17 09:44:11.668 | --> OK

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

TC65FM v0.1 - Copyright Webingenia - www.webingenia.com
2010-07-17 09:44:12.048 | <-- AT^SJRA=a:/secretApp.jad
2010-07-17 09:44:12.132 | --> AT^SJRA=a:/secretApp.jad
2010-07-17 09:44:12.389 | --> OK
2010-07-17 09:44:13.652 | --> WIM2MSoft
2010-07-17 09:44:14.036 | --> Thread-5 : [1/7] Initiating...
2010-07-17 09:44:14.534 | --> Thread-5 : [2/7] Loading settings...
2010-07-17 09:44:15.126 | --> Thread-5 : [3/7] main AT Command interface...
2010-07-17 09:44:15.222 | --> Thread-5 : [4/7] Loading SMS Management...
2010-07-17 09:44:15.510 | --> Thread-5 : [5/7] Checking SIM card...
2010-07-17 09:44:20.676 | --> Thread-5 : [6/7] Loading M2MP network communication...
2010-07-17 09:44:21.908 | --> Thread-5 : [7/7] Loading the main program...
2010-07-17 09:44:32.485 | --> nwr : NetworkLayer.Connect : Could not connect to 84.14.33.44:3000 ex : class javax.microedition.io.ConnectionNotFoundException :  Remote host has rejected the connection.
2010-07-17 09:44:53.845 | --> nwr : NetworkLayer.Connect : Could not connect to 84.14.33.44:3000 ex : class javax.microedition.io.ConnectionNotFoundException :  Remote host has rejected the connection.

During the last months I spent some time writing a document on the TC65 development. It is primary aimed at TC65 project managers and developers.

This document can be considered as a draft and I’m waiting for any of your comments to fix / improve / complete it. It’s currently 40 pages long.

Here is the document.

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 on the 17 December 2009 :
I modified and formated some parts of the original mail.

Here is an other message Ricardo sent on the 18 March 2010 :

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″