Cinterion EHS5 (-E) device nodes | Telit Cinterion IoT Developer Community
February 1, 2021 - 8:36am, 1724 views
we are having problem with Cinterion EHS5-E modem. Device nodes are not correctly created for it after cold boot. For me it seems that the problem is related to the wrong revision number: When device (on cold boot) detects modem revision number (/bcdDevice value) 16.74, only 1 device node (/dev/ttyACM0) is created. After processor reset or software reboot the device detects modem revision number (/bcdDevice value) correctly, as it should be, 17.30, and then all 7 device nodes are created (/dev/ttyACM0-ttyACM6).
Kernel version we are using is 5.4.
Has anyone reported similar problem or do you have any ideas which could cause the issue?
Best Regards, Tuomas
I haven't seen any similar report.
What is exactly the scenario of cold boot - is the module rebooted with At command or powered on after being off etc.? Is it possible to communicate over ACM0 when it happens? Can you paste a part of dmesg output showing the good and bad behavior?
thanks for the answer. Cold boot scenario is that the module is powered on after being off. To is it possible to communicate over ttyACM0 I would say no: I can send e.g. "echo "ATZ" > /dev/ttyACM0" but "cat /dev/ttyACM0" gets never answered. Communication seems working normally when all device nodes ttyACM0-ACM6 appear.
This is the cold boot case:
It doesn't print nothing more after this.
And here after the processor reset or (the whole kernel) software reboot:
Only visible difference is the bcdDevice value 16.74 v 17.30.
I've got Ubuntu with this kernel and it seems to work with it.
If restarting the OS helps it could be some OS issue. BTW how is the device powered? Does OS reboot also mean EHS5 reset? Or the module is still on when the OS reboots?
How exactly do you switch off and then switch on the module when this problem happens?
Can you check the firmware version on the module with 'ATI1' command?
thanks for testing it with the same kernel. Our board is embedded board with Atmel processor, so that may cause some differences with OS and used drivers (atmel-ehci).
EHS5 is powered (operating voltage BATT+) in the same time than the device is power booted (or power for the board is switched on). EHS5 is powered the whole time, also during OS reboot (linux command "reboot"), so OS reboot doesn't mean EHS5 reset.
EHS5 is started by setting GPIO signal connected to EMERG_RST line to 0 and ON line to 1. This start sequence is done every time device is (re)booted. It doesn't matter how long time after the boot the signals are set. If using our old kernel 3.6., modem is working with the same start sequence every time.
VUSB_IN is set in device tree as a "atmel,vbus-gpio".
Trying modem hardware reset using EMERG_RST doesn't resolve the issue, as the same behavior only persists. E.g. 1) device node ttyACM0 spawns 2) modem HW reset using EMERG_RST 3) only ttyACM0 spawns.
Modem reset using AT command is not working if there is only ttyACM0.
and I think bcdDevice value 16.74 is corresponding to revision 02, so it seems like device is somehow getting wrong device descriptor value(s) from modem. I will provide more specific outputs of "lsusb" after I have added that property to our Yocto, maybe on next Monday.
Based on your description it seems that there must be something in your new system which causes this behavior.
There's one thing which could cause that only one interface is enumerated - an external pull down to ground on the DCD0 line during the startup phase causes that the module wakes up in the firmware download ****. But in this case the module reboot would be necessary to switch to the normal ****. So it does not seem to fit in your scenario (that the module is not rebooted with the system) but maybe it's worth checking. In firmware download **** the module would not reply to AT commands.
And do you use RS232 interface? It would be helpful to connect to the module's ASC0 interface and verify if it can reply to AT commands when only one USB is enumerated and also observe when the module reboots (SYSLOADING URC).
the module was unintentionally in firmware download **** due to problems with the GPIO line connected to DCD0 in the new kernel. Thanks for pointing this possibility out! It is strange that I measured BATT+ voltage not changing its level during system reboot but maybe this could be explained by the EMERG_RST signal because I have tried to set it sometimes.
Anyway, the problem is now solved, and thanks for the great support!
Best Regards, Tuomas
Somehow the system reboot must have caused that the module was rebooted without DCD0 pulled down if this was helping to get all interfaces and communicate with the module again.
Anyway it's good that the main problem is diagnosed.