This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/simtrace@lists.osmocom.org/.
Lukas Kuzmiak lukash at backstep.netI've managed to get the serial traces:
*Linux trace on latest firmware (works fine):*
(C) 2006-2011 by Harald Welte <hwelte at hmw-consulting.de>
This software is FREE SOFTWARE licensed under GNU GPL
Version 0.1.12-fa72 compiled 20110815-230016 by
laforge at nataraja.de.gnumonks.org
DEBUG Interface:
0) Set Pull-up 1) Clear Pull-up 2) Toggle LED1 3) Toggle LED2
9) Reset
RSTC_SR=0x00010200
Inititalizing usbcmd_gen_init
udp_open(437): entering
USART Initializing
pio_irq_register(109): registering handler 0010777c for PIOA 7
ISO_SW Initializing
pio_irq_register(109): registering handler 00107c00 for PIOA 8
pio_irq_register(109): registering handler 00107af4 for PIOA 30
USART Entering Rx Mode
RST
computed Fi(1) Di(1) ratio: 372
MODE: SNIFFER
main(76): entering main (idle) loop
*Mac OS X 10.7 Lion trace (repeats itself over and over and over (red led
blinks every time it resets)):*
(C) 2006-2011 by Harald Welte <hwelte at hmw-consulting.de>
This software is FREE SOFTWARE licensed under GNU GPL
Version 0.1.12-fa72 compiled 20110815-230016 by
laforge at nataraja.de.gnumonks.org
DEBUG Interface:
0) Set Pull-up 1) Clear Pull-up 2) Toggle LED1 3) Toggle LED2
9) Reset
RSTC_SR=0x00010200
Inititalizing usbcmd_gen_init
udp_open(437): entering
USART Initializing
pio_irq_register(109): registering handler 0010777c for PIOA 7
__pio_irq_demux(43): PIO_ISR_STATUS = 0xffffffff
RST
computed Fi(1) Di(1) ratio: 372
ISO_SW Initializing
pio_irq_register(109): registering handler 00107c00 for PIOA 8
pio_irq_register(109): registering handler 00107af4 for PIOA 30
USART Entering Rx Mode
RST
computed Fi(1) Di(1) ratio: 372
MODE: SNIFFER
main(76): entering main (idle) loop
Problem is obviously somewhere in the beginning, Mac OS X trace has these 3
lines more than Linux:
__pio_irq_demux(43): PIO_ISR_STATUS = 0xffffffff
RST
computed Fi(1) Di(1) ratio: 372
I honestly don't know what could be the problem here but perhaps this can
lead someone to an idea :)
Lukas
On Mon, Oct 3, 2011 at 9:47 PM, Lukas Kuzmiak <lukash at backstep.net> wrote:
> Hey,
>
> I can confirm this problem on my fresh OS X 10.7 (Lion) installation.
>
> The IRQ storm bug you're referring to was caused by TCK byte difference
> between T=1 and T=0 protocols and has been fixed in firmware 0.2 (
> http://laforge.gnumonks.org/weblog/2011/08/16/).
> This however should not be related I guess as if you connect the simtrace
> without a phone and simcard attached to it, this bug should not trigger
> (correct me if i'm wrong).
>
> to debugging: you can use a serial cable connected to the 2.5" jack
> (something like FTDI based one for osmocom motorola phones if you have one)
> - that's the debugging interface. I'm currently travelling and don't have my
> usb->serial cable with me so I will check back at home.
>
> Cheers,
> Lukas
>
> On Mon, Oct 3, 2011 at 8:29 PM, Peter Stuge <peter at stuge.se> wrote:
>
>> Holger Hans Peter Freyther wrote:
>> > > Mac OS is really really strict about USB descriptors being correct,
>> > > where both Windows and Linux are more lenient. But the error messages
>> > > say the device would not even accept the address it was assigned, so
>> > > there is some more fundamental problem with the USB firmware. :\
>> >
>> > any debug hints? it will be my first real adventure into the USB
>> > land. Right now I would just play trial and error to see how far in
>> > the setup things go.
>>
>> The device address being assigned by the PC is very very early in the
>> USB enumeration (device discovery after plug-in) process, so
>> something goes wrong pretty early.
>>
>> I understood that the firmware is based on an example firmware from
>> Atmel, so maybe look around their developer resources for any info
>> about known problems with Mac OS.
>>
>> I would probably add some serial output to the firmware in main() and
>> in the USB interrupt handler, and try to see what differs between Mac
>> OS and other systems during enumeration.
>>
>> I recall Harald mentioned an interrupt storm in some circumstances,
>> this could also cause the device address assignment to fail if it
>> isn't fixed already.
>>
>>
>> //Peter
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20111004/abc95f5a/attachment.htm>