Broken PLS8-e units | Telit Cinterion IoT Developer Community
November 22, 2019 - 1:19pm, 3016 views
We have some products with PLS8-e modules which started to fail. The units will enumerate on the USB bus als Cinterion LTE Modem (1e2d:0061) in the linux kernel messages all subdevices seem to return error -22 and "zero lenght decriptor references) after exactly 60 seconds the device disconnects and start over again.
The following messages are logged in the kernel logging:
usb 1-1.3: USB disconnect, device number 19
usb 1-1.3: new high-speed USB device number 20 using ehci_hcd
cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
cdc_acm 1-1.3:1.2: ttyACM1: USB ACM device
cdc_acm 1-1.3:1.4: ttyACM2: USB ACM device
cdc_acm 1-1.3:1.6: ttyACM3: USB ACM device
cdc_acm 1-1.3:1.8: ttyACM4: USB ACM device
cdc_ether: probe of 1-1.3:1.10 failed with error -32
cdc_acm: probe of 1-1.3:1.10 failed with error -22
cdc_acm 1-1.3:1.11: Zero length descriptor references
cdc_acm: probe of 1-1.3:1.11 failed with error -22
cdc_ether: probe of 1-1.3:1.12 failed with error -32
cdc_acm: probe of 1-1.3:1.12 failed with error -22
cdc_acm 1-1.3:1.13: Zero length descriptor references
cdc_acm: probe of 1-1.3:1.13 failed with error -22
These modules worked when produced but stopped working over time. It looks to me only some piece of bootrom is working but the firmware in the device is corrupted or something like that.
All ttyACM interfaces just give zero reads and no SYSSTART or AT responses are seen.
Are there more customers seeing this kind of problems? Do we just have some faulty units?
This might mean that the modules are restarting or are being restarted for some reason. It's possible that your hardware is failing or the module. Or the module is reenumerating for some other reason in your software.
Is there any posibility to test the same module separately or the same hardware with a different module?
How is the module used in a standard scenario? Was there any firmware update performed which might have failed or any other non-standard actons?
The units are doing this out of their own. We disabled our software and we after turning the module on we do not do anything.
The firmware in this units is never updated, we have received a few broken modules from our customers which al seem to suffer from this issue.
What kind of non-standard actions to you refer to?
For now we can suppose that the module is restarting. You could measure the lines state to verify this. I can imagine that either your board can be failing (module's power circuit malfunction etc.) or the module. If we suppose that it's the module we still don't know what the cause is. Is it the hardware design issue, wrong treatment or the cause is inside the module. By non-standard actions I meant for example possible power outages, power surges, any untypical output from the modules registered in the logs etc.
Anyway if you suspect any issue with the modules I think that you should report it to your local Gemalto office or Gemalto support via SlaesForce (if you have access). There's a dedicated procedure where the modules can be replaced.