A little TC65 development document

WARNING: All the Cinterion related content from this blog will be removed to go to the javacint wiki soon. Please get used to going there.

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. I also added it to our Cinterion TC65i page on our website.

Oct 10, 2010 : Update
I updated the document to speak about libraries and fixed some few things.

18 thoughts on “A little TC65 development document”

  1. On page 19, first line is:

    but on last line of page 18 you say:
    “It is recommended to set it to restart mode”

    So the AT command should be:

    Thank you for this useful documentation.

  2. Hi Florent,
    I have found a few other problems reading page 30. Please note I am using Evince 2.30.3, I will check with Acrobat Reader.

    Last paragraph of 7.6.4 is:
    “You can see an example of basic asynchronous request sending in 0. To understand […]”

    Here “0” is an hyper-link to “8.1.1 Logging class” but I think should point to “8.1.2 Asynchronous HTTP requests”

    Read “7.7 I/O Blocking or not?”. On my computer it is:
    “If you open your source (say a CommConnection as seen in 0 When you know you won’t require

    Thanks again.

  3. Wow, great document! This document should be part of Cinterion documentation. Thanks a lot for sharing.

    I also have a question regarding TC65 development. I have got a TC65i device with a usb port and I would like to use this usb port to output logging information. So in my application I issue AT^SCFG=”Userware/Stdout”,”USB” in order to route System.Out to the usb port. And then I use System.out.println(“logTxt”) to print logging information.
    However it is impossible (or I don’t know how) to setup a connection with a terminal program to this USB port to view the logging information.

    If there is no java application running then windows discovers the TC65i device and a virtual com port becomes available. With a terminal program I can connect to this com port, send AT commands and read the responses. However when I run a java application the fun is over. The virtual com port simply disappears. There is nothing to connect to. I think I miss something very basic because Siemens/Cinterion probably do not introduce the switch System.out to USB for nothing.

    I hope you or someone else has some information about this.

    By the way my OS is windows 7 64-bit. Can it be a driver issue?

    Oh and in your document you mention that MES is not working on other operation systems then XP. However I have no big troubles with it on win 7. Only the explorer integration is gone and probably that has to do with the fact that my OS is 64 bit.

  4. Hi John,

    Sorry for the late response.

    Yes, you’re right about the MES. I wasn’t clear enough. For me MES stopped working when we couldn’t use the drag&drop feature but it actually works. I have fixed the document on my computer and I will upload it once I have added something about the TC65FM I just did.

    That seems really weird to me as I have used it intensively for a serial over TCP program I did for a client who used an equipment with only one serial port and one USB port.
    I was sending & receiving data over serial and logging information on the USB port.

    Didn’t you activated the multiplexing program ? (the thing that allows you to have 3 AT command interfaces on one).

    Using USB as output is something I can’t recommend to do though as the USB connection breaks each time you need to restart the chip.

    Best regards,

  5. Thank you for your answer Florent. I do not use multiplexing. I agree it is annoying to use the USB connection because of all the disconnecting/reconnecting but I had to use the serial port to connect to some other device.

    If I understand right in your setup you had a virtual com port available, while running an application, that you could connect to. So it is weird it is not working for me, what operating system did you use?

    Or maybe I just do something wrong. My procedure is: Connect to the virtual comport with a terminal program. Then start the application with AT^SJRA. So far so well I get an OK reply and the application starts. However then I hear the windows sound that a USB device has disconnected. Unfortunately it never reconnects again. If I look for com ports the virtual com port is simply gone. I have the feeling I overlook something very basic.

    For the rest the my USB port seems to be working fine. I can also download software via it and debugging seems to work too. So maybe I should try to make the System.out directly visible in Eclipse using udp.

  6. Hi Florent,
    I have a doubt on class Core on page 8.
    I think
    private boolean _loop;
    should be
    private volatile boolean _loop;
    or you should use a synchronize block because start() and stop() are likely called from a different thread, so run() is not guaranteed to see the new value of _loop.

    I think the same is true for the _thread field, but in this case I think it would suffice to make it final.

  7. Hi Marcello,

    The “Core” class is only started by startApp and stopped by stopApp and these two cannot be called at the same time.

    So from a general point of view you’re right. But here, there is no point in securing the concurrent accesses.

  8. Hi Florent,
    unfortunately my English is bad, so I did not explain well.

    The problem is not that Core.start() and Core.stop() can be called concurrently.

    The problem is that Core.stop() and Core.run() will be called from different threads (that is guaranteed). Both use Core._loop, so you must declare it volatile or use synchronization for both read and write operations.

    Reading and writing a boolean is an atomic operation, but no thread communication is guaranteed by the JVM if the variable is not volatile or is not used in a synchronization block.

    You can find a far better explanation on “Effective Java – Second edition” chapter 10 by Joshua Bloch.

  9. Ok, I have found the answer to my doubts in

    It works fine because you call _thread.join() after _loop=false in stop(). This ensure that the new value of Core._loop is propagated to the other thread.

    The only remaining thing is: should Core._thread be final?
    Unless you are sure Core.start() and Core.stop() are called from the same thread, yes. I do not know if this is true. But making Core._thread final has no side effects, so: why not?

  10. Hi.

    “If you want to do some debugging, it might be a better idea to stick to the SDK version of your chip.”
    I disagree. Debbuging works fine in latest versions of netbeans, but you have to configure it just like in the 5.5 verison that comes with SDK.

  11. in page 14, topic ‘5.5.2 How’

    Describes setting the funcionality of the modem. AT^CFUN=0 is an invalid command. In addition, all comands that starts with AT^ are Siemens commands, AT* are Nokia commands and so on… and all commands starting by AT+ are generic commands. AT+CFUN=0 should work in most gprs modems that implement sleep mode feature.

  12. Thank you Ricardo, I have few things to fix in this document. I just fixed this. I’ll try to publish an updated version soon.

    And thank you for all the work you do around the javacint group and more generally for the Cinterion developpers community.

  13. “I disagree. Debbuging works fine in latest versions of netbeans, but you have to configure it just like in the 5.5 verison that comes with SDK.”

    I couldn’t get debugging to work since NetBeans 6.9. Maybe someone can make instructions how to setup recent versions of NetBeans (like 7.0) with TC65i SDK?

Leave a Reply

Your email address will not be published. Required fields are marked *