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.
* it tries to stay as close to POSIX and other Unix APIs as possible
* you can actually have executable programs in the file system
* it contains a small interactive shell
* the changelog is verbose and releases are frequent
* there's a test suite
* there are already ports to other ARM7TDMI microcontrollers
* there is a small UI framework and the notion of drivers for SPI-
attached LCDs (with 1/2/4 bpp)
* it has tasks and threads, pre-emptive and with priorities
* it has posix message queues, which we could use for passing around
primitives between elements in the stack
* it can be used on Unix-like and Windows/Cygwin host OS
* it has its own scripts to generate toolchains, which means we
could possibly standardize on one of those toolchains
Of course, not everything is perfect
* there seems to be no writeable FS we can put in NOR flash
* it has no scripting language integration (like lua) yet
* i didn't find any memory allocator optimized for pools of objects
of the same size (like 'struct msgb' or the like). Something with
an API [not implementation!] of the SLAB/SLUB in Linux would probably
be a good start.
I've done some example compile runs for arm7, including the shell and
the graphics support (nx example). I end up with an object code size of
something like 70 kilobytes, which is pretty good!
So unless anyone raises major objections, I think we should move ahead
with Nuttx. Who is interested in working on the calypso port?
Let's use this list for coordinating the effort.
As for where to put the code: I already have a git-svn clone of Nuttx,
and will push that to a soon-to-be-created nuttx.git repository on
git.osmocom.org. The core calypso support (irq, uart, spi, etc.) should
all go in that tree. Meanwhile we will figure out how it would be
possibel to keep the gsm related 'application' code out-of-tree from
the nuttx code base.
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)
