From: Marcel Holtmann <marcel@holtmann.org>
To: ofono@ofono.org
Subject: Re: [Gta04-owner] HSO modem, apparent confusion between App and Control ports
Date: Mon, 27 Feb 2012 22:21:10 -0800 [thread overview]
Message-ID: <1330410070.3392.78.camel@aeonflux> (raw)
In-Reply-To: <87r4xfgbj4.fsf@neil-laptop.ossau.uklinux.net>
[-- Attachment #1: Type: text/plain, Size: 3991 bytes --]
Hi Neil,
> I'm using an HSO modem in a GTA04 device, and have a UI that, on session
> startup, powers the modem on, and sets it online.
>
> Sometimes - after roughly 50% of reboots - the setting online times out,
> and I've established that this is because there's still a preceding
> command in chat->command_queue, when hso_set_online() is called. So the
> real problem is that the preceding AT command appears to the code not to
> have completed.
>
> I've looked at the logs and identified a significant-looking difference
> between a good run and a bad one. In a good run, the ofonod log
> (following powering on), leading up to the point of divergence, has:
>
> Feb 27 22:01:59 gta04 daemon.info ofonod[983]: Control: > AT_OERCN?\r
> Feb 27 22:01:59 gta04 daemon.info ofonod[983]: Control: < \r\n_OERCN: 3, 10\r\n\r\nOK\r\n
> Feb 27 22:01:59 gta04 daemon.debug ofonod[983]: drivers/atmodem/sim.c:oercn_cb() retry counter id=1, val=3
> Feb 27 22:01:59 gta04 daemon.debug ofonod[983]: drivers/atmodem/sim.c:oercn_cb() retry counter id=9, val=10
> Feb 27 22:01:59 gta04 daemon.info ofonod[983]: Control: > AT+CRSM=192,28590\r
> Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n
> Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: > AT+CRSM=176,28589,0,0,4\r
> Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: < \r\n+CRSM: 144,0,"00FFFF02"\r\n\r\nOK\r\n
> Feb 27 22:02:00 gta04 daemon.debug ofonod[983]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90, 00, 4
> Feb 27 22:02:00 gta04 daemon.debug ofonod[983]: src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 4
> Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: > AT+CRSM=192,28438\r
> Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n
>
> But in a bad run, the last line is different:
>
> Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT_OERCN?\r
> Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: < \r\n_OERCN: 3, 10\r\n\r\nOK\r\n
> Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: drivers/atmodem/sim.c:oercn_cb() retry counter id=1, val=3
> Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: drivers/atmodem/sim.c:oercn_cb() retry counter id=9, val=10
> Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT+CRSM=192,28590\r
> Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n
> Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT+CRSM=176,28589,0,0,4\r
> Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: < \r\n+CRSM: 144,0,"00FFFF02"\r\n\r\nOK\r\n
> Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90, 00, 4
> Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 4
> Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT+CRSM=192,28438\r
> Feb 27 21:52:34 gta04 daemon.info ofonod[996]: App: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n\r\n_OSIGQ: 0,0\r\n\r\n+CREG: 0\r\n\r\n+CGREG: 0\r\n\r\n_OSSYSI: 3\r\n
>
> I.e. firstly the AT+CRSM reply appears to be on the wrong channel, and
> secondly it seems to have a whole load of further replies or unsolicited
> indications tacked on.
if this happens, then this modem is seriously broken. Such a broken
behavior will causes the AT chat handler to fail and there is nothing
you can do to restore it into a proper state.
Try to put the SIM atom onto the application port and see if that helps
a bit to make this reliable.
@@ -435,7 +435,7 @@ static void hso_pre_sim(struct ofono_modem *modem)
ofono_devinfo_create(modem, 0, "atmodem", data->control);
sim = ofono_sim_create(modem, OFONO_VENDOR_OPTION_HSO,
- "atmodem", data->control);
+ "atmodem", data->app);
Regards
Marcel
prev parent reply other threads:[~2012-02-28 6:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-27 22:24 HSO modem, apparent confusion between App and Control ports Neil Jerram
2012-02-28 6:21 ` Marcel Holtmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1330410070.3392.78.camel@aeonflux \
--to=marcel@holtmann.org \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox