Re: Quectel EC21 with internal GSM MUX

Hi Christian, Denis

On Wed, 2025-10-01 at 10:03 -0500, Denis Kenzior wrote:
> Hi Christian,
>=20
> >=20
> > We are operating this modem with a single physical serial
> > connection between CPU and modem. Starting in AT mode and switching
> > over to GSM 07.10 MUX-ing. If I'm getting this correctly, there are
> > three GSM MUX channels opened: control, aux, and PPP data.
>=20
> Gotcha.=C2=A0 You're using naming conventions of pre-multiplexed devices
> (e.g.
> multiple USB interfaces, 1 AT port per USB interface) and this is
> confusing me.
>=20
> >=20
> > What do you mean with premultiplexed ports? The one serial port we
> > are using starts in plain AT communication mode after powering up
> > the device and is then put into GSM 07.10 multiplexing mode.
> >=20
>=20
> Yeah forget I mentioned this :)
>=20
> >=20
> > > You can invoke g_at_chat_send however you like, even one after
> > > the other in the same function.=C2=A0 The underlying implementation
> > > still uses a command queue, so commands will be sent only when
> > > the modem channel is idle, or after receiving a final response
> > > from the modem (ERROR, OK, etc)
> >=20
> > Thank you for clarifying this. Last weeks debugging brought me to
> > the point where I found the command list in g_at_chat and I got up
> > to the point where additional instrumentation below have_line gives
> > me the following:
> >=20
> > =C2=A0=C2=A0=C2=A0=C2=A0 Sep 26 09:43:25 target ofonod[2502]: chat_wake=
up_writer
> > =C2=A0=C2=A0=C2=A0=C2=A0 Sep 26 09:43:25 target ofonod[2502]: Aux: > AT=
E0; &C0;
> > +CMEE=3D1\r
> > =C2=A0=C2=A0=C2=A0=C2=A0 Sep 26 09:43:25 target ofonod[2502]: Aux: < \r=
\nOK\r\n
> > =C2=A0=C2=A0=C2=A0=C2=A0 Sep 26 09:43:25 target ofonod[2502]: have_line=
(0x5d6e78, "OK")
> > =C2=A0=C2=A0=C2=A0=C2=A0 Sep 26 09:43:25 target ofonod[2502]:
> > at_chat_handle_command_response(0x5d6e78, ..., "OK")
> > =C2=A0=C2=A0=C2=A0=C2=A0 Sep 26 09:43:25 target ofonod[2502]: checking =
common
> > terminators
> > =C2=A0=C2=A0=C2=A0=C2=A0 Sep 26 09:43:25 target ofonod[2502]: at_chat_f=
inish_command
> > =C2=A0=C2=A0=C2=A0=C2=A0 Sep 26 09:43:25 target ofonod[2502]: command q=
ueue not empty
> > =C2=A0=C2=A0=C2=A0=C2=A0 Sep 26 09:43:25 target ofonod[2502]: chat_wake=
up_writer
>=20
> Here's how GAtChat operates:
> - When 1 or more commands are queued up via g_at_chat_send(), GAtChat
> checks if
> there's a command in progress.=C2=A0 If there is, it waits for the final
> response.
> - If the modem is idle, it wakes up the writer.=C2=A0 This sets up poll t=
o
> notify the
> application using POLLOUT.
> - When POLLOUT arrives, the command is sent to the kernel via
> write().
> - When POLLIN arrives, the command response is processed
> - If it is a final response, go back to step 1.
>=20
> What seems to be happening is that POLLOUT is somehow broken on this
> particular
> device.=C2=A0 I imagine the kernel suffers from the same problem.

Could it be hardware flow control that not configured right on either
end? I remember having issues with both swapped cts/rts lines, and with
floating signals (i.e. halt/flow state could change by putting a finger
on the board).

// Martin