TDI - TP8
TCK - TP17
TDO - TP16
TMS - TP18
Looking at the board from the battery compartment side with the top of the phone pointing North/Up I see at least TP17 is near the right-hand bank of test points visible from the battery compartment. From left-to-right there I see something like: TP12, TP18?, TP16?, TP17 so it looks like I have two of the TPs I need: 17 and
18.
I can't seem to find TP6 or TP8 anywhere on the schematic.
-Craig
---1562933420-544822754-1380899330=:47346
Content-Type: text/html; charset=us-ascii
<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:10pt">I cracked open the shield on my C139 and didn't see the TPs I expected from the schematic. I thought maybe the angle of the photo on osmocom hid the TPs but it really didn't.<br><br>I'll try my C115 instead since that is more clear and accessible. Flashing hello_world on my C115 seemed to fail in a similar fashion as it does on my C139 so maybe the same issue exists there.<br><br>I was wrong too... it was TP16 not TP6, so I found TP16 but still haven't located TP8 on the C139 schematic.<br><br>-Craig<br><div><span><br></span></div><div><br></div> <div style="font-family: arial, helvetica, sans-serif; font-size: 10pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <hr size="1"> <font face="Arial" size="2"> <b><span style="font-weight:bold;">From:</span></b> Craig Comstock
<craig_comstock(a)yahoo.com><br> <b><span style="font-weight: bold;">To:</span></b> "baseband-devel(a)lists.osmocom.org" <baseband-devel(a)lists.osmocom.org> <br> <b><span style="font-weight: bold;">Sent:</span></b> Thursday, October 3, 2013 9:57 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> c139/c140 jtag anyone?<br> </font> </div> <div class="y_msg_container"><br><div id="yiv5755079058"><div><div style="color:#000;background-color:#fff;font-family:arial, helvetica, sans-serif;font-size:10pt;">I'm at the point w/ flashing firmware where I feel like I need to use a debugger w/ JTAG. I figured I could probably use serial line logging somehow but JTAG seems better and I should learn it anyway.<br><br>Has anyone pried open the shield on a c139/c140 and tried attaching to the JTAG test points that are just inside the shield next to the test points which are accessible via the battery compartment?<br><br>From what I can gather from the
schematics:<br>TDI - TP8<br>TCK - TP17<br>TDO - TP16<br>TMS - TP18<br><br>Looking at the board from the battery compartment side with the top of the phone pointing North/Up I see at least TP17 is near the right-hand bank of test points visible from the battery compartment. From left-to-right there I see something like: TP12, TP18?, TP16?, TP17 so it looks like I have two of the TPs I need: 17 and
18.<br><br>I can't seem to find TP6 or TP8 anywhere on the schematic.<br><br>-Craig<br><div><br></div></div></div></div><br><br></div> </div> </div> </div></body></html>
---1562933420-544822754-1380899330=:47346--
TDI - TP8
TCK - TP17
TDO - TP6
TMS - TP18
Looking at the board from the battery compartment side with the top of the phone pointing North/Up I see at least TP17 is near the right-hand bank of test points visible from the battery compartment. From left-to-right there I see something like: TP12, TP18?, TP16?, TP17 so it looks like I have two of the TPs I need: 17 and 18.
I can't seem to find TP6 or TP8 anywhere on the schematic.
-Craig
--344044665-458139408-1380812233=:84280
Content-Type: text/html; charset=us-ascii
<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:10pt">I'm at the point w/ flashing firmware where I feel like I need to use a debugger w/ JTAG. I figured I could probably use serial line logging somehow but JTAG seems better and I should learn it anyway.<br><br>Has anyone pried open the shield on a c139/c140 and tried attaching to the JTAG test points that are just inside the shield next to the test points which are accessible via the battery compartment?<br><br>From what I can gather from the schematics:<br>TDI - TP8<br>TCK - TP17<br>TDO - TP6<br>TMS - TP18<br><br>Looking at the board from the battery compartment side with the top of the phone pointing North/Up I see at least TP17 is near the right-hand bank of test points visible from the battery compartment. From left-to-right there I see something like: TP12, TP18?, TP16?, TP17 so it looks like I have two of the TPs I need: 17 and
18.<br><br>I can't seem to find TP6 or TP8 anywhere on the schematic.<br><br>-Craig<br><div><br></div></div></body></html>
--344044665-458139408-1380812233=:84280--
fed to LAPDm at all. So when you get a L2 packet from L1, instead of
blindly feeding it to LAPDm, you should check a LPD handler table to
know who to feed it to, and for normal channels there would only be
handler for LAPDm and for CBCH channel there would be no LAPDm handler
and only a LPD=01 handler.
> In the future, we can also add the BTS-side implementation. I don't
> think they can share much code,
If they can't share code, then, I would make sure to mark the method
to be 'ms' side so as to keep the namespace clear.
Also, I would stick to the convention we used for sms and name it
something like gsm412_ms_entity (and same for the methods)
> but it might make sense to have both in the same place.
That's not really the policy we used so far. Only shared code goes to
libosmo-xxx
If it ever comes a time where we need it in another project, it'll
still be time to move it there then.
> I can spin a patch series directly on top of osmocom-bb, but the
> testcases will probably not make it.
Why ? layer23 is auto-tools based as well, copying the test suite
stuff from libosmocore shouldn't be too hard.
Cheers,
Sylvain
other but rather completely separate.
And again from the spec, should you expect one or the other on a
channel, you must ignore any packets with the wrong LPD. So AFAIK on a
CBCH channel if you ever get a LPD=00 it should be ignored and not fed
to a LAPDm processor. Same thing for a BTS side LAPDm instance if it
receives a LPD=01 it should be ignored.
Wireshark. Tracing the code shows that it is waiting for some input which
never comes. The only way to get things going again is to stop and restart
ccch_scan.
The issue has been briefly raised in two earlier emails from Altaf and
Joshua with a reply from Sylvain which I have copied below. Although
Sylvain explains the meaning of the error, no solution has been discussed
so far as far as can find.
Studying the code in various apps to see how they handle S_L1CTL_FBSB_ERR,
it seems the only way to get it going is to restart the sync to ARFCN. I do
it by copying code from app_cbch_sniff.c and inserting the following case
option in signal_cb() in app_ccch_scan.c:
case S_L1CTL_FBSB_ERR:
> ms = ((osmobb_fbsb_res *) signal_data)->ms;
> return l1ctl_tx_fbsb_req(ms, ms->test_arfcn,
> L1CTL_FBSB_F_FB01SB, 100, 0, CCCH_MODE_COMBINED,
> dbm2rxlev(-85));
Frankly I do not know what exactly l1ctl_tx_fbsb_req does, but it seems to
work pretty well. Except *very rarely* I find that after processing this
resync, ccch_scan gives repeated data corruptions messages like:
<000c> l1ctl.c:238 Dropping frame with 78 bit errors
repeating endlessly!
Can Holger or Harald who have written ccch_scan please confirm if this is
the correct way to fix the problem or if there is better solution? Can you
please also insert the update in the ccch_scan code in the burst_ind branch
so that others can benefit?
Thanks in advance!
B.
Related earlier emails below:
==========================
From: Altaf <altaf329 <at> gmail.com>
Subject: Re: Osmocom-bb Making a
call<http://news.gmane.org/find-root.php?message_id=%3c1337878154114%2d4013909.p…>
Date: 2012-05-24 16:49:14 GMT (31 weeks, 4 days, 18 hours and 16 minutes
ago)
When I run the Layer23(ccch_scan) application it gives me the following
output on the terminal....
Failed to connect to '/tmp/osmocom_sap'.
Failed during sap_open(), no SIM reader
<000c> l1ctl.c:114 FBSB RESP: result=255
What does it mean.. Can some one help me at this point..
--
*What does FBSB RESP: result=255 mean?*
*Sylvain Munaut* 246tnt at gmail.com
<baseband-devel%40lists.osmocom.org?Subject=Re%3A%20What%20does%20FBSB%20RESP%3A%20result%3D255%20mean%3F&In-Reply-To=%3CCAHL%2Bj08dHmbuRtcwPFeyVVQnpROLCu6n7kZi%3D%3Dat%3DHrbeWtW2A%40mail.gmail.com%3E>
*Thu Apr 26 01:45:42 CEST 2012*
Hi,
>* Running ccch_scan or bcch_scan in the sylvain/burst_ind branch, I keep*>* getting this error:*
bcch_scan doesn't make sense on burst_ind. Only ccch_scan is meant to
do anything useful, all the other apps may do random things becaue
they're not meant for use in burst_ind.
>* <000c> l1ctl.c:114 FBSB RESP: result=255*>**>* I tried checking the code, but I can't quite figure out what's going on. It*>* looks like 255 is an error code, but I don't know where to go from there.*
It just means failure to sync ...
Most likely the ARFCN you gave doesn't carry a valid C0.
Note that it's only tested on 900/1800. US band support is not tested
and probably not functional especially in burst_ind. Fixing it is left
as an exercise to the reader ...
--f46d044468e32d3f9604d2391d02
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>When I run ccch_scan on a regular network, every once in a while, at r=
andom I find the app stops sniffing with the error:</div><div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex">
<000c> l1ctl.c:291 BURST IND: @(1428545 =3D 1077/01/35) (-105 dBm, SN=
R =A0 3, SACCH)<br><000c> l1ctl.c:114 FBSB RESP: result=3D255</blockq=
uote><div><br></div></div><div>At the same time Osmocon gives a message lik=
e the following:</div>
<div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex">=3D> DSP reports FB in bit that is 1031487569 bits=
in the future?!?<br>
Synchronize_TDMA<br>LOST 2313!</blockquote></div><div><br></div><div>The pr=
oblems seems therefore to emerge from some corruption of data in reception =
which causes l1ctl.c to dispatch the=A0<span style=3D"font-family:'cour=
ier new',monospace">S_L1CTL_FBSB_ERR</span>=A0signal.</div>
<div><br></div><div>From this point on ccch_scan ceases to send any further=
messages to Wireshark. Tracing the code shows that it is waiting for some =
input which never comes. The only way to get things going again is to stop =
and restart ccch_scan.</div>
<div><br></div><div>The issue has been briefly raised in two earlier emails=
from Altaf and =A0Joshua with a reply from Sylvain which I have copied bel=
ow. Although Sylvain explains the meaning of the error, no solution has bee=
n discussed so far as far as can find.</div>
<div><br></div><div>Studying the code in various apps to see how they handl=
e=A0<span style=3D"font-family:'courier new',monospace">S_L1CTL_FBS=
B_ERR</span>, it seems the only way to get it going is to restart the sync =
to ARFCN. I do it by copying code from app_cbch_sniff.c and inserting the f=
ollowing case option in=A0signal_cb() in app_ccch_scan.c:</div>
<div><br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><font face=3D"courier new, monospace">=
<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>case S_L1C=
TL_FBSB_ERR: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0=A0<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>ms =3D ((=
osmobb_fbsb_res *) signal_data)->ms;<br><span class=3D"Apple-tab-span" s=
tyle=3D"white-space:pre"> </span>return l1ctl_tx_fbsb_req(ms, ms->test_=
arfcn,<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>L1CTL_FB=
SB_F_FB01SB, 100, 0, CCCH_MODE_COMBINED,<br><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"> </span>dbm2rxlev(-85));</font></blockquote></d=
iv><div>
<br></div><div>Frankly I do not know what exactly=A0<span style=3D"font-fam=
ily:'courier new',monospace">l1ctl_tx_fbsb_req </span>does, but it =
seems to work pretty well. Except *very rarely* I find that after processin=
g this resync, ccch_scan gives repeated data corruptions messages like:</di=
v>
<div><br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><000c> l1ctl.c:238 Dropping fram=
e with 78 bit errors</blockquote>
<div><br></div></div><div>repeating endlessly!</div><div><br></div><div>Can=
Holger or Harald who have written ccch_scan please confirm if this is the =
correct way to fix the problem or if there is better solution? Can you plea=
se also insert the update in the ccch_scan code in the burst_ind branch so =
that others can benefit?</div>
<div><br></div><div>Thanks in advance!</div><div><br></div><div>B.</div><di=
v><br></div>Related earlier emails below:<br><div>=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div><div class=
=3D"headers" style=3D"margin-top:2pt;font-family:arial,sans-serif;font-size=
:medium">
From: Altaf <altaf329 <at> <a href=3D"http://gmail.com">gmail.com<=
/a>><br>Subject:=A0<a target=3D"_top" rel=3D"nofollow" href=3D"http://ne=ws.gmane.org/find-root.php?message_id=3D%3c1337878154114%2d4013909.post%40n=
3.nabble.com%3e" style=3D"color:rgb(0,35,144);font-weight:bold;text-decorat=
ion:initial">Re: Osmocom-bb Making a call</a><br>
Date: 2012-05-24 16:49:14 GMT (31 weeks, 4 days, 18 hours and 16 minutes ag=
o)</div><pre>When I run the Layer23(ccch_scan) application it gives me the =
following
output on the terminal....
Failed to connect to '/tmp/osmocom_sap'.
Failed during sap_open(), no SIM reader
<000c> l1ctl.c:114 FBSB RESP: result=3D255
What does it mean.. Can some one help me at this point..
--</pre><pre><b><u><font size=3D"4" face=3D"arial, helvetica, sans-serif">W=
hat does FBSB RESP: result=3D255 mean?</font></u></b></pre><pre><b style=3D=
"font-family:'Times New Roman';font-size:medium;white-space:normal"=
>Sylvain Munaut</b><span style=3D"font-family:'Times New Roman';fon=
t-size:medium;white-space:normal;background-color:rgb(255,255,255)">=A0</sp=
an><a href=3D"mailto:baseband-devel%40lists.osmocom.org?Subject=3DRe%3A%20W=
hat%20does%20FBSB%20RESP%3A%20result%3D255%20mean%3F&In-Reply-To=3D%3CC=
AHL%2Bj08dHmbuRtcwPFeyVVQnpROLCu6n7kZi%3D%3Dat%3DHrbeWtW2A%40mail.gmail.com=
%3E" title=3D"What does FBSB RESP: result=3D255 mean?" style=3D"font-family=
:'Times New Roman';font-size:medium;white-space:normal">246tnt at g=
mail.com=A0</a><br style=3D"font-family:'Times New Roman';font-size=
:medium;white-space:normal">
<i style=3D"font-family:'Times New Roman';font-size:medium;white-sp=
ace:normal">Thu Apr 26 01:45:42 CEST 2012</i><pre style=3D"white-space:pre-=
wrap">Hi,
><i> Running ccch_scan or bcch_scan in the sylvain/burst_ind branch, I k=
eep
</i>><i> getting this error:
</i>
bcch_scan doesn't make sense on burst_ind. Only ccch_scan is meant to
do anything useful, all the other apps may do random things becaue
they're not meant for use in burst_ind.
><i> <000c> l1ctl.c:114 FBSB RESP: result=3D255
</i>><i>
</i>><i> I tried checking the code, but I can't quite figure out wha=
t's going on. =A0It
</i>><i> looks like 255 is an error code, but I don't know where to =
go from there.
</i>
It just means failure to sync ...
Most likely the ARFCN you gave doesn't carry a valid C0.
Note that it's only tested on 900/1800. US band support is not tested
and probably not functional especially in burst_ind. Fixing it is left
as an exercise to the reader ...
</pre><div><br></div></pre></div>
--f46d044468e32d3f9604d2391d02--
keep doing the same style. Good food makes a brain work better.
> Venue-wise, I would again suggest to hold it in Berlin, as it's
> reasonbly well connected, has lots of low-cost flights to it,
> accomodation is not too expensive and holger/me/sysmocom can take care
> of local organization related activities. Hoewver, if somebody has a
> strong opinion against berlin _and_ is willing to organize it, I'm not
> completely against another venue.
Berlin is perfect.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0=
=B8=D0=BE
http://fairwaves.ru
osmo_auth_load()
osmo_auth_supported()
osmo_auth_gen_vec()
osmo_auth_gen_vec_auts()
osmo_auth_alg_name()
osmo_auth_alg_parse()
You can check the libosmocore/utils/osmo-auc-gen.c example on how they
are used to generate authentication truplets or quintuples.
OpenBSC predates this generic API and should be updated. Once again,
contributions are welcome.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
ISM868 bands that are located adjacent to the GSM 850/900 frequency<br>
allocations.<br>
<br>
My initial investigations and enquiries indicate that this should be<br>
possible by creative programming of the baseband processor in many<br>
models of phones. =A0The trick, as I suspect you well know, is the<br>
difficulty in getting the information and tools required to reprogram<br>
these radios.<br>
<br>
I am now in a position to potentially fund further work on this.<br>
<br>
So, as the open-source group with the most experience reprogramming<br>
baseband radios, what is the feasibility of creating a<br>
proof-of-concept using the types of phones you already work with to<br>
send and receive arbitrary data packets without reliance on a cell<br>
tower (even for time synchronisation)?<br>
<br>
I know there are a lot of constraints and problems, but I am most<br>
interested in creative solutions that can get us to a working<br>
prototype, however crude, that can be used to demonstrate the<br>
feasibility of what I am proposing.<br>
<br>
If this discussion is off-topic here, I am happy to hold the<br>
conversation at the serval-project-developers google group, but I am<br>
equally comfortable with it continuing here.<br>
<br>
Thanks in advance,<br>
<font color=3D"#888888">Paul Gardner-Stephen.<br>
Shuttleworth Telecommunications Fellow at Flinders University.<br>
<br>
</font></blockquote></div><br></div></div>
--0016367b5dfaa9e5ed04abe063a0--
ISM868 bands that are located adjacent to the GSM 850/900 frequency<br>
allocations.<br>
<br>
My initial investigations and enquiries indicate that this should be<br>
possible by creative programming of the baseband processor in many<br>
models of phones. =A0The trick, as I suspect you well know, is the<br>
difficulty in getting the information and tools required to reprogram<br>
these radios.<br>
<br>
I am now in a position to potentially fund further work on this.<br>
<br>
So, as the open-source group with the most experience reprogramming<br>
baseband radios, what is the feasibility of creating a<br>
proof-of-concept using the types of phones you already work with to<br>
send and receive arbitrary data packets without reliance on a cell<br>
tower (even for time synchronisation)?<br>
<br>
I know there are a lot of constraints and problems, but I am most<br>
interested in creative solutions that can get us to a working<br>
prototype, however crude, that can be used to demonstrate the<br>
feasibility of what I am proposing.<br>
<br>
If this discussion is off-topic here, I am happy to hold the<br>
conversation at the serval-project-developers google group, but I am<br>
equally comfortable with it continuing here.<br>
<br>
Thanks in advance,<br>
<font color=3D"#888888">Paul Gardner-Stephen.<br>
Shuttleworth Telecommunications Fellow at Flinders University.<br>
<br>
</font></blockquote></div><br></div></div>
--0016367faa93c4a56b04abdc0ca5--
ISM868 bands that are located adjacent to the GSM 850/900 frequency
allocations.
My initial investigations and enquiries indicate that this should be
possible by creative programming of the baseband processor in many
models of phones. The trick, as I suspect you well know, is the
difficulty in getting the information and tools required to reprogram
these radios.
I am now in a position to potentially fund further work on this.
So, as the open-source group with the most experience reprogramming
baseband radios, what is the feasibility of creating a
proof-of-concept using the types of phones you already work with to
send and receive arbitrary data packets without reliance on a cell
tower (even for time synchronisation)?
I know there are a lot of constraints and problems, but I am most
interested in creative solutions that can get us to a working
prototype, however crude, that can be used to demonstrate the
feasibility of what I am proposing.
If this discussion is off-topic here, I am happy to hold the
conversation at the serval-project-developers google group, but I am
equally comfortable with it continuing here.
Thanks in advance,
Paul Gardner-Stephen.
Shuttleworth Telecommunications Fellow at Flinders University.
