unknown reason cause TI GSM modem always return "+CME ERROR: 512"

[sean_chiang@…]

For now, I have no idea what makes TI GSM modem return "+CME ERROR: 512". But
when modem enter this state, no mater what atcommand we send to modem, we always
get "+CME ERROR: 512". Hence, we couldn't make phone call anymore.

[sean_chiang@…]

gsm.log

[sean_chiang@…]

another gsm log from neo(gta01)

[sean_chiang@…]

retrieve imsi when init gsm

[sean_chiang@…]

Fixed it

[sean_chiang@…]

It still happen, but now I could re-produce it.

1. Make our test environment simple

stop xserver, and kill phone-kit process

2. camp to network first through libgsmd-tool

3. Try this command 2 times, then I got "+CME ERROR 512" at second time.

libgsmd-tool -m shell < test
The content of test is:

n

S=5
D0937xxxxxx
S=10
H
S=5

4. After we got "+CME ERROR 512", TI GSM modem is out of control.

Whatever atcommand(ex. AT) we send, it always respond "+CME ERROR 512"

[erin_yueh@…]

i tried to reproduce this CME error 512 with your steps, but i didn't get this
error. -erin

[erin_yueh@…]

but i got cme error 512 from #1195 cnum test case.

[erin_yueh@…]

oops...... i wrote a wrong test case, and i forgot the first 'n' command.
after using this test case, i got that magic error code too!

[balrogg@…]

Hi,
probably not very helpful, but I remember my Calypso modem on GTA01 sometimes
getting into a loop where it would only give a +CME error on anything I do until
I reset it. It was not reproducible - when it happened for the first time, I
tried to reproduce it and couldn't, but another day ran into it again. It was a
long time ago.

I don't know what the error code was because I was using the AT+CMEE=2 mode
(textual errors) so it was something like:

+CME: Operation in progress

or something similar, but it was a non-standard error (i.e. it was not in the
GSM specs when I checked). I only hit it when manually using the serial port
with "cu".

The modem was printing this error on every *character* I typed, not every
command (unless pasting commands). So if I typed AT+ABC slowly, I would get:

A
+CME: Operation in progress
T
+CME: Operation in progress
+
+CME: Operation in progress
A
+CME: Operation in progress
B
+CME: Operation in progress
C
+CME: Operation in progress

[balrogg@…]

So I think it's not a gsmd bug.

[sean_chiang@…]

Yes, not gsmd problem, the problem definitely is coming from GSM firmware. If we
remove the "AT+COLP=1" in gsmd_initsettings2(), then it won't happen anymore.

[mickey@…]

Is this really the latest firmware from TI? I have the very uncomfortable
feeling that some of our problems are not due to kernel serial port or gsmd but
actually due to the firmware. Can we double check that with TI?

[sean_chiang@…]

It's the latest TI GSM firmware from TI, if "latest" means from TI. Because we
had already do some modification since the lastest firmware delievered from TI.
Before solve this from firmware side, we'll have a work-around from gsmd side.

[mickey@…]

Ok, I just managed to get to this state again. I did multiple sequences of
at+cops=? followed by cancelling (sending any other character) the command. It
seems the AT interpreter or firmware state machine inside the modem just hangs
somewhere undefined.

Additional remarks:

• There does not seem to be a concrete way to trigger this state. It seems

unrelated to any sequence of commands. It's just that commands with long
execution time seem to trigger it more often.

• It also happens in MUXing mode and it only renders one channel unusable. The

other channels still work as expected.

• There does not seem a way to recover from this state. Even closing and

reopening the virtual channel does not fix the problem. Even waiting one hour
does not fix the problem. The only way to recover is doing a modem power cycle.

Since the TI Calypso is end-of-life it's highly unlikely that someone will look
into this problem. Since it occurs very rare and also can be detected by a good
parser (which could then transparently trigger the modem power cycle), I'll
close this as WONTFIX.

[zecke]

I fear power cycling is not a good solution.

[octavsly]

I see the same problem here. When, I could not get the call I had:
Sep 3 15:16:17 om-gta02 user.notice root: AtChat? : F : "+CMS ERROR: 512"
Sep 3 15:16:17 om-gta02 user.notice root: AtChat? : T : "AT+CFUN=1"
Sep 3 15:16:17 om-gta02 user.notice root: AtChat? : F : "+CMS ERROR: 512"
Sep 3 15:16:17 om-gta02 user.notice root: AtChat? : T : "AT+CFUN?"
Sep 3 15:16:18 om-gta02 user.notice root: AtChat? : F : "+CMS ERROR: 512"
Sep 3 15:16:18 om-gta02 user.notice root: AtChat? : T : "AT+CMEE=1"

After this the phone keeps on waking up as mention in #1875.
The message this time is:
Sep 3 15:25:19 om-gta02 user.notice root: Modem : void CellModemManager::retryRfLevelRequest() Retrying cfun
Sep 3 15:25:19 om-gta02 user.notice root: AtChat? : F : "ERROR"
Sep 3 15:25:19 om-gta02 user.notice root: AtChat? : T : "AT+CFUN=1"
Sep 3 15:25:19 om-gta02 user.notice root: AtChat? : F : "ERROR"
Sep 3 15:25:19 om-gta02 user.notice root: AtChat? : T : "AT+CFUN?"
Sep 3 15:25:19 om-gta02 user.notice root: AtChat? : F : "ERROR"
Sep 3 15:25:19 om-gta02 user.notice root: AtChat? : T : "AT+CMEE=1"
Sep 3 15:25:19 om-gta02 user.notice root: AtChat? : F : "ERROR"
Sep 3 15:25:19 om-gta02 user.notice root: AtChat? : T : "AT+CFUN=1"
Sep 3 15:25:19 om-gta02 user.notice root: AtChat? : F : "ERROR"
Sep 3 15:25:19 om-gta02 user.notice root: AtChat? : T : "AT+CFUN?"
Sep 3 15:25:19 om-gta02 user.notice root: AtChat? : F : "ERROR"
Sep 3 15:25:19 om-gta02 user.notice root: AtChat? : T : "AT+CMEE=1"
Sep 3 15:25:19 om-gta02 user.notice root: Modem : void CellModemManager::retryRfLevelRequest() Retrying cfun
Sep 3 15:25:19 om-gta02 user.notice root: AtChat? : F : "ERROR"
Sep 3 15:25:19 om-gta02 user.notice root: Modem : void CellModemManager::retryRfLevelRequest() Retrying cfun
Sep 3 15:25:19 om-gta02 user.notice root: AtChat? : T : "AT+CFUN=1"

[octavsly]

Attachements of ticket 1738 (requested to be moved here)

[Treviño]

Restart the GSM modem on firmware crash

[Treviño]

Hello, I've tried to improve the management of this issue with the patch above. Since all the times I got this crash I was able to recover my phone simply restarting the GSM interface with:

killall qpe
echo 0 > /sys/devices/platform/neo1973-pm-gsm.0/power_on
echo 1 > /sys/devices/platform/neo1973-pm-gsm.0/power_on
qpe

I've tried to get the same from the modem plugin. Now qtopia should restart the gsm interface and then reconfigure the plugin as on first run.

Unfortunately I couldn't try this (since fortunately I had no crash in the past days :D), but I hope it will work.

[wendy_hung]

Don't know if it helps, but here is the logread that i happened with this problem. block with #1738.
use the testing branch image flash at 10/28, opkg update/upgrade at 10/29

[mickey]

Fwiw, I learned from the GSM firmware that this error means "unable to cancel command". The gsm server should be very careful not to try cancelling a command twice. Also, some commands should not be cancelled (i.e. +COPS=?). Cancelling an ATD seems to work fine, so every gsm server using the MUX mode should be able to get away without provoking this illegal state -- or at least transparently power-cycle the modem after you encounter this message. The core problem is definitely in the firmware, but it's unlikely we will see a fix for that.

[mickey]

I just got the first report from someone whose 512 was fixed by updating to moko10-beta2 firmware. Although this may be unrelated (since we still don't know which exact conditions lead to 512), it may be worthwhile to try. 512 may be connected to Om ticket #666.

[mickey]

Someone also needs to double check whether http://docs.openmoko.org/trac/changeset/3964 has any effect on 512 or not.

[joerg]

added to CC

[mickey]

Seems pretty much contained with disabling +COLP. Has anyone seen it _with_ +COLP=0?

[mickey]

+COLP=0 and moko11 fixes this for good.