There seems to be a bug in the recovery mechanism:
After an application has been stopped by the “Recovery Mechanism” due to crashing repeatedly, AT+WOPEN=7 (show application’s current state) replies +WOPEN: 7,0 - which means, “application is not started (current mode is AT+WOPEN=0)”
This makes sense.
But, in this state, AT+WOPEN=3 (erase Flash Objects) replies +CME ERROR: 532 - which means, “the embedded application is activated so the objects flash (sic) are not erased”
This does not make sense!
Similarly, in this state, AT+WOPEN=4 (erase application) replies +CME ERROR: 3 - which means, “Operation not allowed”
This also does not make sense - and is, presumably, related to the same issue?
We have same issue.
What is worse – there is no way out of it for embedded box.
In fact, it is quite easy to get the module into this state. For example, flood ping it with UDP packets (if it has network interface). This will cause watchdog reset. Keep doing it and, after few resets, module will go into recovery mode.
As far as I know there is no way out of this mode beside reset.
Assuming modem is burried inside remote appliance…
I have logged a TRM request about this issue, but, so far, no useful response.
Let us know if you find anything.
I agree that it’s not great for devices in the field!
However, 2 possible escape routes could be:
AT+WRST
Use an external watchdog device
I don’t think that should trigger the recovery mechanism?
I think the recovery mechanism should only take effect when the reset occurs “immediately” on startup?
Is the “flood ping” a bug in WIP, or a bug in your application? Either way, the bug should be fixed!
