SMS OTAP program for the TC65 updated

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).

Cinterion TC65′s TCP stack limits

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 an ACK packet before sending any other packet. It 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 send a packet before waiting the acknowledge of the previous packet, it would have to use a more complex TCP stack and to consume some RAM to store all the packets left to acknowledge. 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).

Why TC65 SMS OTAP software update is great

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″

Cinterion TC65 Chip

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.

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.

Posted in English. Tags: , . 9 Comments »

TC65 FAQ

  • 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 information.
    If you want a free and unofficial support, you can contact the javacint group.
  • Do you offer support / development services?
    Yes through my company.
  • 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 another 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 one but I think it only occurs on TC65 v1 chips. 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 have this error :
    1
    
    ^EXIT 00010000,008e504c4b4d4552522c353030333a306334303a65303130204d6f6e61636f3a2053504f5254733a204253504f5254204c6f636b7570

    This can be hextranslated to :

    1
    
    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.

  • I have this error :
    This one comes from Marcin Mazurek on a TC65i

    1
    2
    
    ^EXIT 00010000,015d4b49414d582c283434303032442c38303034302c4646464629
    ^EXIT 0000fd04,07016572726f72686e646c2e632c535849545f636f6e74696e75653d66666666666666312831303030302c4b49414d583a3334392c283435303032442c39303033462c464646462929

    This can be hextranslated to:

    1
    2
    
    KIAMX,(44002D,80040,FFFF)
    errorhndl.c,SXIT_continue=fffffff1(10000,KIAMX:349,(45002D,9003F,FFFF))

    This is likely to be caused by the use of an opened SpiConnection class instance and the GPIO at the same time. You should avoid to use SPI and GPIO at the same time and if you’re using a multi threaded program, you should synchronize the access to these elements.

  • I have this error:
    1
    2
    3
    
    ^EXIT 0000fd09,05e2686973745f7461736b2e632c31303030302c6162706d6d6d2e632c3132373
    22c4d6f6465204d616e616765723a426c6f636b2032303030204e5652414d2072656164206661696
    c757265206f72204461746120636f7272757074

    This can be hextranslated to:

    1
    
    hist_task.c,10000,abpmmm.c,1272,Mode Manager:Block 2000 NVRAM read failure or Data corrupt

    It seems your NVRAM (and your TC65 chip) is out of order. You might have changed too many times some settings with the AT^SCFG command.

  • 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 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?
    Behind the wheels, the JVM will load your jar file, uncompress id, load the main class, instantiate it and…
    - The midlets starts in the “startApp” method and it should 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. In the TC65, I’ve never seen them being used. But I don’t know everything.

    Keeping the program’s loop in the “startApp” method is wrong. It creates update problems because the destroyApp method is called when the startApp method is still running.

    Letting the startApp method call finish is a good thing. Creating new threads is not a requirements, you could handle everything through URC and ATCommandListener.

  • 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. But because of the wear leveling mechanism applied by the flash memory, we can consider the number of writes applicables as way more important. So it’s really a matter of appending more than replacing and leaving enough free space for the wear leveling to apply.

    Discussions around the subject: 1, 2

  • Can we build TC65 programs with Windows Vista or Windows 7?
    Yes but the Module Exchange Suite doesn’t seem to work with x64 versions.
    But you can use JObexFTP (from Ricardo Schmidt) if that happens.
  • 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?
    It seems connecting the ignition input (IGT_IN) to the power input works. But the TC65 HW Description file says :

    When the TC65i module is in Power-down mode or Charge-only mode, it can be started to Normal mode or Airplane mode by driving the IGT (ignition) line to ground. This must be accomplished with an open drain/collector driver to avoid current flowing into this line.

  • How can we get the source code from a TC65 jar file?
    Any java decompiler can do the trick
  • How do we use I2C

    I2C java API only exists since TC65i. If you need some I2C using AT Command please read the AT Command doc.
    The SDK documentation on that matter is pretty clear.

    The documentation even has a pretty simple example, here it is with some comments added :

    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
    
    /*** Open I2C connection and data streams: ***/
     i2cConnection cc = (I2cBusConnection) Connector.open("i2c:0;baudrate=100"); // Bus 0 (there's only one on the TC65), 100 kbps
     int baudrate = cc.getBaudRate();
     InputStream inStream  = cc.openInputStream();
     OutputStream outStream = cc.openOutputStream();
     
    /*** Write Transfer Frame, where a = message ID, AE = Slave Address and write request: ***/
     String data = "<aAE000102030405060708090A0B0C0E0F>";
     outStream.write(data.getBytes(), 0, data.length()); // This is acceptable here (because all these chars are ASCII), but you should avoid fixing the size of a byte array and a string (UTF8 chars can make 2 bytes).
     outStream.flush();
     
    Read response message: {a+} where a = message ID:
     byte[] inBuf = new byte[<size>];
     if (inStream.available())
      int inBufLen = inStream.read(inBuf);  // Here, the generated string is in : new String( inBuf, 0, inBufLen );
    // But to get some real code, you have to do some standard InputStream processing
    // It means basically that you have to wait for the '>' or '}' char ( == byte here) before handling each buffered packet.
    /*	
     Note that the read method blocks the thread until at least one byte has been read.
     To avoid blocking infinitely in case the I2C bus does not respond, check please first
     if there is data available. If the bus sends a big amount of data, the data will be read
     in pieces and the implementation has to poll until the end of the data.
    */
     
    /*** Close data streams and connection: ***/
     inStream.close();
     outStream.close();
     cc.close();
  • How can I protect my source code from being stolen and still distribute jar file?
    Activate the compiler optimizations, and set the maximum obfuscation level.
  • Can we use an emulator for the TC65/TC65i?
    No you can’t, sometimes it is referred to a simulator but in fact it always relies on the chip.

    You should note that you could potentially emulate the chip by launching the midlet on a J2ME mobile device emulator and recreating all the Cinterion’s classes. But that wouldn’t be very interesting as most of the development work done on the TC65 is around the hardware handling.

  • How can I get and send back to a server the stack trace of an exception?
    You can’t directly do it from the java code as the J2ME doesn’t allow to export the stack trace of an exception to an outputstream and you can’t change the defaults output streams (stdout and stderr).

    But you can set up your program to redirect it’s output to a logfile by using the “AT^SCFG=”Userware/Stdout” command described on page 65 of the TC65i AT Command Set document.

  • How can I use socket connection?
    This is very well explained in the I2CBusConnection class javadoc.

    This can implemented very quickly, you just have to create an I2C message parser, the most important part being to get the message between the ‘{‘ and the ‘}’ braces. You could also make it handle the retransmission of unsent I2C messages.

  • How can I send mail with the TC65?
    As a general architecture pattern, it’s often more appropriate to use the server as an “alerter” that will send SMS, mail or anything else depending on the received messages. But still…

    You could use the mail AT commands but that will lead you to some very poor maintainability. If you’ve already handle some simple text protocol, it will be quite easy to communicate with the SMTP server. This is what it looks like :
    “<--" for received and "-->” for sent

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    
    <-- 220 ns301797.ovh.net ESMTP Postfix (Debian/GNU)
    --> HELO TC65/toto
    <-- 250 ns301797.ovh.net
    --> MAIL FROM: <tc65@webingenia.com>
    <-- 250 2.1.0 Ok
    --> RCPT TO: <florent@clairambault.fr>
    <-- 250 2.1.5 Ok
    --> DATA
    <-- 354 End data with <CR><LF>.<CR><LF>
    --> From: <tc65@webingenia.com>
    --> To: florent@clairambault.fr
    --> Subject: This is a simple mail
    -->
    --> Here is the content of the mail
    --> .
    <-- 250 2.0.0 Ok: queued as C3C323401B
    --> QUIT
    <-- 221 2.0.0 Bye

    If you need to send attachments, this is a little bit more complex but not that much. You need to add some headers to send mail as multipart messages (meaning that it will contain more than one part). And you need to add some Base64 encoding method so that you could put the content of the file you wish to send into a base64 encoded format.

  • What can I do if I set a password on the device and forgot it?
    Basically you can do everything that doesn’t require any password. Because there’s not way to recover your password. This is clearly stated in the Cinterion documentation:
    CAUTION: Be careful not to lose the password. There is no way to reset or recover a forgotten password or to obtain a new password from the manufacturer.

    Doing FOTA doesn’t seem possible and there isn’t any reported way to flash the NVRAM. So you basically bricked your device if the autostart delay was set to 0. If not, well, you should still put it in the trash bin because it will create some real constraints (like not being able to do some OTAP).

  • Last update: Apr 10, 2011. Added the password issue.

    Last update: Dec 16, 2010. Updated the flash answer.

    Last update: Nov 23, 2010. Updated the link to the javacint group which has been migrated from google to yahoo.

    Last update: May 12, 2010. Update the FAQ.

    Last update: Mars 09, 2010. Updated this FAQ.

    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.

Posted in English. Tags: , , . 21 Comments »