11 Mar
2010
11 Mar
'10
7:19 p.m.
I'm trying to run the layer1 firmware and the layer23 program
with an C123, however as soon as the firmware reports a layer 1
reset and a L1CTL_NEW_CCCH_REQ message is sent to the phone,
it appears to crash and sends a new PROMPT1, causing an endless
cycle of firmware uploads and following crashes.
Bisection failed due to compiler errors, using trial-and-error
I found that the last instructions successfully executed are in
l1a_l23_rx_cb(), case L1CTL_NEW_CCCH_REQ, just before the
tpu_end_scenario() call. tpu_end_scenario() is what appears to
be triggering the crash, more specifically its the tpu_enable()
call in tpu_end_scenario().
Any hints how to debug this further?
For reference, this is the output of osmocon:
$ ./osmocon -p /dev/ttyUSB0 -m c123xor
../../target/firmware/board/compal_e88/layer1.bin
Received PROMPT1 from phone, responding with CMD
read_file(../../target/firmware/board/compal_e88/layer1.bin):
file_size=35848, hdr_len=4, dnload_len=35855
...
handle_write(): finished
Received DOWNLOAD ACK from phone, your code is running now!
Hello World from apps/layer1/main.c program code
======================================================================
Device ID code: 0xb4fb
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Dropping sample '~'
===
THIS FIRMWARE WAS COMPILED WITHOUT TX SUPPORT!!!
Assert DSP into Reset
Releasing DSP from Reset
Setting some dsp_api.ndb values
Setting API NDB parameters
DSP Download Status: 0x0001
DSP API Version: 0x0000 0x0000
Finishing download phase
DSP Download Status: 0x0002
hdlc_send_to_phone(dlci=5): 01 00 00 00 00 00 14 00
Received PROMPT1 from phone, responding with CMD
read_file(../../target/firmware/board/compal_e88/layer1.bin):
file_size=35848, hdr_len=4, dnload_len=35855
...
Received PROMPT2 from phone, starting download
and so on.
11 Mar
11 Mar
9:14 p.m.
Hi Patrick,
good to have you on board!
On Thu, Mar 11, 2010 at 07:19:04PM +0100, Patrick McHardy wrote:
I'm trying to run the layer1 firmware and the
layer23 program
with an C123, however as soon as the firmware reports a layer 1
reset and a L1CTL_NEW_CCCH_REQ message is sent to the phone,
it appears to crash and sends a new PROMPT1, causing an endless
cycle of firmware uploads and following crashes.
that's something I haven't seen so far yet. Are you using the C123 that
I shipped you (i.e. from the same batch as those I and others use), or
was it obtained somewhere else? In the latter case, it might be some
different hardware version or the like. So far I haven't yet seen any
differences, but well, what do we know about what the manufacturer did.
btw: What about the l1test.bin. This one does a scan over the GSM900
band and then automatically selects the strongest ARFCN (and sends DATA
INDICATIONS to the layer23).
Any hints how to debug this further?
At this point I would say try to eliminate differences to other
developers, i.e. what particular toolchain are you using? Can you try
a layer1.bin compiled by somebody else, just to determine if its
something in the build or something related to your hardware that
we're not doing right yet.
Just my 2 cents from holidays,
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)
12 Mar
12 Mar
12:06 p.m.
Harald Welte wrote:
I'm using the gnuarm.com gcc 4.0 toolchain. I've also tried using
the builds you sent me, no differences. This is what the DSP dumper
shows:
======================================================================
Device ID code: 0xb4fb
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Die ID code: 0c933a10d0039bcf
======================================================================
Assert DSP into Reset
Releasing DSP from Reset
DSP bootloader version 0x0100
DSP dump: Registers [00000-0005f]
00000 : 3000 0008 0008 0008 0e0c 0e0c 181f 2900 0000 0000 0000 0060 0000
0000 0000 3fa6
00010 : 4340 005f 0813 0014 0003 0014 4099 43c0 1100 00ff 0000 8869 8869
ffa8 0000 0000
00020 : 0000 0000 0800 0000 f501 ffff 0000 0000 7fff f802 0000 0000 0000
0000 0000 0000
00030 : 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000
Hi Patrick,
good to have you on board!
On Thu, Mar 11, 2010 at 07:19:04PM +0100, Patrick McHardy wrote:
Yeah, its the one you sent me. I'll try a different one tommorrow.
I'm trying to run the layer1 firmware and the
layer23 program
with an C123, however as soon as the firmware reports a layer 1
reset and a L1CTL_NEW_CCCH_REQ message is sent to the phone,
it appears to crash and sends a new PROMPT1, causing an endless
cycle of firmware uploads and following crashes.
that's something I haven't seen so far yet. Are you using the C123 that
I shipped you (i.e. from the same batch as those I and others use), or
was it obtained somewhere else? In the latter case, it might be some
different hardware version or the like. So far I haven't yet seen any
differences, but well, what do weknow about what the manufacturer did. btw: What about the l1test.bin. This one does a scan
over the GSM900
band and then automatically selects the strongest ARFCN (and sends DATA
INDICATIONS to the layer23).
That shows the same behaviour, after finding the first ARFCN it
restarts with PROMPT1:
...
Assert DSP into Reset
Releasing DSP from Reset
Setting some dsp_api.ndb values
Setting API NDB parameters
DSP Download Status: 0x0001
DSP API Version: 0x0000 0x0000
Finishing download phase
DSP Download Status: 0x0002
DSP API Version: 0x3606 0x0000
Performing power measurement over GSM900
LOST!ARFCN Top 10 Rx Level
ARFCN 22: -41 dBm
Received PROMPT1 from phone, responding with CMD
read_file(/tmp/harald/l1test.bin): file_size=37000, hdr_len=4,
dnload_len=37007
Any hints how
to debug this further?
At this point I would say try to eliminate differences to other
developers, i.e. what particular toolchain are you using? Can you try
a layer1.bin compiled by somebody else, just to determine if its
something in the build or something related to your hardware that
we're not doing right yet. 
1:44 p.m.
On Friday 12 March 2010 12:06:07 Patrick McHardy wrote:
Received PROMPT1 from phone, responding with CMD
read_file(/tmp/harald/l1test.bin): file_size=37000, hdr_len=4,
dnload_len=37007
Hi,
interesting. My conclusion would be you are jumping directly into the reset
vector without having and data/instruction abort? This would mean we directly
jump to 0x0 or wherever the reset vector is located at?
Debug proposals/ideas... maybe you have tried all these:
- Is Hello World surviving?
- If hello world is working, maybe your GSM neighborhood makes our
app just crash? Can you remove the antenna or go to a basement?
- The calypso has a special debug FIFO remembering the latest
instruction and data fetches, prom wrote some support for it... I'm
not sure it will survive the soft reset you are seeing... IIRC we
are relocating the vector tables, so we should be able to dump it
after a reset (in case the content survives that)?
sorry for the wild guesses, I have no idea if that is of any use.
z.
1:55 p.m.
Hi,
I'm using the gnuarm.com gcc 4.0 toolchain.
I've also tried using
the builds you sent me, no differences. This is what the DSP dumper
shows:
Just FYI, The dsp_dumper doesn't work for me either, it panics
(keyboard backlight goes fade in/out). Probably because it outputs too
much data too fast and panics in the console layer ...
Sylvain
14 Mar
14 Mar
5:21 p.m.
On Fri, Mar 12, 2010 at 12:06:07PM +0100, Patrick McHardy wrote:
Yeah, its the one you sent me. I'll try a
different one tommorrow.
any progress / result with that?
Holger and I have discussed your problems yesterday, but we really don't
have an idea at this point.
Some (relatively stupid) ideas to debug it:
1) does hello_world.bin work for you at all?
2) what happens if you change the timing, i.e. add a couple of delays
to see if the reboot happens after a certain fixed wallclock time or
really depends on the code that is executed
3) what about using layer1.bin and the layer23 program on an ARFCN
that is produced by OpenBSC + nanoBTS? This is the most frequently
used setup by Dieter, Holger and myself so far. This way we can
exclude the possibility that something received from the real
operator GSM network in your location causes the problem
Cheers,
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)
15 Mar
15 Mar
2:11 p.m.
Harald Welte wrote:
On Fri, Mar 12, 2010 at 12:06:07PM +0100, Patrick
McHardy wrote:
Yes, I've tried using a different phone and it works fine.
Yeah, its the one you sent me. I'll try a
different one tommorrow.
any progress / result with that? Holger and I have discussed your problems yesterday,
but we really don't
have an idea at this point.
Some (relatively stupid) ideas to debug it:
1) does hello_world.bin work for you at all?
Yes.
2) what happens if you change the timing, i.e. add a
couple of delays
to see if the reboot happens after a certain fixed wallclock time or
really depends on the code that is executed
I've tried disabling the tpu_end_scenario() call, which avoids the
crash. My understanding is that the new settings are not activated
without this, so I guess a good spot would be to add some delays
directly after the tpu_end_scenario() call to see if the crash happens
within the interrupt handlers?
3) what about using layer1.bin and the layer23 program
on an ARFCN
that is produced by OpenBSC + nanoBTS? This is the most frequently
used setup by Dieter, Holger and myself so far. This way we can
exclude the possibility that something received from the real
operator GSM network in your location causes the problem
I'll give that a try.
Thanks!
6:09 p.m.
Hi Patrick,
On Mon, Mar 15, 2010 at 02:11:27PM +0100, Patrick McHardy wrote:
yes.
Harald Welte wrote:
great news!
Then I'll simply assume the phone I sent is broken. Sorry for that. I
can probably have it replaced from the vendor if I get it back. Have
you ever tried to use it on a regular network (using some random SIM)?
On Fri, Mar 12, 2010 at 12:06:07PM +0100, Patrick
McHardy wrote:
Yes, I've tried using a different phone and it works fine. Yeah, its the one you sent me. I'll try a
different one tommorrow.
any progress / result with that? 2) what
happens if you change the timing, i.e. add a couple of delays
to see if the reboot happens after a certain fixed wallclock time or
really depends on the code that is executed
I've tried disabling the tpu_end_scenario() call, which avoids the
crash. My understanding is that the new settings are not activated
without this, so I guess a good spot would be to add some delays
directly after the
tpu_end_scenario() call to see if the crash happens within the
interrupt handlers?
sounds like a possible approach, but if your other phone is working I
doubt there's much point in further debugging.
--
- 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)
16 Mar
16 Mar
2:49 p.m.
Harald Welte wrote:
yes.
Yeah, I'll leave it for now unless someone else runs into the
same problem.
On Mon, Mar 15, 2010 at 02:11:27PM +0100, Patrick
McHardy wrote:
Yes, that works properly. Replacing it is not necessary, one working
phone should be enough for now :)
Harald Welte wrote:
great news!
Then I'll simply assume the phone I sent is broken. Sorry for that. I
can probably have it replaced from the vendor if I get it back. Have
you ever tried to use it on a regular network (using some random SIM)? On Fri, Mar 12, 2010 at 12:06:07PM +0100, Patrick
McHardy wrote:
Yes, I've
tried using a different phone and it works fine. Yeah, its the one you sent me. I'll try a
different one tommorrow.
any progress / result with that? 2) what happens if you change the timing, i.e. add a
couple of delays
to see if the reboot happens after a certain fixed wallclock time or
really depends on the code that is executed
I've tried disabling the
tpu_end_scenario() call, which avoids the
crash. My understanding is that the new settings are not activated
without this, so I guess a good spot would be to add some
delays directly after the
tpu_end_scenario() call to see if the crash happens within the
interrupt handlers?
sounds like a possible approach, but if your other phone is working I
doubt there's much point in further debugging.
5164
days inactive
5169
days old
baseband-devel@lists.osmocom.org
8 comments
4 participants
participants (4)
-
Harald Welte -
Holger Freyther -
Patrick McHardy -
Sylvain Munaut