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