CME Error 536/515



This is a follow-up on a post a colleague made in 2013, see [url]]

We are still seeing devices stuck in a state were most AT commands return CME Errors 536 and 515. We are still not sure what the events are that leads up to the lock-up, as we’ve never been able to reproduce it in the lab. With around 1500 devices out in the field, we get one every few weeks that is in this state. We have tried to handle this state in our OpenAT app, but so far we’ve been unsucessful, as it persists accross resets (using AT+CFUN=1,1). The only way up to now to get the device going again is by issuing a AT+WOPEN=0, AT+CFUN=1,1 and AT+WOPEN=1 sequence.

The question is: Is there any way we can recover from this state when we detect it in our app?

Below is the output from a few commands. AT+WSTR seems to indicate that the firmware initialization was never completed.

"DWL","V10c05","","Sierra Wireless",62640,"051513 10:45","a0836b50","00010000"
"FW","FW_752_34_3.SL6087G","R7.52.0.201306260837.SL6087","Sierra Wireless",673436,"062613 08:37","89796368","001d0000"
"MODEM","1.3.36","201306260837.SL6087","Sierra Wireless",1713240,"062613 08:37","85a2fb97","00020000"
"OAT","2.13.408.1","Sefeko Mercury","Gendac (Pty) Ltd",1840120,"040815 18:09","765c6451","002a0000"
 -"Developer Studio",""
 -"Open AT Application Framework package",""
 -"Open AT OS Package",""
 -"Firmware Package",""
 -"Internet Library Package",""
 -"Security Library Package",""

+WLERR: 0,1,"Except RTX: task IDLE, out of kernel envelopes , caller = 0x1577 "
+WLERR: 0,2,"Except RTX: task IDLE, out of kernel envelopes , caller = 0x1577 "
+WLERR: 0,3,"Except RTX: task IDLE, out of kernel envelopes , caller = 0x1577 "
+WLERR: 0,4,"Except RTX: task IDLE, out of kernel envelopes , caller = 0x1577 "
+WLERR: 1,0
+WLERR: 2,292,32760,52



+WSTR: 1,1

+WSTR: 2,0








+WOPEN: 6,2880,1984


+WOPEN: 9,0,1984



I know that it’s a trite answer, but have you tried updating some modules out in the field with later firmware (and recompile your application against the later api)?

I’m working with the Q2698, and there’s been a lot of changes between firmware versions - even between minor firmware versions. Have a chat to your distributor to check if there is any beta firmware that you can test.

Ciao, Dave



We’ve had this issue for years now, using 7.46, 7.47 and 7.52. In every case, we’ve made absolutely sure that the application was compiled for the exact version of firmware we were using.

It looks like this problem is caused by a very specific set of circumstances which we cannot reproduce. To illustrate: We received a unit back from a client that was in this state. We stopped and started the application and took it back to the client at the exact same site and tested it and it was fine.



That’s not good.

One final thought … did you attempt to get any back traces out of the malfunctioning modules?

Ciao, Dave


Backtraces don’t work unfortunately. Developer studio runs out of memory when decoding them. I believe our app is too big.


Just got another unit with the same problem. AT+WOPEN=0, AT+CFUN=1,1 and AT+WOPEN=1 did not recover it.

We did the following:

  1. AT+WOPEN=0
  2. AT+CFUN=1,1 and waited for it to be properly started
  3. AT+CPIN? - This returned SIM PIN
  4. AT+CPIN= - This never completed - no response at all
  5. Waited a while and issued AT+CPIN? - this returned CME ERROR 515.

Looking at our application traces, this is exactly what happens at app startup as well. We receive the ADL_SIM_EVENT_PIN_WAIT event and then call adl_simEnterPIN. This doesn’t seem to ever complete and we never see any furhter SIM events.



Arrrggghhh. Having tools that don’t (can’t?) work is worse than having no tools at all.

ciao, Dave



I have a similar problem - My FX100s get into a state where the response doesn’t match the question and it appears to be one state behind

See my post FX100
AT command ERROR

In addition three letter commands work eq ATI but ATI9 gives error
I cannot recover with CFUN but haven’t tried AT+WOPEN ??
MY only solution is a power cycle -
At the moment I am considering dumping the FX100 as this has been going on for many months
The FXT009s was working perfectly for many months but the FX100 continues to give me grief


Have you tried using the abort command, +WAC?


So it looks like the AT+CPIN command is getting “stuck”.

Have you tried taking the SIM out, and putting it into another unit - ie, is it the SIM that’s somehow “locked-up”?

Similarly, if you put a different SIM into a “stuck” unit, does that “unstick” it?

If I understand you correctly, a “stuck” unit remains “stuck” over a power-cycle - so can you get your distributor to send a “stuck” one to SiWi for examination…:question:


Give a Link :exclamation:


You understand correctly yes - the unit remains stuck. Swapping SIMs doesn’t help.

I had two units that were in the stuck state and I left them without power for a few days. Interestingly, the one unit recovered by itself, while the other unit is still in the state.

I have tried AT+WAC. It returns OK, but has no effect.


If you do at+WIND=32767 to enable all indications, what do you see while the unit starts? How does it compare for “stuck” and “working” units :question:


This is what we get after a reset:

+WIND: 3

+WIND: 13

+WBCI: 0

+WIND: 1


After issuing a AT+CPIN=, we get no further WIND notifications.



I’m not sure you need to send the PUK code when the SIM PIN is required.

I’ve only sent the PUK code when the SIM has been locked by 10 invalid PIN attempts… or when required for other unlock commands.

Ciao, Dave



I’m sure you don’t need the puk, and we don’t normally do it from out OpenAT app. There we use adl_simEnterPIN(). It does result in the same behaviour though.


You may want to consult your modem manual for the meaning of error messages and +CMGS command details! Generally, CMS ERROR: 515 means “Please wait, init or command processing in progress”. I guess, you’re sending a character after the -z, before the SMS text is accepted and confirmed.