29 Sep
2011
29 Sep
'11
9:39 p.m.
Hi
I tried SIMTrace with Gemalto java smart cards and it is working great.
Unfortunately I can’t run it on my shiny Mac OSX (Darwin Kernel Version 10.8.0), hosting
Ubuntu in VMware.
SIMtrace is flashed with the latest firmware (see
http://lists.osmocom.org/pipermail/simtrace/2011-August/000109.html)
If I connect it to my mac the red light is flashing periodically.
In the kernel log I see the following messages:
9/28/11 9:47:05 PM kernel USBF: 428978. 89 [0xadd3100] The IOUSBFamily was not able to
enumerate a device.
9/28/11 9:47:06 PM kernel USBF: 428979.493 [0xadd3100] The IOUSBFamily is having trouble
enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub
at 0x6000000)
9/28/11 9:47:06 PM kernel USBF: 428979.493 [0xadd3100] The IOUSBFamily was not able to
enumerate a device.
9/28/11 9:47:07 PM kernel USBF: 428980.898 [0xadd3100] The IOUSBFamily is having trouble
enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub
at 0x6000000)
9/28/11 9:47:07 PM kernel USBF: 428980.898 [0xadd3100] The IOUSBFamily was not able to
enumerate a device.
9/28/11 9:47:09 PM kernel USBF: 428982.303 [0xadd3100] The IOUSBFamily is having trouble
enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub
at 0x6000000)
....
with logging enabled:
9/29/11 9:10:33 PM kernel USBF: 1466.294 AppleUSBOHCI[0x7679000]::MakeDevice error setting
address. err=0xe00002ed device=0x96d3400 - releasing device
9/29/11 9:10:33 PM kernel USBF: 1466.294 **5**
AppleUSBHubPort[0x77d5c00]::AddDeviceResetChangeHandler - Port 4 of Hub at 0x6000000,
unable to set device 0 to address 0 - disabling port
9/29/11 9:10:33 PM kernel USBF: 1466.296 AppleUSBHubPort[0x77d5c00]::DetachDevice Port 4
of Hub at 0x6000000 being detached (_attachRetry = 0)
9/29/11 9:10:33 PM kernel USBF: 1466.296 [0x77d5c00] The IOUSBFamily is having trouble
enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub
at 0x6000000)
9/29/11 9:10:33 PM kernel USBF: 1466.296 AppleUSBHubPort[0x77d5c00]::DetachDevice - Port 4
of Hub at 0x6000000 - device has gone away
9/29/11 9:10:33 PM kernel USBF: 1466.296 [0x77d5c00] The IOUSBFamily was not able to
enumerate a device.
9/29/11 9:10:34 PM kernel USBF: 1467.700 AppleUSBOHCI[0x7679000]::MakeDevice error setting
address. err=0xe00002ed device=0x96d3400 - releasing device
9/29/11 9:10:34 PM kernel USBF: 1467.700 **5**
AppleUSBHubPort[0x77d5c00]::AddDeviceResetChangeHandler - Port 4 of Hub at 0x6000000,
unable to set device 0 to address 0 - disabling port
9/29/11 9:10:34 PM kernel USBF: 1467.702 AppleUSBHubPort[0x77d5c00]::DetachDevice Port 4
of Hub at 0x6000000 being detached (_attachRetry = 0)
9/29/11 9:10:34 PM kernel USBF: 1467.702 [0x77d5c00] The IOUSBFamily is having trouble
enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub
at 0x6000000)
9/29/11 9:10:34 PM kernel USBF: 1467.702 AppleUSBHubPort[0x77d5c00]::DetachDevice - Port 4
of Hub at 0x6000000 - device has gone away
9/29/11 9:10:34 PM kernel USBF: 1467.702 [0x77d5c00] The IOUSBFamily was not able to
enumerate a device.
9/29/11 9:10:36 PM kernel USBF: 1469.107 AppleUSBOHCI[0x7679000]::MakeDevice error setting
address. err=0xe00002ed device=0x96d3400 - releasing device
9/29/11 9:10:36 PM kernel USBF: 1469.107 **5**
AppleUSBHubPort[0x77d5c00]::AddDeviceResetChangeHandler - Port 4 of Hub at 0x6000000,
unable to set device 0 to address 0 - disabling port
9/29/11 9:10:36 PM kernel USBF: 1469.109 AppleUSBHubPort[0x77d5c00]::DetachDevice Port 4
of Hub at 0x6000000 being detached (_attachRetry = 0)
9/29/11 9:10:36 PM kernel USBF: 1469.109 [0x77d5c00] The IOUSBFamily is having trouble
enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub
at 0x6000000)
9/29/11 9:10:36 PM kernel USBF: 1469.109 AppleUSBHubPort[0x77d5c00]::DetachDevice - Port 4
of Hub at 0x6000000 - device has gone away
9/29/11 9:10:36 PM kernel USBF: 1469.109 [0x77d5c00] The IOUSBFamily was not able to
enumerate a device.
9/29/11 9:10:37 PM kernel USBF: 1470.512 AppleUSBOHCI[0x7679000]::MakeDevice error setting
address. err=0xe00002ed device=0x96d3400 - releasing device
Please find attached also the trace logs form USBProber and usbtracer.
Any ideas how this could be fixed?
Ben
5:12 p.m.
On 10/03/2011 12:26 PM, Holger Hans Peter Freyther wrote:
just a blind guess, at the Camp we had one or two
reports that the device does
not properly enumerate on a USB 3.0 port. Could this apply?
FYI: I tried on a mac (lion) and I can confirm this issue. Will try to play
wit that tomorrow.
7:41 p.m.
Holger Hans Peter Freyther wrote:
On 10/03/2011 12:26 PM, 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. :\
//Peter
just a blind guess, at the Camp we had one or two
reports that
the device does not properly enumerate on a USB 3.0 port. Could
this apply?
FYI: I tried on a mac (lion) and I can confirm this issue. Will try
to play wit that tomorrow.
8:17 p.m.
On 10/03/2011 07:41 PM, Peter Stuge 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.
:)
8:29 p.m.
Holger Hans Peter Freyther wrote:
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
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. 
9:47 p.m.
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:
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
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.
4 Oct
4 Oct
12:35 a.m.
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:
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
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.
11:44 a.m.
On 10/03/2011 08:29 PM, Peter Stuge wrote:
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.
This was related to the UART code, but yes looking at the serial output i see:
RSTC_SR=0x00010200
SRCMP: 1 == Software reset in progress
RSTTYP: 2 == Watchdog reset
so it is stuck somewhere. time to get a USBJtag adapter.. :)
12:48 p.m.
On 10/04/2011 11:44 AM, Holger Hans Peter Freyther wrote:
SRCMP: 1 == Software reset in progress
RSTTYP: 2 == Watchdog reset
so it is stuck somewhere. time to get a USBJtag adapter.. :)
Hi,
I am lacking USB and AT7SAM knowledge here. I made the debug output
synchronous and managed to get here:
udp_irq(imr=0x1200, isr=0x0300, state=5): RXSUSP RXRSM END
udp_irq(imr=0x1200, isr=0x1000, state=5): ENDBUSRES END
udp_irq(imr=0x1203, isr=0x0801, state=5): EP0INT(Control) CSR=0x88804 len=8
bmRequestType=0x80 DATA_IN=1 dfu_state = 0 GET_DESCRIPTOR(wValue=0x0100,
wIndex=0x0000) OUT
So this means that we at least get a USB request to get our descriptor, and
asking for USB_DT_DEVICE.
The call is made to:
udp_ep0_send_data((const char *) &dev_descriptor,
MIN(sizeof(dev_descriptor), wLength));
and it is getting stuck in:
udp_ep0_send_zlp(void) {
AT91PS_UDP pUdp = AT91C_BASE_UDP;
pUdp->UDP_CSR[0] |= AT91C_UDP_TXPKTRDY;
while (!(pUdp->UDP_CSR[0] & AT91C_UDP_TXCOMP)) ;
^^^^ sending never completes
Anyone has a guess? I am going to start to read the Atmel docs now.
11:26 a.m.
On 10/03/2011 08:17 PM, Holger Hans Peter Freyther wrote:
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.
I have a first hypothesis/guess... I think we transmit debug messages on EP3
before the device is configured.
3:34 p.m.
Hello Holger,
On Tue, 04 Oct 2011 12:48:58 +0200, "Holger Hans Peter Freyther"
<holger(a)freyther.de> wrote:
Anyone has a guess? I am going to start to read the Atmel docs now.
I don't have time to debug this issue, but a USB Analyzer trace clearly
shows that the SET ADDRESS command goes wrong.
My guess: The only difference between the Windows and MacOS X trace is
a USB Reset between the GET DESCRIPTOR and SET ADDRESS command on Windows,
the Reset is not there on MacOS X (don't know what Linux does). So I would
look if "upcd.state" is USB_STATE_DEFAULT, if not STD_SET_ADDRESS won't do
anything. From my understanding "upcd.state" is set to USB_STATE_DEFAULT
on a USB Reset, so it might not be initialized properly.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
2:37 p.m.
On 10/04/2011 01:34 PM, Dieter Spaar wrote:
Hello Holger,
I don't have time to debug this issue, but a USB
Analyzer trace clearly
shows that the SET ADDRESS command goes wrong.
I thought harald had fixed the issues your USB Analyzer complained about?
My guess: The only difference between the Windows and
MacOS X trace is
a USB Reset between the GET DESCRIPTOR and SET ADDRESS command on Windows,
the Reset is not there on MacOS X (don't know what Linux does).
yes, the firmware 'stalls' in:
while (!(pUdp->UDP_CSR[0] & AT91C_UDP_TXPKTRDY))
for sending a zero length packet... (which is after/part of the GET
DESCRIPTOR) response. I think it is from an interrupt handler and maybe we
need to check if the transfer has been canceled?
look if "upcd.state" is USB_STATE_DEFAULT,
if not STD_SET_ADDRESS won't do
anything. From my understanding "upcd.state" is set to USB_STATE_DEFAULT
on a USB Reset, so it might not be initialized properly.
will do, but I think we are stuck in the interrupt handler.
4:46 p.m.
Hello Holger,
On Tue, 04 Oct 2011 14:37:09 +0200, "Holger Hans Peter Freyther"
<holger(a)freyther.de> wrote:
I thought harald had fixed the issues your USB Analyzer complained about?
This was a completly different issue, it was not related to the
USB behaviour on MacOS X.
for sending a zero length packet... (which is
after/part of the GET
DESCRIPTOR) response. I think it is from an interrupt handler and maybe we
need to check if the transfer has been canceled?
The GET DESCRIPTOR request is working fine including the response from the
device, the problem is that there is no repsonse on the SET ADDRESS request.
will do, but I think we are stuck in the interrupt
handler.
As a quick check I would just remove the test for the state when handling
SET ADDRESS and see if this helps.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
2:58 p.m.
On 10/04/2011 02:46 PM, Dieter Spaar wrote:
Hi Dieter,
I am not using JTAG to debug so my view i have might be limited. I have put
DEBUG_UNBUFFERD in the codepath. So from the messages I print to the serial.
With my current information I would claim the firmware does not see the SET
ADDRESS (i assume the zpl method needs to check the ISR of the UDP)
frame 0> udp_ep0_send_zlp
frame 1> udp_ep0_send_data
frame 2> udp_ep0_handler
frame 3> udp_irq
Please don't feel urged to look into it, I quite enjoy learning about USB this
way. :)
Hello Holger,
for sending a
zero length packet... (which is after/part of the GET
DESCRIPTOR) response. I think it is from an interrupt handler and maybe we
need to check if the transfer has been canceled?
The GET DESCRIPTOR request is working fine including the response from the
device, the problem is that there is no repsonse on the SET ADDRESS request.
will do, but I think we are stuck in the
interrupt handler.
As a quick check I would just remove the test for the state when handling
SET ADDRESS and see if this helps.
3:23 p.m.
On 10/04/2011 02:58 PM, Holger Hans Peter Freyther wrote:
frame 0> udp_ep0_send_zlp
frame 1> udp_ep0_send_data
frame 2> udp_ep0_handler
frame 3> udp_irq
Okay,
I 'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 that added sending a ZPL
for every thing length % 8 == 0 and the device started to work on OSX. I
assume we will need to look at the USB spec. :)
4:12 p.m.
On 10/04/2011 03:23 PM, Holger Hans Peter Freyther wrote:
On 10/04/2011 02:58 PM, Holger Hans Peter Freyther
wrote:
Okay,
I 'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 that added sending a ZPL
for every thing length % 8 == 0 and the device started to work on OSX. I
assume we will need to look at the USB spec. :)
I have uploaded alternative firmware for OSX[1] and the 'diff' to revert the
above commit. I have to read when to and when not to send a ZPL.
[1] http://bb.osmocom.org/trac/attachment/wiki/SIMtrace/Firmware/
4:29 p.m.
Well done!
I'll try it out in the evening and let you know, I think as it's known where
the problem is now it won't be hard to find out if there's a mistake with
ZPL and how to fix it to have one FW :)
Lukas
On Tue, Oct 4, 2011 at 4:12 PM, Holger Hans Peter Freyther <
holger(a)freyther.de> wrote:
On 10/04/2011 03:23 PM, Holger Hans Peter Freyther
wrote:
On 10/04/2011 02:58 PM, Holger Hans Peter
Freyther wrote:
Okay,
I 'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 that added sending
a
ZPL
for every thing length % 8 == 0 and the device
started to work on OSX. I
assume we will need to look at the USB spec. :)
I have uploaded alternative firmware for OSX[1] and the 'diff' to revert
the
above commit. I have to read when to and when not to send a ZPL.
[1] http://bb.osmocom.org/trac/attachment/wiki/SIMtrace/Firmware/
4:43 p.m.
Where is the firmware hosted btw ? The link on the SIMtrace/Firmware
page is broken ...
Cheers,
Sylvain
4:54 p.m.
On 10/04/2011 04:43 PM, Sylvain Munaut wrote:
Where is the firmware hosted btw ? The link on the
SIMtrace/Firmware
page is broken ...
$ git clone git://git.gnumonks.org/openpcd.git
gitdaemon runs, gitweb on gnumonks does not show it though. I mailed harald
about it (asking for sam7 utils as well).
holger
6 Oct
6 Oct
9:54 a.m.
On Tue, Oct 04, 2011 at 04:54:47PM +0200, Holger Hans Peter Freyther wrote:
On 10/04/2011 04:43 PM, Sylvain Munaut wrote:
the gitweb is up and running again. I have no sam7utils repository,
sorry.
--
- 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)
Where is the firmware hosted btw ? The link on
the SIMtrace/Firmware
page is broken ...
$ git clone git://git.gnumonks.org/openpcd.git
gitdaemon runs, gitweb on gnumonks does not show it though. I mailed harald
about it (asking for sam7 utils as well).
10:04 a.m.
On 10/06/2011 09:54 AM, Harald Welte wrote:
the gitweb is up and running again. I have no sam7utils repository,
sorry.
Hi,
do you think it makes sense to create one? It took me some time to figure out
that it doesn't even connect to the device (or be able to have posix and usb
backend in the same binary). I don't know the story about this utility, but
IIRC I downloaded a tarball from openocd?
holger
8 Oct
8 Oct
10:41 a.m.
Hi Holger,
On Thu, Oct 06, 2011 at 10:04:22AM +0200, Holger Hans Peter Freyther wrote:
do you think it makes sense to create one? It took me
some time to figure out
that it doesn't even connect to the device (or be able to have posix and usb
backend in the same binary). I don't know the story about this utility, but
IIRC I downloaded a tarball from openocd?
I think the most current version of the tool (or an equivalent tool) is
distributed by Atmel itself, somewhere hidden deep in their download
links for the AT91SAM7-EK product. There are even two versions of it,
one that uses the raw USB device (via libusb) and one that uses the
ttyUSB* device generated by the kernel serial driver for the sam-ba
bootloader usb device.
Creating a git repo would probably make sense only if we actually had
some changes/patcehs to that utility.
Regards,
Harald
--
- 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)
10:53 a.m.
On 10/08/2011 10:41 AM, Harald Welte wrote:
Hi Holger,
Creating a git repo would probably make sense only if we actually had
some changes/patcehs to that utility.
I have a printf in case the device fails to open, and I would build both
(posix, libusbb) backends into the same binary. It took me some minutes to
figure out that -l /dev/ttyACM0 was just ignored.
holger
4 Oct
4 Oct
5:26 p.m.
Hello Holger,
On Tue, 04 Oct 2011 14:58:49 +0200, "Holger Hans Peter Freyther"
<holger(a)freyther.de> wrote:
I am not using JTAG to debug so my view i have might be limited. I have put
DEBUG_UNBUFFERD in the codepath. So from the messages I print to the serial.
I don't recommend debugging USB issues with JTAG anyway because it might
chance the behaviour of the device.
With my current information I would claim the firmware
does not see the SET
ADDRESS (i assume the zpl method needs to check the ISR of the UDP)
frame 0> udp_ep0_send_zlp
frame 1> udp_ep0_send_data
frame 2> udp_ep0_handler
frame 3> udp_irq
I can only judge from the trace and using the prebuilt firmware v0.2.2,
in this case the GET DESCRIPTOR request is completed, the SET ADDRESS
request comes in, is ACKed and no response from the device is sent back
when the IN packet from the host arrives.
Have you tried to modify the SET ADDRESS handling already ?
Please don't feel urged to look into it, I quite
enjoy learning about USB this
way. :)
I don't have a working setup here for building the simtrace firmware, so far
I only used prebuilt version. So I can't do much and I currently don't
have the time to go through the process of creating the build-environment.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
6:43 p.m.
Hello Holger,
On Tue, 04 Oct 2011 16:12:42 +0200, "Holger Hans Peter Freyther"
<holger(a)freyther.de> wrote:
I have uploaded alternative firmware for OSX[1] and the 'diff' to revert the
above commit. I have to read when to and when not to send a ZPL.
Have a look at the requested size from the host, only when the host
requests more data than available, the ZLP is needed (if the size sent
is an exact multiple of the endpoint size). In my traces I can see that
Windows request 64 bytes for the first GET DESCRIPTOR which is only 8 bytes
long (so a ZPL should be sent). MacOS X requests 8 bytes, so no ZLP is needed.
I still believe there is another issue which will cause
problems if a USB Reset is missing between the first GET DESCRIPTOR
and the SET ADDRESS request, which I could observe here with my MacOS X
installation (an older one from a year ago).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
4:49 p.m.
On 10/04/2011 04:43 PM, Dieter Spaar wrote:
Have a look at the requested size from the host, only
when the host
requests more data than available, the ZLP is needed (if the size sent
is an exact multiple of the endpoint size).
ahhh. maybe I find something in the USB 2.0 specification about that part now.
Thanks for your input!
7:11 p.m.
Hello Holger,
On Tue, 04 Oct 2011 16:49:37 +0200, "Holger Hans Peter Freyther"
<holger(a)freyther.de> wrote:
ahhh. maybe I find something in the USB 2.0 specification about that part now.
Thanks for your input!
"8.5.3.2 Variable-length Data Stage"
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
7:54 p.m.
Holger Hans Peter Freyther wrote:
USB spec and Windows like to refer to pipes, I think it's a bit
redundant, transfers to and from endpoints is good enough imo. :)
//Peter
I 'reverted'
fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 that added
sending a ZPL for every thing length % 8 == 0 and the device
started to work on OSX. I assume we will need to look at the USB
spec. :)
I think that commit is mostly correct, it just overlooks the
condition of total data length == requested length, in which case I
think no zlp should be sent. Also, hard coding 8 as packet size is
not awesome, the value used by the host for this is bMaxPacketSize0
in the device descriptor. (See 9.6.1) At least a define would be
good, full-speed devices can choose value here.
The same commit also exists earlier in the branch as
8cc090e310545f7858558f74116f707318daf682 with no merges in between.
I'm not sure what happened there.
Holger Hans Peter Freyther wrote:
"8.5.3.2
Variable-length Data Stage"
and 9.4.3 Get Descriptor.
What is a Control Pipe?
8:01 p.m.
Peter Stuge wrote:
Make that total data length >= requested length
//Peter
I
'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9
I think that commit is mostly correct, it just overlooks the
condition of total data length == requested length, in which case I
think no zlp should be sent.
8:17 p.m.
On 10/04/2011 07:54 PM, Peter Stuge wrote:
Holger Hans Peter Freyther wrote:
So 8.5.3.2 demands that if data.length is an exact multiple of wMaxPacketSize
we need to send the ZPL.
And 9.4.3
The wLength field specifies the number of bytes to return. If the descriptor
is longer than the wLength field, only the initial bytes of the descriptor
are returned. If the descriptor is shorter than the wLength field, the device
indicates the end of the control transfer by sending a short packet when
further data is requested. A short packet is defined as a packet shorter than
the maximum payload size or a zero length data packet (refer to Chapter 5).
How to put this together? I will try to tomorrow.
So as Peter points out we should not send a ZPL if we sent wLength byte but it
also happens to be a multiple of wMaxPacketSize?
I 'reverted'
fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 that added
sending a ZPL for every thing length % 8 == 0 and the device
started to work on OSX. I assume we will need to look at the USB
spec. :)
I think that commit is mostly correct, it just overlooks the
condition of total data length == requested length, in which case I
think no zlp should be sent. Also, hard coding 8 as packet size is
not awesome, the value used by the host for this is bMaxPacketSize0
in the device descriptor. (See 9.6.1) At least a define would be
good, full-speed devices can choose value here.
8:33 p.m.
Holger Hans Peter Freyther wrote:
So 8.5.3.2 demands that if data.length is an exact
multiple of
wMaxPacketSize we need to send the ZPL.
It seems that this refers to control pipes other than the one
involving endpoint 0, which is often refered to as the default
control pipe. (It is mandatory by spec and endpoint 0 does not have
an endpoint descriptor, so there is no wMaxPacketSize for endpoint 0.
(See 9.6.6)
For endpoint 0 this is instead stored in bMaxPacketSize0 in the
device descriptor.
Also, is data.length the length of the requested data, or is it the
length that was requested? Note the difference. The requested data is
e.g. the device descriptor. A device descriptor is always 18 bytes.
(See 9.6.1)
And 9.4.3
The wLength field specifies the number of bytes to return. If the
descriptor is longer than the wLength field, only the initial bytes
of the descriptor are returned.
This is the case we hit on Mac OS. Since the requested data is longer
(18) than the requested length (8) we must send no ZLP, only the
first 8 bytes.
Mac OS should follow up with another request for more data.
If the descriptor is shorter than the wLength field,
the device
indicates the end of the control transfer by sending a short packet
when further data is requested.
This case is what we hit on Windows, where 64 bytes are requested.
A short packet is defined as a packet shorter than the
maximum
payload size or a zero length data packet (refer to Chapter 5).
So for Windows we must also not send ZLP, because 18 bytes is already
shorter than 64. Returning 18 bytes is sufficient to say that no more
data is coming.
How to put this together? I will try to tomorrow.
So as Peter points out we should not send a ZPL if we
sent wLength
byte but it also happens to be a multiple of wMaxPacketSize?
Compare length of the descriptor with requested number of bytes. Only
when more bytes are requested than the descriptor is long *and* when
the descriptor is a multiple of the max packet size (bMaxPacketSize0
for ep0, wMaxPacketSize for the ep in the ep descriptor) then send ZLP.
//Peter
7:36 p.m.
Hello Holger,
On Tue, 04 Oct 2011 17:25:01 +0200, "Holger Hans Peter Freyther"
<holger(a)freyther.de> wrote:
and 9.4.3 Get Descriptor.
Its the same rule, all the standard device requests are Control Transfers
as described in 8.5.3.
What is a Control Pipe? The 'reserved
bandwidth/window' for a control
request?
Shall I repeat "Terms and Abbreviations" from the specification ;-) ?
Control Pipe: Same as a message pipe.
Message Pipe: A bi-directional pipe that transfers data using a
request/data/status paradigm. The data has an imposed structure
that allows requests to be reliably identified and communicated
Think about the Control Pipe as the mechanism which transports
the Control Transfers and a such the standard device requests.
You can also put your own requests there (vendor specific requests).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
10:43 p.m.
Hello Holger,
On Tue, 04 Oct 2011 20:17:00 +0200, "Holger Hans Peter Freyther"
<holger(a)freyther.de> wrote:
So 8.5.3.2 demands that if data.length is an exact multiple of wMaxPacketSize
we need to send the ZPL.
But only if less data than requested are sent ("A control pipe may have
a variable-length data phase in which the host requests more data than
is contained").
Its the same rule for GET DESCRIPTOR, no difference.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
4592
days inactive
4601
days old
35 comments
7 participants
participants (7)
-
Dieter Spaar -
Harald Welte -
Holger Hans Peter Freyther -
Lukas Kuzmiak -
Myonium -
Peter Stuge -
Sylvain Munaut