What now? How to proceed debugging this GSM/kernel problem?

[Harald Welte]

On Sun, Apr 20, 2008 at 12:19:11AM -0500, Mike (mwester) wrote:

> c) What are the real-world parameters for the GSM modem with regard to  
> flow-control:
>
>   1) How much data can it buffer internally?

I have tried to find this out given the mixture of proprietary bits and
source code that TI has provided to FIC (yes, this was before Openmoko,
Inc. existed) and was unable to determine it.

Since the communication back then with TI was extremely difficult and we
didn't even get answers to much simpler things, I didn't even bother to
put this in the queue to be resolved by TI.  Probably easier to try to
find this out by experimentation.

>   2) What does it do when its internal buffers fill -- does it throw  
> data away?  Does it transmit despite being flow-controlled?  Is there an  
>  AT command available to alter or control how it behaves?  Can it report 
> internal buffer overflows?  What could trigger it to transmit despite 
> being flow-controlled?

There are different behaviours for this case, which can be programmed
using a TI specific AT command.

> d) If I were to acquire a scope, are the CTS, RTS, and other signals  
> between the GSM and the UART accessible on the debug board?  Are there  
> pads on the phone itself?

RTS (from modem): H-TP1531
CTS (to modem): H-TP1530


MODEM_ON can be measured at R10818 (whose other pad is ground)
GSM_EN can be measured at R1501 (which is NC and whose other pad is GND)

IO1 (EINT1) for the GSM -> CPU waekup interrupt is not on any testpad.
If you need to measure it, I suggest using JTAG to read the GPIO state
registers.

> Now compare that to the next entries in the log.  We suspend, as before.  
>  We resume, as before.  The reason for the resume is clear (incoming  
> data from the modem).  But notice the "E# O" line -- that signifies that  
> at that point in the data stream the S3C2410 UART reported an Overrun  
> error.  The data that follows seems to confirm that -- if you count the  
> characters, you'll come up with 16 characters, and you'll notice that  
> the CMTI message is truncated (one character short; the message is  
> supposed to be terminated by "\r\n", the "\n" is missing (the  
> non-printing characters are replaced by a period in the log, but I went  
> and checked what's really there in the binary data)).

well, if  the S3C2410 reports an overrun, then that means that the
UART has received more characters than software was able to poll.

This basically means that the loss is not between the GSM modem UART and
the S3C2410 UART (since those have hardware flow control to prevent any
overrun), but between the S3C2410 UART hardware and the OS/driver.

Maybe something in the resume path just takes too much time, i.e. the
FIFO of the UART fills, it generates an IRQ, but the driver just can't
process that data fast enough.  To test this, I suggest something like
configuring the MODEM_RTS (nRTS0 of S3C2410) in GPIO mode and set it to
high until the full resume has finished.  After the resume, maybe use
JTAG or some custom kernel hack to manually switch the GPIO function
back to nRTS function (or GPIO output in low).  This way you basically
ensure that the GSM modem is not sending more data, since the hardware
flow control just doesn't prevent it to send any data.  You should not
get a S3C2410 UART Overrun.  If data is now lost, it is really lost in
the GSM modem.

Cheers,
-- 
- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone