Warning: Can't synchronize with repository "(default)" (No changeset 96d22ec3fa3ef6de3ea8dc0d7d398adc9aa071cf in the repository). Look in the Trac log for more information.

Ticket #211 (closed defect: fixed)

Opened 5 years ago

Last modified 4 years ago

TI Calypso enters strange state (+CMS ERROR: 512 on most reqests)

Reported by: daniel Owned by: mickey
Priority: critical Milestone: milestone5
Component: framework/ogsmd Version:
Keywords: Cc:

Description

After suspending and resuming several times I wasn't able to call anyone anymore. Incoming calls were directed to my mailbox, *even* when my phone was awake. Other methods like RetrieveMessagebook? were answered with +CMS ERROR 512 (Failed to abort command).

Attachments

frameworkd.log (207.2 KB) - added by daniel 5 years ago.
frameworkd.2.log (167.8 KB) - added by daniel 4 years ago.

Change History

comment:1 Changed 5 years ago by mickey

  • Milestone changed from milestone4 to milestone5

Root cause is the Calypso Firmware, which should prevent this.

See also http://docs.openmoko.org/trac/ticket/1192 -- I'm going to add a workaround in the TI Calypso modem abstraction before milestone5.

Changed 5 years ago by daniel

comment:2 Changed 5 years ago by D3xter

I flashed moko10beta2 yesterday and now I don't receive any "+CMS ERROR: 512"

comment:3 Changed 4 years ago by daniel

I just got a variation of this problem. After calling out I get CMS ERROR: 512 and ERROR to all commands sent on the misc channel (Look for ATD and following lines), but I was still able to accept an incoming call (look for ATA) on the call channel.

Suspend/resume (issuing commands on the UnsolicitedChannel?) also seemed to work after that.

Note that I haven't flashed moko10beta2 yet.

Changed 4 years ago by daniel

comment:4 Changed 4 years ago by mickey

Yes, that's expected (thanks for confirming!). As +CMS ERROR 512 is a forbidden state in the AT interpreter, it can be broken per-virtual channel.

comment:5 Changed 4 years ago by daniel

Retrying with moko10 now. Would be great if this problem is fixed as it's the most annoying and reoccurring failure mode of my FR at the moment.

comment:6 Changed 4 years ago by daniel

Still happens with moko10

comment:7 Changed 4 years ago by daniel

It seems that issuing AT+COLP=0 in the modem initialization (instead of =1) makes this error go away (or at least appear less often). We should have a look at the init sequence anyway and check what we really need since we don't seem to rely on COLP at all.

comment:8 Changed 4 years ago by daniel

Stress testing through calling continuously seems to indicate that everything is working fine. The following:

cli-framework
>>> def callstress(number, wait1=15, wait2=7):
...  tries = 0                                
...  while True:                              
...   print "Call", tries                     
...   id = gsmcall.Initiate(number, "voice")  
...   time.sleep(wait1)                       
...   gsmcall.Release(id)                     
...   time.sleep(wait2)                       
...   tries = tries + 1                       
...                                         
>>> callstress("+4953134943594196000")

Is at Call 326 now. I'll let it run for 500 calls total, but the failure is already much rarer than before.

comment:9 Changed 4 years ago by mickey

  • Status changed from new to closed
  • Resolution set to fixed

Ok, without being 100% convinced that +COLP=1 is the culprit, it seems to make a difference for you guys. [d32cffd07f1a5a95ef10bfb0677bae9a9f2c9d74] disables that for the Calypso with a big fat warning. Feel free to reopen, if 512 still appears.

Note: See TracTickets for help on using tickets.