On Windows 7 USB COM Port device hangs after AT+CFUN=1,1 | Telit Cinterion IoT Developer Community
December 3, 2020 - 6:19pm, 2099 views
I'm able to connect to a PLS62T_w terminal device through a USB port on Windows 7. For USB driver, I'm using the cinterion usb drivers, "pls62-w_rev02.000_arn01.000.04_drivers".
If I issue AT+CFUN=1,1 using Hyperterminal, the USB port hangs so I'm not able to connect to the terminal. The terminal device itself is still working. The "Cinterion PLSx USB Com Port1" device is still shown under Ports in Windows Device Manager but the Virtual COM Port is inaccessible until I physically disconnect and reconnect the USB connector. Alternatively, right click disable and enable the "Cinterion PLSx USB Com Port1" device on Windows Device Manager will also work.
I don't have this problem on Windows 10.
Another issue which I faced is if the USB connector is disconnected for any reason, the Virtual COM Port will become inaccessible by console and the only way to resolve it is by physically disconnecting the connector a second time or right click disable and then enable the device on Windows Device Manager. This is the reason why I was looking at the watchdog 2 earlier but I would like to avoid using Java.
Questions:
1. Is there a way for me to reset the terminal by AT command so that the Windows virtual COM device still works after reset? I tried AT^SMSO but it powers down the terminal entirely. As the terminal will be used in a remote location, as far as possible, I would like to manage the device using AT commands.
2. On Windows 10, is there any advantage in using the native "pls62-w_rev02.000_arn01.000.04_drivers" instead of the native Windows USB device driver? Which is better? For my tests so far, the native Windows USB device don't appear on Windows 7.
Hello,
It should be enough to do a software disconnection in your terminal program when you reboot the module. It should not be necessary to physically replug the cable. It is a known behavior in Windows unfortunately.
If some standard Windows drivers are working for you, you can also use them for AT commands. But you may not have modem or Ethernet adapter drivers installed automatically by Windows. And firmware update over USB would also not work.
Best regards,
Bartłomiej
Thanks Bartłomiej. I managed to get it to work by closing the COM port immediately or 1-2 seconds after AT+CFUN=1,1, and refrain from opening the COM port until about 10-15 seconds later.
As for disconnecting USB connector, the above method doesn't work (the port is disconnected to begin with). However, I'm able to connect using Serial COM1 and see:
^SYSLOADING
^SYSSTART
+CIEV: prov,1,"fallback"
+PBREADY
From serial COM1, I issue AT+CFUN=1,1, and after that, I can access via USB virtual COM Port. The other way is to disconnect the USB Connector a second time.
Can I confirm that watchdog2 only works if AT command is working and if the module has not hang in the first place?
Hello,
If you disconnect USB cable and plug it again you also should disconnect the software connection (like in case of a module reboot) and connect when the module is enumerated. It is not the case for RS232 connection.
If you see ^SYSLOADING and ^SYSSTART URCs this means that the module was rebooted. Does it happen when you disconnect USB? Maybe the device is powered over USB. What hardware do you have?
Watchdog which you activate with AT^SCFG command and control with Java MIDlet will only reboot the module if the Java MIDlet starts it. So MIDlet should be started with autostart and have time to start the watchdog and then should not kick it for a defined time.
Regards,
Bartłomiej
Thanks for your reply. If the USB cable is accidentally disconnected, closing the COM port won't work. The only way is to physically disconnect it again and reconnect the 2nd time.
I'm using the PL62-W USB which I believe is not powered via USB. I noticed that if serial COM port is connected for the first time, ^SYSLOADING and ^SYSSTART will be displayed on first connect, even if the device was already connected through the USB port and AT commands issued.
Does the MIDlet kick the hardware watchdog? Or just the module watchdog?
I've activated the watchdog using the AT^SCFG command. Does the JRC MIDLET starts and kicks the watchdog? It will be very useful if the default MIDLET is able to do that.
AT^SJAM=5
^SJAM: "a:/JRC-1.62.01.jad","Java Remote Control MIDlet Suite","Cinterion","1.62.01",1,1
Hello,
I'm using Windows10 and can't reproduce your problem. When the cable is plugged back and the module enumerates it is possible to connect again with my terminal software. Did you check in Device Manager if it enumerates properly on the same ports?
What hardware do you use - is it the module on some developer board or the terminal version with casing?
If you don't observe any problems on USB while plugging the serial cable, the module still replies and there are no signs of reboot then most probably the URC's that were thrown on start were buggered and displayed when you opened the serial port on your PC.
The module's watchdog is the mechanism designed to protect from some error situations related to the user MIDlet, like deadlock or hanging caused by any unpredictable reason. You need to activate it with an AT command first. And then initialize in your application. After that the watchdog ***** to be kicked within the configured interval. You usually place such kicking into some critical thread or add some wrappers to the provided Watchdog API to control more critical threads. When the application hangs (or more precisely the thread that kicks the watchdog stops doing so) the module will reboot.
It's up to the designer if and where the watchdog will be used in the application.
JRC does not use this watchdog.
If you have the terminal (orange/gray box) there is another hardware watchdog located outside of the module. This one does not depend on the Java MIDlets. It can be kicked by RS communication, GPIO or i2c depending on the configuration.
Best regards,
Bartłomiej