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 <sp...@openmoko.org> 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 > hardware@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/hardware _______________________________________________ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware