Malfunction of EHS5-US related to simcard | Telit Cinterion IoT Developer Community
January 23, 2019 - 3:04pm, 5731 views
Hello
I have the following problem with an EHS5-US module:
I have thousands of EHS5-USs running and suddenly 1 of them stops working after months of doing it correctly. The symptom is verified because the LED of the EHS5 is always off (command AT ^ SLED = 2) and there is no further communication with the module.
Resetting or turn off the power supply (20 seconds without VBat and due to the capacitor in VBat the voltage drops to 1.2V approx.) does not solve the problem.
If, when replacing the module with a new one (tested in the factory), the same simcard that was in the faulty module is used, the same fault is presented in the new module. It is the "simcard of death". If the simcard is removed both modules work normally.
If I reuse the "simcard of death" in the first module that failed now works normally. It seems that using the simcard in another module (which also failed) fixes the problem (this behavior is repeated in all cases).
Can the simcard cause a malfunction in the EHS5-US module?
Where can I find a list of the bugs that the EHS5-US has or had in previous versions?
The EHS5-US reports:
ATI1
Cinterion
EHS5-US
REVISION 03.001
A-REVISION 00.000.31
OK
The shutdown of the module by cutting VBat is done in emergency mode only when after 30 seconds of sending the SMSO command the answer "^ SHUTDOWN" is not obtained or if VCORE or 1.8V from modem is unexpectedly lost.
The log file is based on a circular event queue, each event occupies a size of 32 bytes and stores data to reconstruct the state of what happened (eg Timestamp, error codes, etc.). At the beginning, when the log file does not exist, the file is created (and the first entry of the log indicates the loss of the log file), as new log entries are generated, they are added to the file and when their length reaches the equivalent of 1024 entries (this is a file of 32768 bytes in length), the next event uses the seek function (with the offsent at 0) to overwrite the oldest events. The file never has more than 32768 bytes in length. The modification method is open-write-close in each log entry.
The device has a 12V lead acid battery that is placed before the EHS5 power supply. The battery always feeds the power supply of the EHS5 and its charge is maintained with a charger of the floating type.
I have already sent the email with the schematics.
Thank you.
Regards.
Sergio
Hello,
We've seen the schematics.
There is EMERG_RST line visible on the schematic - this line should be used to reset the module in case of emergency like no reply to AT^SMSO command instead of cutting off the power. Cutting off the power before V180 goes low can potentially be dangerous for the module. Additionally the voltage that remains on BATT+, according to your description is too high. When the module is in power down mode the application interface is switched off and must not be fed from any other voltage source.
My suspicion is that this reset procedure might be responsible for your problems - maybe it has happened in the field that for some reason the second reset procedure (with cutting off the power) was used and after that the device was unable to start the module properly until you left the device unused for a long time.
Best regards,
Bartłomiej
Hi.
Cutting the power VBat and wait 1 minute leaves a voltage of 0.25V so it is verified that there is no gpio with external voltage.
I understand your point of view and I have already changed the way to recover an EHS5 that does not respond by first generating an emergency reset before cutting off the power (and wait 1 minute), only time will tell if that was the problem.
Thank you.
Best regards
Sergio
OK, let's see if it helps.
I think that if there was a log showing that this last chance reset was used and there was no contact with the module after that, it could confirm that this reset procedure was to blame. But the log was not stored to the module - in fact this could mean that it was not stored because the module was not accessible and there is a chance that it was because of this reset. Let's see what the time brings.
Regards,
Bartłomiej