mobile - making a call

[eisencah eisenach]

Hello everyone.

After some more digging turns out that removing the "Status 1: 90 00"  from the firrmware the SIM response gets back to the upper layers. 
What I've also noticed is that when the SIM response wasn't getting to the mobile application a L1CTL_RESET was following. My question is : would this L1CTL_RESET
have the effect of removing pending packets from the queue? Cause that would sort of explain why the delay introduced by the debug printing would influence the overall behaviour.

Thanks,
Mihai.


--- On Sun, 5/15/11, eisencah eisenach <wbg_1000 at yahoo.com> wrote:

From: eisencah eisenach <wbg_1000 at yahoo.com>
Subject: Re: Fw: Re: mobile - making a call
To: baseband-devel at lists.osmocom.org
Date: Sunday, May 15, 2011, 5:52 PM

Hi again.
So after some digging I'm quite sure the ADPU response doesn't make it back into the upper layers. My question is , case the osmocon output contains some weird characters (see bellow), I should assume that at that point something went wrong with the serial link? Also is there some flag to compile the firmware such that the prints have no effect, as to offload the serial link?
Thanks,
Mihai.

L1CTL_DATA_REQ (link_id=0x00)
ul=00811fe0, ul->payload=00811fe4, data_ind=00811fe4, data_ind->data=00811fe4 l3h=00811fe4
SIM Request (7): a0 a4 00 00 02 6f 20 
Status 2: 9F 0F
SIM Request (5): a0 c0 00 00 0f 
Status 1: 90 00
SIM Request (14): a0 d6 00 00 09 ff 49 fd 1a 49 8f 70 00 01 
Status 2: 90��Q��L1CTL_PARAM_REQ (ta=1, tx_power=6)
L1CTL_DATA_REQ (link_id=0x00)
ul=00811fe0,
 ul->payload=00811fe4, data_ind=00811fe4, data_ind->data=00811fe4 l3h=00811fe4
L1CTL_DATA_REQ (link_id=0x00)
ul=008123c4, ul->payload=008123c8, data_ind=008123c8, data_ind->data=008123c8 l3h=008123c8



--- On Sat, 5/7/11, Sylvain Munaut <246tnt at gmail.com> wrote:

From: Sylvain Munaut <246tnt at gmail.com>
Subject: Re: Fw: Re: mobile - making a call
To: "eisencah eisenach" <wbg_1000 at yahoo.com>
Cc: baseband-devel at lists.osmocom.org
Date: Saturday, May 7, 2011, 11:07 AM

> So any ideea where to look for the answer to the UPDATE_BINARY message?

No not really ...

But there is a good reason the SIM driver is not in master ... it
sucks at several level, including blocking behavior in interrupt
context IIRC, so it's totally plausible your
 machine speed triggers
some weird things.

My advice would be to:
 - Cleanup the SIM driver
 - Bypass it in the code and try to access a real PCSC device locally
rather than the built in SIM reader.

Both are non-trivial of course.


Cheers,

    Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110613/925bb75b/attachment.htm>