GSM bugs

Mike (mwester) mwester at dls.net
Thu May 8 15:55:36 CEST 2008


Holger Freyther wrote:
> On Monday 05 May 2008 22:55:12 Holger Freyther wrote:
> 
>> Looks bad (just by the name):
>>       - #1376, looks bad. The first thing probably to do would be to verify
>> that the modem actually sees the flow control (physically). The bug
>> indicates that the modem is aware of it though.... and verify that it is
>> happening on a GTA02 as well.
> 
> Okay, proxying a comment from a local friend. What you need to test is the 
> following:
> 	- is CTS set to low/0 on suspend?
> 	- is it really zero (on the physical line...) when we go suspend
> 	- when is it cleared?
>         - is this even honored by the modem or connected?
> 
> z.
>

Permit me to clarify the problem so that when someone finds time to look 
at this, they are looking for the _correct_ problem...

The GSM *does* respond to flow-control, it just does so incorrectly.

More specifically, if you take over the appropriate flow-control pin by 
converting it to a GPIO, you will observe that you can cause the GSM to 
cease sending data.  You will also observe while doing this that the GSM 
will interrupt on the GPIO assigned for this purpose.

So, the above proves that the _basic_ functionality of flow-control is 
working per the design.

The problem is that when flow-control is given to the UART to manage 
(i.e. by reverting the I/O pin from the GPIO mode to the UART mode), one 
will occasionally observe that the GSM overruns the UART -- indicating 
that the GSM did not respond to the flow-control from the UART, either 
at all or in a timely fashion.

What I deduce from the above is that:
a) the UART may not be properly sending the flow-control signal
b) the UART may not be in hardware-flow-control mode
c) the GSM may not be responding in a timely fashion to flow-control
d) the GSM may have a logic flaw in regards to flow-control
e) the logic signal itself may be compromised w.r.t fast transitions

A scope would be very useful to determine a) and e) in this list; I have 
no such equipment so I have to focus on what I can observe from the 
software side of things.

Further investigations involved instrumentation of the serial driver, 
specifically testing to see what the state of the UART is at each and 
every I/O operation performed in the driver -- this test shows that the 
serial driver is bad by itself, but when combined with the console on 
the same port it is nothing less than an abomination.  Nevertheless, by 
careful patching and kernel configs and command-line options, it was 
proven conclusively that the UART is in hardware-flow-control at all 
times and yet the overruns can occur.  This removes option b) above.

Google comes up with no relevant hits when searching for S3C2410 UART 
errata, bugs, or known issues; this does not rule out option a) but it 
makes it less probable.

Option c) was the one I presumed to be the most likely issue.  However 
there is no means to alter the hardware flow-control threshold on the 
UART; it cannot be changed from 14/16 characters.  However, during this 
part of the investigation, I did take a closer look at the captured 
dumps of the overruns, and observed that the overruns all followed an 
unexpected pattern -- the data received ended with the final line-feed 
character from the GSM.  This is not what I expected, because if the GSM 
is responding slowly to the flow-control, one would logically assume 
that once-in-a-while at least it would manage to respond in mid-message, 
so that the missing data would be limited to a portion in the midst of 
the data stream.  Instead, it appears that once the overrun occurs, the 
GSM does not respond to flow control at all, or it responds so very late 
that the entire message is sent -- resulting in the observed behavior; 
the message is truncated with the final character read being the 
terminating line-feed.

This is far from conclusive, as each of these tests relies on the 
vagaries of the cellular network here, and often requires that it be 
triggered by sending an SMS -- which became an expensive test, in 
addition to tedious, after a while.  Also, the unsolicited messages from 
the GSM are all very short, so the probability of encountering this with 
normal signal quality types of reports is almost zero.  So much more 
testing on this needs to be conducted.

What I do find intriguing is the description by Harald on the wiki, 
regarding how this is supposed to work -- if one reads that carefully, 
one can see that an implementation per that spec would result in a GSM 
that tests for flow-control only before sending an entire message, and 
does not test for flow-control during the transmission of that message 
-- this would explain the observed behavior, and is the reason I include 
  d) in the list.


Regards,
Mike



More information about the openmoko-devel mailing list