Status of bug #1024 (periodic signal lost and re-registration)
xbmodder+openmoko at gmail.com
Wed Jan 7 16:13:04 CET 2009
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 <dkogan at cds.caltech.edu> 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
> 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
> I can easily reproduce 1024 most of the time, so I can do experiments
> if needed.
> On Mon, 22 Dec 2008 13:06:27 +0100
> Dieter Spaar <spaar at openmoko.org> wrote:
>> 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
>> - 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,
>> hardware mailing list
>> hardware at lists.openmoko.org
> hardware mailing list
> hardware at lists.openmoko.org
More information about the hardware