I've managed to get the serial traces:
*Linux trace on latest firmware (works fine):*
(C) 2006-2011 by Harald Welte <hwelte(a)hmw-consulting.de>
This software is FREE SOFTWARE licensed under GNU GPL
Version 0.1.12-fa72 compiled 20110815-230016 by
laforge(a)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(a)hmw-consulting.de>
This software is FREE SOFTWARE licensed under GNU GPL
Version 0.1.12-fa72 compiled 20110815-230016 by
laforge(a)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(a)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(a)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