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)):

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