19 Feb
2012
19 Feb
'12
6:30 p.m.
Hi,
I have a git clone from 23.01.2012 and a current git clone.
When I compile both and use the mobile appliation, I have a strange
problem in the current code. Very often I can't send USSD codes (and maybe
also can't communicate in other ways; USSD is the costless way to check
whether I am connected or not).
Ok, this is what I do: I send "service 1 *#21#", wait the answer and the
string "% On Network, normal service: Germany, O2". Then send it again and
so on.
With the old code, I reliable get the answer e.g. "% Status: deactivated".
With the new code, I very often (sometime already when trying first time)
get nothing back and after some seconds only "% Service connection
terminated.".
Can someone confirm this behavior?
Thanks
Tim
19 Feb
19 Feb
11:19 p.m.
On Sun, 19 Feb 2012, Tim Ehlers wrote:
Hi,
(just to tell everyone)
When I compile both and use the mobile appliation, I
have a strange problem
I can now say its not the mobile application (layer23). Its the new
layer1. When using the current mobile application with the old
layer1.compalram.bin, its working.
Cheers
Tim
11:41 p.m.
On Sun, 19 Feb 2012, Sylvain Munaut wrote:
Hi Sylvain,
no, shall I? :)
I just checked out the main branch:
git clone git://git.osmocom.org/osmocom-bb.git
The "old" one is from 23.01. and it seems that layer1 is somehow new since
then. It now shows different string in the phone display and you can't
stop it with just shortly pressing power, but pressing for some seconds.
Cheers
Tim
I can now say
its not the mobile application (layer23). Its the new
layer1. When using the current mobile application with the old
layer1.compalram.bin, its working.
Define "old" ....
Are you using the sylvain/testing branch in both case ? 
11:43 p.m.
Hi,
Yes :)
there is an ugly hack to workaround a known issue ...
Are you using
the sylvain/testing branch in both case ?
no, shall I? :) The "old" one is from 23.01. and it seems
that layer1 is somehow new since
then. It now shows different string in the phone display and you can't stop
it with just shortly pressing power, but pressing for some seconds.
Do you have commit id ?
Cheers,
Sylvain
11:49 p.m.
Sylvain Munaut wrote:
Run e.g. git show and it's the first line.
//Peter
The
"old" one is from 23.01. and it seems that layer1 is somehow new since
then. It now shows different string in the phone display and you can't stop
it with just shortly pressing power, but pressing for some seconds.
Do you have commit id ?
20 Feb
20 Feb
12:02 a.m.
On Sun, 19 Feb 2012, Peter Stuge wrote:
Run e.g. git show and it's the first line.
ahh, you mean the commit id from working tree? It should be
2c02043f490704805c17f787394403de93d0b9c6. But, as I wrote, I don't know
since when (after this commit) the problem exists.
Cheers
Tim
The "old" one is from 23.01. and it seems
that layer1 is somehow new since
then. It now shows different string in the phone display and you can't stop
it with just shortly pressing power, but pressing for some seconds.
Do you have commit id ?
12:16 a.m.
Tim Ehlers wrote:
ahh, you mean the commit id from working tree? It should be
2c02043f490704805c17f787394403de93d0b9c6. But, as I wrote, I don't
know since when (after this commit) the problem exists.
In the newer clone you can also check the commit id, then git bisect
can be used to find which commit introduced the problem.
http://book.git-scm.com/5_finding_issues_-_git_bisect.html
http://progit.org/book/ch6-5.html
//Peter
Do you have commit id ?
Run e.g. git show and it's the first line.
19 Feb
19 Feb
11:53 p.m.
On Sun, 19 Feb 2012, Sylvain Munaut wrote:
Yes :)
there is an ugly hack to workaround a known issue ...
ok, I try that tomorrow.
no, thats the problem. I checked out at 23.01. and the current git. I
know, the tree from 23.01. has a working layer1 (what I wrote in first
mail).
I would tip, that it has to do with the 'git-subtree' update from Harald,
where he wrote:
Are you using the sylvain/testing branch in both case
?
no, shall I? :) The
"old" one is from 23.01. and it seems that layer1 is somehow new
since then. It now shows different string in the phone display and you
can't stop it with just shortly pressing power, but pressing for some
seconds.
Do you have commit id ? Nonetheless, if you experience strange new problems,
the libosmocore
update might be a possible cause.
But its just a guess.
Tim
20 Feb
20 Feb
12:13 p.m.
Le 19/02/12 18:30, Tim Ehlers a écrit :
Hi,
I have a git clone from 23.01.2012 and a current git clone.
When I compile both and use the mobile appliation, I have a strange
problem in the current code. Very often I can't send USSD codes (and
maybe also can't communicate in other ways; USSD is the costless way
to check whether I am connected or not).
Ok, this is what I do: I send "service 1 *#21#", wait the answer and
the string "% On Network, normal service: Germany, O2". Then send it
again and so on.
With the old code, I reliable get the answer e.g. "% Status:
deactivated". With the new code, I very often (sometime already when
trying first time) get nothing back and after some seconds only "%
Service connection terminated.".
Can someone confirm this behavior?
Hi,
I have the same problem (testing with a C123). When this problem occurs,
I have also a lot of "DSP Error Status: 8" and afterwards "DSP Error
Status: 24". With git bisect, I localize the first commit showing this
issue as 7cc4a4b ( Improvement of neighbour cell power measurement task).
Hope this help,
Cheers,
Jean-Pierre
1:14 p.m.
Hi,
I have the same problem (testing with a C123). When
this problem occurs, I
have also a lot of "DSP Error Status: 8" and afterwards "DSP Error
Status:
24". With git bisect, I localize the first commit showing this issue as
7cc4a4b ( Improvement of neighbour cell power measurement task).
Oh yes, that commit looks like a very bad idea ... neigh measurement
should always be on TN 0 ...
Can you try to undo that chunk :
diff --git a/src/target/firmware/layer1/prim_pm.c
b/src/target/firmware/layer1/prim_pm.c
index 07b7209..1630600 100644
--- a/src/target/firmware/layer1/prim_pm.c
+++ b/src/target/firmware/layer1/prim_pm.c
@@ -175,7 +175,8 @@ static int l1s_neigh_pm_cmd(uint8_t num_meas,
* num_meas > 1 */
/* do measurement dummy, in case l1s.neigh_pm.n == 0 */
l1s_rx_win_ctrl((l1s.neigh_pm.n) ?
- l1s.neigh_pm.band_arfcn[l1s.neigh_pm.pos] : 0, L1_RXWIN_PW, 0);
+ l1s.neigh_pm.band_arfcn[l1s.neigh_pm.pos] : 0,
+ L1_RXWIN_PW, l1s.neigh_pm.tn[l1s.neigh_pm.pos]);
/* restore last gain */
rffe_set_gain(last_gain);
And check if it improves things.
Cheers,
Sylvain
1:49 p.m.
Le 20/02/12 13:14, Sylvain Munaut a écrit :
Hi,
Hi Sylvain,
I applied this patch:
diff --git a/src/target/firmware/Makefile b/src/target/firmware/Makefile
index 3af2f67..0e0ec8b 100644
--- a/src/target/firmware/Makefile
+++ b/src/target/firmware/Makefile
@@ -95,7 +95,7 @@ ANY_APP_LIBS+=calypso/libcalypso.a layer1/liblayer1.a
lib/libmini.a comm/libcomm
-include Makefile.inc
# Uncomment this line if you want to enable Tx (Transmit) Support.
-#CFLAGS += -DCONFIG_TX_ENABLE
+CFLAGS += -DCONFIG_TX_ENABLE
# Uncomment this line if you want to write to flash.
#CFLAGS += -DCONFIG_FLASH_WRITE
diff --git a/src/target/firmware/board/compal/highram.lds
b/src/target/firmware/board/compal/highram.lds
index 498a2fa..41786d3 100644
--- a/src/target/firmware/board/compal/highram.lds
+++ b/src/target/firmware/board/compal/highram.lds
@@ -16,9 +16,9 @@ MEMORY
/* lowram: could be anything, we place exception vectors here */
XRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00020000
/* highram binary: our text, initialized data */
- LRAM (rw) : ORIGIN = 0x00820000, LENGTH = 0x00014000
+ LRAM (rw) : ORIGIN = 0x00820000, LENGTH = 0x00015000
/* highram binary: our unitialized data, stacks, heap */
- IRAM (rw) : ORIGIN = 0x00834000, LENGTH = 0x0000c000
+ IRAM (rw) : ORIGIN = 0x00835000, LENGTH = 0x0000c000
}
SECTIONS
{
diff --git a/src/target/firmware/board/compal/ram.lds
b/src/target/firmware/board/compal/ram.lds
index 9503ede..acc72ca 100644
--- a/src/target/firmware/board/compal/ram.lds
+++ b/src/target/firmware/board/compal/ram.lds
@@ -11,9 +11,9 @@ ENTRY(_start)
MEMORY
{
/* compal-loaded binary: our text, initialized data */
- LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00014000
+ LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00015000
/* compal-loaded binary: our unitialized data, stacks, heap */
- IRAM (rw) : ORIGIN = 0x00814000, LENGTH = 0x0000c000
+ IRAM (rw) : ORIGIN = 0x00815000, LENGTH = 0x0000c000
}
SECTIONS
{
diff --git a/src/target/firmware/layer1/prim_pm.c
b/src/target/firmware/layer1/prim_pm.c
index 1630600..84b5161 100644
--- a/src/target/firmware/layer1/prim_pm.c
+++ b/src/target/firmware/layer1/prim_pm.c
@@ -175,8 +175,7 @@ static int l1s_neigh_pm_cmd(uint8_t num_meas,
* num_meas > 1 */
/* do measurement dummy, in case l1s.neigh_pm.n == 0 */
l1s_rx_win_ctrl((l1s.neigh_pm.n) ?
- l1s.neigh_pm.band_arfcn[l1s.neigh_pm.pos] : 0,
- L1_RXWIN_PW, l1s.neigh_pm.tn[l1s.neigh_pm.pos]);
+ l1s.neigh_pm.band_arfcn[l1s.neigh_pm.pos] : 0, L1_RXWIN_PW, 0);
/* restore last gain */
rffe_set_gain(last_gain);
The issue is not solved with this. I still have plenty DSP Error Status
in the Layer1 output (in attachment). And I can not request any service
(*#21# for exemple).
Cheers,
Jean-Pierre
I have the same problem (testing with a C123).
When this problem occurs, I
have also a lot of "DSP Error Status: 8" and afterwards "DSP Error
Status:
24". With git bisect, I localize the first commit showing this issue as
7cc4a4b ( Improvement of neighbour cell power measurement task).
Oh yes, that
commit looks like a very bad idea ... neigh measurement
should always be on TN 0 ...
Can you try to undo that chunk :
7:44 p.m.
On Mon, 20 Feb 2012, Jean-Pierre Szikora wrote:
Hi,
I have the same problem (testing with a C123). When
this problem occurs, I
have also a lot of "DSP Error Status: 8" and afterwards "DSP Error
Status:
24". With git bisect, I localize the first commit showing this issue as
7cc4a4b ( Improvement of neighbour cell power measurement task).
Hope this help,
yes, very much. I had problems with bisect. It told me, that there are
more than 550 revisions to check and most of them where older than the bad
one... So you findings helped me to track the problem down to this:
--- mframe_sched.c 2012-02-20 19:37:42.000000000 +0100
+++ mframe_sched.c~ 2012-02-20 19:33:24.000000000 +0100
@@ -200,7 +200,11 @@
/* Measurement for MF 51 */
static const struct mframe_sched_item mf_neigh_pm51[] = {
- { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 50 },
+ { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 0 },
+ { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 10 },
+ { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 20 },
+ { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 30 },
+ { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 40 },
{ .sched_set = NULL }
};
in the changeset 7cc4a4b324bcf65b5d383faf2b3e727953c8df81.
Not that I would understand what this means... :)
Harald can you fix your changes with that info?
Thanks
Tim
8:23 p.m.
On Mon, 20 Feb 2012, Sylvain Munaut wrote:
So reverting that commit fixes your issues ?
yes, it seems so. I mean I don't have longterm tests now, but cloning
current git, reverting the part from the commit I wrote, I made 10
"service 2 *#21#" in a row without problems.
So I assume, that this fixes the issue.
Cheers
Tim
21 Feb
21 Feb
10:58 a.m.
Le 20/02/12 20:23, Tim Ehlers a écrit :
On Mon, 20 Feb 2012, Sylvain Munaut wrote:
I tested it also. Service and SMS sending
is working, but regular call
is still broken (still plenty DSP Error Status in Layer1 output).
Cheers,
Jean-Pierre
So reverting that commit fixes your issues ?
yes, it seems so. I mean I don't have longterm tests now, but cloning
current git, reverting the part from the commit I wrote, I made 10
"service 2 *#21#" in a row without problems.
So I assume, that this fixes the issue.
23 Feb
23 Feb
9:10 a.m.
On Tue, 21 Feb 2012, Jean-Pierre Szikora wrote:
Hi,
I tested it also. Service and SMS sending
is working, but regular call
is still broken (still plenty DSP Error Status in Layer1 output).
yesterday I made a quick call test and you are right, calling is still
broken. I could call a number, it is ringing and after pickup the call is
released (that happend in my quick test yesterday; I didn't have the time
to test more/again).
Could someone check this too? Is there someone, not having problems in the
current git?
Cheers,
Tim
So reverting that commit fixes your issues ?
yes, it seems so. I mean I don't have longterm tests now, but cloning
current git, reverting the part from the commit I wrote, I made 10
"service 2 *#21#" in a row without problems.
So I assume, that this fixes the issue.
9:30 a.m.
yesterday I made a quick call test and you are right,
calling is still
broken. I could call a number, it is ringing and after pickup the call is
released (that happend in my quick test yesterday; I didn't have the time to
test more/again).
Did you use the sylvain/testing branch as a base this time ?
Cheers,
Sylvain
9:47 a.m.
On Thu, 23 Feb 2012, Sylvain Munaut wrote:
Hi Sylvain,
as I can see you mean this patch, right?:
http://bb.osmocom.org/trac/changeset/fe3c81ecc454266b0ccd14a3c0f502db1413f0…
It's the only difference between master and sylvain/testing.
This patch I tried. It doesn't change a thing in this issue. And the call
yesterday was your testing branch plus:
--- mframe_sched.c 2012-02-20 19:37:42.000000000 +0100
+++ mframe_sched.c~ 2012-02-20 19:33:24.000000000 +0100
@@ -200,7 +200,11 @@
/* Measurement for MF 51 */
static const struct mframe_sched_item mf_neigh_pm51[] = {
+ { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 50 },
- { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 0 },
- { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 10 },
- { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 20 },
- { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 30 },
- { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 40 },
{ .sched_set = NULL }
};
Cheers
Tim
yesterday I
made a quick call test and you are right, calling is still
broken. I could call a number, it is ringing and after pickup the call is
released (that happend in my quick test yesterday; I didn't have the time to
test more/again).
Did you use the sylvain/testing branch as a base this time ?
4 Apr
4 Apr
7:54 p.m.
On Thu, 23 Feb 2012, Tim Ehlers wrote:
Hi,
I tested it also. Service and SMS sending
is working, but regular call
is still broken (still plenty DSP Error Status in Layer1 output).
yesterday I made a quick call test and you are right, calling is still
broken. I could call a number, it is ringing and after pickup the call is
released (that happend in my quick test yesterday; I didn't have the time to
test more/again).
Could someone check this too? Is there someone, not having problems in the
current git?
just to acknowledge this patch from Andreas:
http://bb.osmocom.org/trac/changeset/e7997163b240168301d7d2988f2cd74ae1f397…
it fixes the issues I had. Now everything is working again.
Thanks Andreas.
Tim
So reverting
that commit fixes your issues ?
yes, it seems so. I mean I don't have longterm tests now, but cloning
current git, reverting the part from the commit I wrote, I made 10
"service 2 *#21#" in a row without problems.
So I assume, that this fixes the issue.
4414
days inactive
4459
days old
baseband-devel@lists.osmocom.org
20 comments
4 participants
participants (4)
-
Jean-Pierre Szikora -
Peter Stuge -
Sylvain Munaut -
Tim Ehlers