[QtMoko] GSM not turning on / registering

[Michael Spacefalcon]

Nick <openmoko-community at njw.me.uk> wrote:

> I haven't been using my phone much recently, but it's always been 
> reasonably reliable when I have. Today I turned it on, and all day 
> it has just said "searching for network".
> [...]
> I'm not sure where to go or what to look for to debug this. I've 
> restarted the phone multiple times without success.

What modem firmware version is this?

> Any advice?

Since the GSM modem is no longer an impenetrable black box, you could
try debugging the apparently misbehaving modem using standard Free
Software debugging methods: study the source and the documentation,
and make use of the modem debug interface accessible via the headset
jack.

Start by taking QtMoko high-level software out of the equation and
talking AT commands directly to the modem:

http://wiki.openmoko.org/wiki/Manually_using_GSM

Try the AT commands shown on that wiki page, and tell us the results.
That right there might spot an issue.

If the modem behavior at the AT command level is that of failing to
register for no good reason, the next debugging step would be to look
at the debug trace output.  Get a debug cable, if you haven't already:

http://bb.osmocom.org/trac/wiki/Hardware/SerialCable

Put the debug serial channel on the headset jack with this command:

echo 1 > /sys/bus/platform/devices/gta02-pm-gsm.0/download

Make sure the audio is routed to your Neo's earpiece speaker and not
the loudspeaker, to avoid damaging the latter or your ears.  Plug the
debug serial cable into the headset jack, and plug the other end into
your PC or other host computer running GNU/Linux or some other Unix.
Run the rvtdump utility from the FreeCalypso suite, e.g.,

rvtdump -l logfile /dev/ttyUSB0

With the serial cable connected, rvtdump running on the other end, and
1 written into that /sys/.../download node, power up the modem.  You
should get a bunch of debug output; tell us what you see.  (The -l
option will save this output into a log file, with a timestamp prepended
to each line.)  You should get more interested debug output when you
issue AT+CFUN=1 and AT+COPS commands which start the actual GSM
operation; tell us what you see at those steps as well.

If the above steps don't reveal anything amiss, next debugging steps
would be to examine firmware state variables in memory with fc-tmsh
and/or send special commands (called "system primitives", enabling more
verbose traces and other debug functions) to the running fw with g23sh,
both of which are FreeCalypso tools operating via the debug interface
(called RVTMUX) presented on that headset jack.  If you are running a
firmware version such as leo2moko for which we have a linker map file,
we can examine every single variable that fw maintains, and the
"system primitives" provided by the GPF component (Condat's Generic
Protocol stack Framework) allows us to capture and examine every
primitive exchanged between GSM protocol stack layers: e.g., we could
see the exchange between L1 and L2, or between RR and MM, etc.

But let's see if you can manage the simpler steps above before I go
into details of what you should peek and poke with fc-tmsh and g23sh
tools - getting the simpler rvtdump working would be a prerequisite
for the more advanced tools anyway.

HTH,
SF