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/.
Holger Hans Peter Freyther holger at freyther.deOn 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.