I have ordered a C139+cable and I am waiting for it to arrive. I guess
the helloworld and other binaries will run on it but the peripherals
that differ from the C123 will not work. Is that correct?
At work we used ARM7TDMI, now an ARM9, and we looked at FreeRTOS
before going for a custom non-RTOS event-based os. We use the gnu
toolchain and OpenOCD.
So far, I have only used GSM/GPRS from the AT-command level, but it
looks interesting to see more.
While waiting for the hardware I did some trivial patches for osmocon
that are attached. Hope that form (as well as the content :) is
acceptable.
/Erik
Hello Chekov,
On Mon, 01 Mar 2010 02:04:13 +0100, "chekov" <chekov(a)riseup.net> wrote:
> but now i'm stuck, because i get no feedback from the phone, except that
> the display lights up blue.
I think the problem is related to this:
> Received PROMPT2 from phone, starting download
> handle_write(): 4096 bytes (4096/16503)
> handle_write(): 4096 bytes (8192/16503)
> handle_write(): 4096 bytes (12288/16503)
> handle_write(): 4096 bytes (16384/16503)
> handle_write(): 119 bytes (16503/16503)
> handle_write(): finished
> handle_write(): 4096 bytes (4096/16503) <<<<----- this should not happen
> got 1 bytes from modem, data looks like: 1b
This probably means that the downloader does not receive a reply in time
and continues to download the code. You can try to fix it with this
modification:
--- ./src/host/osmocon/osmocon.c Tue Feb 23 18:38:39 2010
+++ /src/host/osmocon/osmocon.c Mon Mar 01 07:59:22 2010
@@ -275,6 +275,7 @@
usleep(1);
} else if (dnload.write_ptr >= dnload.data + dnload.data_len) {
printf("finished\n");
+ dnload.serial_fd.when = BSC_FD_READ;
dnload.write_ptr = dnload.data;
return 1;
}
As a consequence of still sending data to the phone, the firmware
could crash because there was a bug which is already fixed in the
latest GIT version. You can check if you already have the latest
version:
--- ./src/target/firmware/comm/msgb.c Tue Feb 23 18:38:39 2010
+++ /src/target/firmware/comm/msgb.c Sun Feb 28 11:22:57 2010
@@ -35,7 +35,11 @@
#ifdef NO_TALLOC
/* This is a poor mans static allocator for msgb objects */
-#define MSGB_DATA_SIZE 256
+#define MSGB_DATA_SIZE 256+4
#define MSGB_NUM 16
struct supermsg {
uint8_t allocated;
Maybe the above helps to solve the problem.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi!
I'm currently working on getting the integration between l1, l2 and l3
running.
As it seems to me, using at least the RLL part of RSL as an interface
between l2 and l3 seems to make a lot of sense. After all, it contains
all information we need, such as timeslot/subslot/sapi/... and supports
all the various {data,unit_data,establish}{{request,indication} messages.
So my idea is to generate a RSL RLL message in L2 and send ot to L3 and
vice versa.
I'll commit it to the 'uplink' branch as soon as I have something useful.
--
- 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)
hi,
i'm trying to follow this projects developement with my revived Motorola
C118. The wiki helped me making the phone downloading the
hello_world.bin file.
but now i'm stuck, because i get no feedback from the phone, except that
the display lights up blue.
here is what osmocon prints when i make the phone downloading the
hello_world.bin:
$ ./host/osmocon/osmocon -m c118 -p /dev/ttyUSB0
target/firmware/hello_world.bin
got 2 bytes from modem, data looks like: 04 81
got 5 bytes from modem, data looks like: 1b f6 02 00 41
got 1 bytes from modem, data looks like: 01
got 1 bytes from modem, data looks like: 40
Received PROMPT1 from phone, responding with CMD
read_file(target/firmware/hello_world.bin): file_size=16500, hdr_len=0,
dnload_len=16503
got 1 bytes from modem, data looks like: 1b
got 1 bytes from modem, data looks like: f6
got 1 bytes from modem, data looks like: 02
got 1 bytes from modem, data looks like: 00
got 1 bytes from modem, data looks like: 41
got 1 bytes from modem, data looks like: 02
got 1 bytes from modem, data looks like: 43
Received PROMPT2 from phone, starting download
handle_write(): 4096 bytes (4096/16503)
handle_write(): 4096 bytes (8192/16503)
handle_write(): 4096 bytes (12288/16503)
handle_write(): 4096 bytes (16384/16503)
handle_write(): 119 bytes (16503/16503)
handle_write(): finished
handle_write(): 4096 bytes (4096/16503)
got 1 bytes from modem, data looks like: 1b
got 1 bytes from modem, data looks like: f6
got 1 bytes from modem, data looks like: 02
got 1 bytes from modem, data looks like: 00
got 1 bytes from modem, data looks like: 41
got 1 bytes from modem, data looks like: 03
got 1 bytes from modem, data looks like: 42
Received DOWNLOAD ACK from phone, your code is running now!
this also works with -m c118xor
maybe you can create something like a user mailinglist if this kind of
questions produces to much volume.
Hello Joachim,
On Sun, 28 Feb 2010 03:55:12 +0100, "Joachim Steiger" <roh(a)hyte.de> wrote:
>
> ps: according the the schem the vibra should be controlled by the auxdac
> of iota. i poked it and some enable bit few minutes, but couldnt get it
> doing anything.
Have you turned the Auxiliary DAC on ? It has its own power control
bit and bit 5 (ADACS) in TOGBR1 hat to be set to turn the Auxiliary DAC
on. I just did a quick test with a C123, and the following seems to
work:
twl3025_reg_write(TOGBR1, 1 << 5); // turn ADAC on
twl3025_reg_write(AUXDAC, 1000);
delay_ms(1500);
twl3025_reg_write(AUXDAC, 0);
twl3025_reg_write(TOGBR1, 1 << 4); // turn ADAC off
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
sorry for not writing anything earlier, but i'm currently moving so i'm
a bit short of time.
i have been working on the bci and madc block already, so if you are not
already done, i'd like to do that.
its a bit tricky since one needs to do quite a lot to charge the battery
correctly, but in the end we could even charge nimh and i guess small
lead batterys also if we want to (with different code).
i have done the irq handlers, the charger plug in detection and the
async madc stuff is already working.
it just needs some cleanup before commit.
about the bci stuff: i'm now done reading and understanding the iota
datasheets and appnotes (the latter one having invaluable information
not in the datasheets).
'just' need to get it written down in code and debug it. ;)
summary: if you can live with charging your batteries for another week
or 2, just try figuring out the ringer and or vibra for example
ps: according the the schem the vibra should be controlled by the auxdac
of iota. i poked it and some enable bit few minutes, but couldnt get it
doing anything.
so there is still a mystery or 2 left.
kind regards
--
roh
Hi everyone
Without further introduction and in a similar manner to laforge's last
mail I would like to note that I am working on a bootloader that will
allow for larger binaries in RAM and flexible flashing.
To avoid troublesome interaction between the Calypso bootrom (which we
use for interrupt redirection) and CFI support, I have decided to go for
an interrupt-less approach. So don't be surprised to see me committing a
polling mode to fundamental drivers (keypad, uart) sometime soon.
Luckily, the required changes are trivial.
I'll push my branch sometime soon, just dropping a line to keep everyone
informed. Feel free to drop a line in case you are interested in other
flash-based tasks like hammering out linkage details and implementing
some kind of filesystem.
Greetings
prom
Hi!
Just to avoid any possible duplicate work: A member of this list already has a
working C155 color display driver. So if you were thinking of working on
this: Please rather do another TODO item.
I'm supposed to be merging that driver during the next couple of days.
Cheers,
Harald
p.s.: I'm back in Berlin now, will be working with zecke of getting layer2
(bi-directional) up and running.
--
- 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)
Hi,
First I'd like to thank all people involved with the project. I don't
know about GSM but as Harald said [1] I can contribute with
microcontroller development.
I have an old functional Motorola C200 phone. I'd like to know if it's
possible use it? I've search for some information about C200 baseband
processor without success, so I'm asking in the list.
[1] http://lists.osmocom.org/pipermail/baseband-devel/2010-February/000000.html
--tm
