sim hot swap problem with Telit GE910-QUAD

Aleksander Morgado aleksander at aleksander.es
Mon Jul 24 10:16:38 UTC 2017


On Mon, Jul 24, 2017 at 12:02 PM, Carlo Lobrano <c.lobrano at gmail.com> wrote:
>> What would happen if you completely disable and enable the handlers > with
>> the method I'm suggesting, and then you just let the #QSS=1 > indication
>> happen? If the modem already had a SIM inserted, an extra > #QSS=1 wouldn't
>> harm, right? Won't it be just ignored when it's
>> processed?
>
> You're right, we don't need to process #QSS=1, but we absolutely need to
> wait for it before sending any other SIM command.
>
> Since #QSS=1 arrives in a couple of seconds, even a sleep will do, but if
> anything goes wrong we will get stuck in the next command (not sure if it is
> a bug, but it looks like it to me).
>

I see, so yes, we do need to wait for the #QSS.

> In the meantime I tried the my proposal and I'm not really sure about how to
> wait for the unsolicited. I cannot let the thread go on, otherwise we call
> +CRSM and get stuck, but if I put a simple sleep, we do not process any
> unsolicited...
>

So, you're running an async operation (GSimpleAsyncResult or GTask).
The logic won't go on unless you complete it, and you want to complete
it only after receiving the indication or a give timeout happens.

You solve this by setting up a timeout, e.g.
g_timeout_add_seconds(3...) that will be triggered if you don't get
the unsolicited indication. If the timeout happens, you complete the
async method (you stored previously the GSimpleAsyncResult or GTask in
private info). If the unsolicited message arrives, you also complete
the async method, but you also cancel the timeout (so you also stored
the timeout id in private info). The difference between a plain
sleep() and a timeout via g_timeout_add_seconds() is that the former
blocks the running thread, while the latter leaves the main loop
running during the timeout (so unsolicited messages are processed).

-- 
Aleksander
https://aleksander.es


More information about the ModemManager-devel mailing list