Status of bug #1024 (periodic signal lost and re-registration)

[Dima Kogan]

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 <spaar at 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 at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/hardware