Hardware Reset for bricked ELS61 | Telit Cinterion IoT Developer Community
March 4, 2019 - 4:40pm, 2407 views
Hi,
I've managed to get an ELS61-E R2 into a bricked state as I have an app loaded that is throwing a nullpointer but when thrown the module then says something along the lines of 'Abnormal exit restarting'. This restarts the app and therefore crashes over and over again. After doing this multiple ***** (around 5) the module will then sit powered on and able to connect via a COM Port but I am unable to talk to it and will go into standby within 5-10minutes.
I cannot access any of the ports as all this happens so quickly. I have even wrote a python script that is running on my PC to try to spam a message that may hopefully get through and stop the app before this happens but had no luck.
So what I am looking for is a hardware pin that I can use to reset the module entirely back to factory settings or something along those lines.
I've also seen the MESFormat tool although cannot get that to format the drive either.
Any advice will be greatly appreciated.
James
Hello,
As such things can happen during the development it is a good idea to implement some strategy to prevent such a scenario. It could be not using the autostart or configuring an autostart delay with "Userware/Autostart/Delay" parameter of AT^SCFG command. Then you have some extra time to disable the failing application. Other solution could be to set 'Oracle-MIDlet-Restart:' to false instead of true in the jad file.
If you haven't configured 'Oracle-MIDlet-Restart-Count:' inside jad file, the default is 3. So the crashing MIDlet should be restarted 3 ***** and then the module should rebooted. I can see that it's a little bit different in your case. Can you write what functionality is implemented in your application?
Unfortunately there is no hardware reset possibility. Usually in such a situation the best idea is to try to send for example AT^SCFG="Userware/Autostart","0" just after the module starts (with a script or just paste the command to termianl). And such a strategy could succeed after a few trials. The chances are bigger if you can do it on ASC0 (if it is enabled, not reserved for system out etc.) interface instead of USB.
Best regards,
Bartłomiej
Hi Bartlomeij,
Yes it was an oversight on my part on what was meant to be a quick fix. Unfortunatly I think this one is completely bricked as I mentioned i wrote script to spam all ports as soon as they come on an that didn't work.
Although I have been testing the "Userware/Autostart/Delay" today on another board and it doesn't actually allow you to enter commands before hand. What I have noticed it completely pauses the boot in ^SYSLOADING and hangs there until the timer is complete then we go into ^SYSSTART. This isn't helpful because before ^SYSSTART you cannot enter any commands.
We have a 'Oracle-MIDlet-Restart-Count' set to 3 currently but it seems after the device comes online and has stopped restarting it self due to the crash the COM ports are inaccessable. Which is why I cannot fix this even after the restarts.
I think in the future I am going to have to implement a timer in my MIDlet rather than on the module that will not start the MIDlet functionality until timer is hit on the app and not device.
Regards,
James
Hello,
You are right about this "Userware/Autostart/Delay" behavior - I have also tested it on my module. It's been changed in this version which I didn't know about. In previous firmware revisions the AT interface was active before ^SYSSTART.
But I'm wondering why you cannot send commands when your MIDlet is crashing or after it has crashed. That's why I have asked about what particular API's you use in your application and what is the functionality. Does it connect to serial interfaces?
There is one more thing that you should pay attention to in the future - in 'Oracle-MIDlet-Autostart:' you should configure a value greater than 1 as this decides about the autostart order. This will prevent your application from being started before JRC MIDlet.
Regards,
Bartłomiej