Florent Clairambault

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.

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.

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.

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

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.

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

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

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.

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();

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.

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.

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.

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.

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