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 <[EMAIL PROTECTED]> http://openmoko.org/ ============================================================================ Software for the world's first truly open Free Software mobile phone
