Ticket #1376 (closed defect: fixed)

Opened 9 years ago

Last modified 7 years ago

GSM does not respond to flow control

Reported by: mwester@… Owned by: openmoko-devel
Priority: highest Milestone:
Component: GSM Modem Version: GTA02v6
Severity: critical Keywords:
Cc: buglog@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:


The GSM does not respond to the hardware flow control signals in a timely
manner, resulting in occasional buffer overruns from the UART, and associated
data loss. This happens most often when the GTA0x is brought out of suspend
mode due to incoming call or SMS, with the result being that the call or SMS is

Specifics of the test setup, remediation attempts, and other information will be
happily shared with whomever is assigned to work on this bug.

Briefly, the easiest way to observe this is to have the GSM flow-controlled
during a suspend, then wake the device by sending it an SMS or a call. You'll
observe a buffer overrun approximately 1 out of 10 attempts by default,
depending on timing issues and the length of the message that caused the wakeup.

By changing the point at which the UART interrupts the host CPU from the default
1/2 full to 3/4 full, the problem becomes almost a certainty, with better than 2
out of 3 probability that a buffer overrun will occur.

The UART hardware will signal to flow-control the GSM when the GTA01 UART FIFO
reaches 14 characters deep (it has 16 slots). We can assume that the hardware
does not signal this until after the 14th character is complete, and therefore
it is logical to assume that the GSM will transmit the 15th character before it
can respond to the flow-control -- this would allow one full character time
extra headroom. However, looking at the dumps of the buffers when this overrun
occurs, it does not appear that the overrun is by some small, constant number of
characters (which might indicate a timing issue in the GSM or perhaps the
hardware between it and the host UART). Instead all remaining characters in the
message being transmitted are lost, regardless of the length of the message. In
other words, the behavior is consistent with a GSM that only checks for
flow-control _before sending an entire message_.

Regardless of the cause, the fact is that the GSM does not honor flow-control in
the way it should, which has been proven to cause data-loss on the GTA01, and
based on observed behavior is likely to cause data-loss on the GTA02 as well.

Change History

comment:1 Changed 9 years ago by sean_chiang@…

  • Status changed from new to assigned

comment:2 Changed 9 years ago by roh

  • Owner changed from sean_chiang@… to sean_chiang

comment:3 Changed 9 years ago by mwester@…

Update on this issue, please?

comment:4 Changed 8 years ago by john_lee

  • Owner changed from sean_chiang to openmoko-devel
  • HasPatchForReview unset

comment:5 Changed 7 years ago by joerg

  • Status changed from assigned to closed
  • Resolution set to fixed

I think that's fixed with MOKO10b / MOKO11
Please reopen if the issue persists

Note: See TracTickets for help on using tickets.