Oh, yeah, I may have forgotten to send this to list, but this post reminds me. I have also experienced #1024 when deep_sleep = never. It seems that it auto-recovers pretty quickly though. It also happens for 2-3 minutes, (at a cycle between 15-30 seconds). After a few minutes, the modem goes back to normal like nothing ever happened.
On Wed, Jan 7, 2009 at 6:05 AM, Dima Kogan <[email protected]> wrote: > My phone readily exhibits #1024, so I just spent a bit of time looking > into the stability of the 32KHz oscillator at R1050. I scoped across > C1050, and looked for instabilities in the clock waveform as the phone > repeatedly lost and regained registration. I found none. The waveform > seemed stable at 32.786KHz. I looked at the waveform on a very slow > timescale, looking for dropouts, and on a faster time scale with a long > trigger delay, looking for phase drift. I didn't find any instability > with either method. It's still possible that a very quick instability > got by the scope, and I missed it, but if it's there, it's subtle. I > did not replace the resistor, but I can if you think it would be > useful. > > While playing with this, I discovered that issuing AT%SLEEP=2 does not > completely eliminate recamping for me. If the registration was stable, > and I issued AT%SLEEP=2, no recamping would occur. However, if the > phone was very recently recamping, recamping would continue > even after I issued AT%SLEEP=2. In the new setting it would still > recamp a few times, and then settle and become stable. It feels like in > sleep=4, the phone goes in and out of an unstable state, and that > issuing AT%SLEEP=2 doesn't kick the phone out of this unstable state, > but rather doesn't let this it ENTER the unstable state. > > Another thing I noticed is that when I issue AT%SLEEP=4, the calypso > responds with "EXT: I" and "OK". If registration is stable and I issue > AT%SLEEP=2, I also get "EXT: I" and "OK", and most of the time no > recamping happens (but not always). If recamping was recently > happening, AT%SLEEP=2 only says OK, no "EXT: I". If I issue the command > a second time, I get "EXT: I" also. In this situation, the calypso > seems to always recamp at least once. This is all based on one night's > worth of experimenting, so it's not conclusive, obviously. It may still > be interesting to understand what EXT: I is. It probably doesn't mean > we're currently not in Deep Sleep because that would imply that we're > often NOT in Deep Sleep when the phone is sitting on my desk, doing > nothing (if we're in sleep=4, but registration is stable). Is there a > way to tell if we're CURRENTLY in Deep Sleep? The mickeyterm logs from > my sessions that demonstrate the described behaviour are at > > http://secretsauce.net:5050/recamping.log > > I can easily reproduce 1024 most of the time, so I can do experiments > if needed. > > Dima > > On Mon, 22 Dec 2008 13:06:27 +0100 > Dieter Spaar <[email protected]> wrote: > >> Hello, >> >> >> here is an update about the status of bug #1024. >> >> First some background information why it is so hard for us to >> solve this bug: >> >> >> - we (or better, those who work on the GSM stuff) cannot reproduce >> this bug. >> >> >> - OM does only have a small part of the GSM firmware as source code. >> Basically its the AT command interface and some drivers. The rest >> is delivered by TI as binary libraries only, especially the GSM >> protocol stack and Layer 1. So we cannot just have a look at the >> source code and search for errors. >> >> >> - To get an impression of what we talk about, here are some C metric >> numbers from a comparable GSM firmware: >> >> GSM Protocol stack: 700 files 400.000 lines 127.000 >> statements Layer 1: 130 file 130.000 lines 31.000 >> statements >> >> >> - the actual low-level RF work of decoding the GSM frames is done >> by the DSP in the Calypso (there is an ARM and a DSP core inside). >> The DSP has its code in ROM and OM has no documentation about it. >> >> >> - The Calypso chipset is already "end of life" for quite some time, >> there is not much support from TI for it any more. >> >> >> The above should be no excuse, it should show why it is rather >> difficult for us to fix this problem. >> >> What we know so far about #1024: >> >> - We have some PCO2 traces (PCO2 is an internal TI tool) which show >> that in Idle Mode (the phone is registered to the cell but there >> is no voice or data traffic) the periodic reading of the BCCH >> (Broadcast Control Channel) of the serving cell at some point fails. >> We don't know yet what exactly fails, just that an error flag set. >> When this happens, the error does no longer go away and most >> certainly after some timeout causes the "signal lost" indication and >> finally the re-registering in the cell. >> >> >> - In traces where bug #1024 does not occur, this error flag is only >> set very rarely. And if it is set, it usually goes away within the >> next few readings. This is similar if the "AT%SLEEP" workaround is >> applied, the error flag is nearly never set. >> >> >> - This periodic reading of the BCCH occur about every two seconds, >> there is no difference with or without #1024 occurring. >> >> >> - This periodic reading basically works like that: A special >> timer ("special" because it is designed to support the >> GSM frame timing very well) is programmed to wake up the >> chip at the correct time so that the GSM frame of interest >> can be received. Then the chip starts to sleep and waits >> for the interrupt of the timer. There are two different >> sleep modes, "Big Sleep" and "Deep Sleep". >> >> >> - #1024 only occurs if "Deep Sleep" mode is active (this is the >> standard behaviour, AT%SLEEP=2 disables it and only "Big Sleep" >> is used). The special thing about "Deep Sleep" mode is that the >> fast oscillator of the Calypso is turned off and it relies on the >> 32kHz oscillator only. >> >> >> - "Big Sleep" draws less current than "Deep Sleep" so its not a >> perfect workaround to disable "Deep Sleep" completely. We have not >> yet measured how exact the standby time of the phone is influenced >> if "Deep Sleep" is turned off. I assume that it has an influence >> which should not be neglected. >> >> >> There are several open questions: >> >> >> - The problem could come from "drifting away" in "Deep Sleep" mode >> from the right point of time to receive the frame. The firmware does >> some adjusting of the 32kHz oscillator, but there are several things >> which could go wrong (software and/or hardware issue). >> >> >> - We should check the 32kHz oscillator, especially have a look at >> the 220k resistor R1050. In one of the Calypso docs and in the TI >> reference implementation this resistor is 100k. TI is very picky >> about the 32KHz resonator, they mention quite a lot of things >> about what to take care. Is there a reason why we choose 220k ? >> >> >> - Is there a regular pattern when bug #1024 occurs ? For example >> does it depend on temperature ? Or does it depend on the charging >> level of the battery ? >> >> >> - Is there a way to reproduce #1024 ? Does it only occur with >> certain phones ? Or does it depend on the cell where the phone is >> registered ? >> >> Please feel free to add your comments and thoughts, we are really >> trying to fix this problem but we need your help by reporting as much >> details as possible about the circumstances for bug #1024. Thank you >> very much. >> >> Best regards, >> Dieter >> >> _______________________________________________ >> hardware mailing list >> [email protected] >> http://lists.openmoko.org/mailman/listinfo/hardware > > _______________________________________________ > hardware mailing list > [email protected] > http://lists.openmoko.org/mailman/listinfo/hardware > _______________________________________________ hardware mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/hardware
