^SYSSTART DOWNLOAD MODE | Telit Cinterion IoT Developer Community
September 4, 2015 - 11:35am, 5399 views
I have a PLS8-E module that is acting strange.
When I connect it it gets enumerated and I get all USB serials and such. But none of them is replying to AT-comands. But I can download new firmware on one of the ports if I use a firmware tool in recovery mode, (one that skips AT^SFDL). When doing this the module responds whit ANSWER_OK, (0x01 byte), to all uploaded data. After download the module restarts but it does not change its behaviour.
I have also connected to the ASC0-port. And there I always get an "^SYSSTART DOWNLOAD MODE" when the module starts. I can also upload to this port in recovery mode, but the problem persists here too.
So is there anything more I can do to try to recover the module?
Hello,
Can you described how this has happened? Do you have other PLS8 modules that are working fine?
Are you using gWinSwup or some custom application?
I'm afraid that if there is no communication with the module and flashing does not hep you can't do much more. Only internal tools may manage to get it working again.
Please contact the distributor or your local technical support.
Regards,
Bartłomiej
We have exactly the same problem. We have developed a PCB for the PLS-8 E(S30960-S3400-A300-1). Seems to me, there are not documented "HW Settings" to force the PLS-8 into the "DOWNLOAD MODE".
Is for that problem any solution known?
Hello,
There's one hardware "trick" that can cause the module to wakeup in the firmware download mode - when you drive the DCD0 line low for example by connecting it to ground when the module boots - please check if this is not the case here.
Regards,
Bartłomiej
Thanks for the information. Could be the reason but I did not connect the DCD0 to GND. I used a null modem cable with loopback handshake.
See at wikipedia /wiki/Null_modem#Loopback_handshaking
That means DTR, DCD and DSR are connected and RTS and CTS as well. Only GND, Rx and Tx are routed to the opposite device.
I can not test it on short term because the trace on the PCB is under the PLS8 between the LGAs.
Sadly there is nothing in the documentation about that feature and so no chance to avoid dangerous wiring.
Hello,
So this could be it. And it would be important to check it before going further with investigation.
We have recently found out that it is not documented unlike it is for some other module type that also has this feature. So it should be corrected in a future.
Regards,
Bartłomiej
Hi,
now the PLS8 were resoldered from the PCBs, the null modem wiring with loopback handshake were removed from the PCBs and the PLS8 were soldered again.
Now is working as expected. The null modem wiring with loopback handshake was the problem.
Sadly there was noting about the "trick" in the, for me available, documentation and that took me a lot of time and money.
I have learned now one "trick", but the question is, are there more "tricks" or hidden features?
Is it possible to receive a paper where all "tricks" and hidden features are documented?
Hello,
I'm happy that the problem was solved and I'm sorry for that situation.
Unfortunately there's no special document with all the "tricks" because that "trick" was in fact a documentation defect because the same feature was documented in some other module type. I was able to inform you about it because we have recently learned about this inconsistency from some other customer. So I suppose that it should be fixed in the documentation soon.
I encourage you, especially in case of problems, to use the forum and/or support packages for consultations and help.
Best regards,
Bartłomiej