Just one I have a work somewhere...
Can check model tomorrow...
Annoying thing about it is that people will come by and touch the screen not knowing it's touch sensitive and make it do some random thing...
Got a chuckle from that last bit. I know exactly how that feels. When my kids were very young I wanted them to be comfortable with computers so I put some games and a paint program on my computer (Win 3.1) and let them play on it. Quite an educational adventure having to undo all the inadvertent changes they made.
But, have had to unplug and replug USB mouse a couple times to make it go..
Low-speed or full-speed mouse?
In my testing full-speed sometimes may need additional disconnect/connect attempts before it gets a good enumeration. Low-speed should be pretty solid.
I don't think commenting out that delay would make a difference in your situation, as I had it there to give me time to get the PST enabled.
I've got the Amazon Basics mouse, and it's low-speed. Is the mouse connected to the USB shield at startup? Don't really think this would matter, though. Do you have any debug output going to your terminal from the USB host? If something goes awry at connect, the host should output an error message if the initial device descriptor request fails.
Version 0.9a of the USB Low/Full speed keyboard/mouse demo and "minimal footprint" source files, updated to reflect the P2 FPGA v16a changes.
Minor improvements to device enumeration success on connect. Low-Speed devices are very solid, and Full-Speed is also solid when using USB 1.x and 2.0 devices. USB 3.0 devices are not as accommodating, and may take several connect/disconnect attempts before a clean enumeration can be achieved. My meager bus analyzing skills have so far failed to determine why that may be. Since High/Super speeds are beyond the P2's capability, I don't know how much of an issue this would be.
I wonder if those 3.0 devices do some test burst at high frequency after plug-in.
I haven't really had a chance to peruse the USB 3 spec, but that was something that crossed my mind that could be a part of it. High-Speed has a J/K "Chirp" it sends during the reset state to distinguish itself from Full-Speed. If the 3.x device makes it past reset things get better, but where the 2.0 device transactions are solid, the bus signalling of the 3.x device is less stable, resulting in transaction stage failures. The retry mechanism recovers much of the time so the overall transaction succeeds, but it can get really messy.
I've got a low-budget analyzer that only targets low/full speed, and don't have a mixed-signal o'scope, so I'm running somewhat blind when it comes to what, exactly, is happening on the wire
I don't think any mice or keyboards or any other HIDs are USB 3.0 are they?
Yeah, in the keyboard/mouse realm High-Speed is overkill. It just bugs me that the 2.0 devices enumerate cleanly, the 3.0 devices are finicky, and I don't yet see a reason why...
I don't think any mice or keyboards or any other HIDs are USB 3.0 are they?
Yeah, in the keyboard/mouse realm High-Speed is overkill. It just bugs me that the 2.0 devices enumerate cleanly, the 3.0 devices are finicky, and I don't yet see a reason why...
Do you have a list of parts that do not enumerate ?
Does the FPGA USB testing use a differential pin buffer, as I think the final silicon will.
The FPGA pin nodes are also likely to be faster than final process.
I don't think a standard USB transceiver can connect readily to the P2 image, but you could try 22 ohm/22pF LPF to see if that makes any difference, and maybe also try the longest, 'lossiest' cables you can find.
I've got a low-budget analyzer that only targets low/full speed, and don't have a mixed-signal o'scope, so I'm running somewhat blind when it comes to what, exactly, is happening on the wire
What scope do you have ?
Even if it cannot see the HS USB stuff, it may be able to identify when it is present, as I think that is reduced swing (similar to LVDS)
I thought USB 3.0 used different voltage levels... I was surprised it works even a little...
USB 3.0 is backward compatible with 2.x connect-wise. I haven't spent any time in the 3.0 spec to see what caveats, if any, may exist with down-level connection. So far I've just been testing with them because I have some...
@jmg
I've got a mixed bag of 3.0 thumb drives: Lexar, HP, SanDisk and Toshiba. All are finicky, some more than others. My focus has been on getting the 1.x and 2.x devices as reliable as I can, and there's much more to do there, so I haven't been too keen on burning time on what is essentially a side-trip. I'm mostly a software guy, and my skills with logic analyzers is limited (but growing), but with o'scopes (a 100MHz, 2-channel Rigol) I'm barely at the basics.
I thought USB 3.0 used different voltage levels... I was surprised it works even a little...
It does when running at 480M, but it is supposed to have fall-back to 12M.
There is usually some sort of 'have a go' at differing speeds, but I would have expected a slave to follow the host, and not 'try anything fancy' until asked...
Another possible test would be to try 84MHz or 96MHz Sysclk ?
This would remove any jitter from the BUS signals, to check/eliminate if that is having an effect ? - it may be that the USB 3.0 parts have a fussier PLL scheme, tuned for higher speeds and not tested with more ropey 12MHz signals.. ?
I think that needs a PLL tweak in the FPGA, and depends on how much margin exists in the builds.
84MHz is not much of a push ?
Another possible test would be to try 84MHz or 96MHz Sysclk ?
This would remove any jitter from the BUS signals, to check/eliminate if that is having an effect ? - it may be that the USB 3.0 parts have a fussier PLL scheme, tuned for higher speeds and not tested with more ropey 12MHz signals.. ?
I think that needs a PLL tweak in the FPGA, and depends on how much margin exists in the builds.
84MHz is not much of a push ?
I have two Sandisk "Ultra" 16GB 3.0 parts, and they enumerate very reliably. The attached analyzer screenshots show the same device descriptor request for the Sandisk part and a Toshiba 3.0 part. The Sandisk capture from index 40..58 shows a "clean" SETUP descriptor request transaction, and the Toshiba capture from index 45..65 shows a SETUP descriptor request that also succeeded, but it required three data phase IN transaction attempts to do so. In the first two attempts, the Toshiba device did not respond to the DATAx packet that follows the IN token. During an IN transaction, NOT returning an ACK/NAK/STALL handshake means the packet was missing or corrupt. Since the analyzer was able to successfully read and verify the DATAx packet, the read issue must be with the Toshiba part?
I'd certainly like to test if it's possible to tweak the FPGA to 84 or 96MHz? Or should there be no worries if the P2 silicon is clocked at > 96MHz?
... and the Toshiba capture from index 45..65 shows a SETUP descriptor request that also succeeded, but it required three data phase IN transaction attempts to do so. In the first two attempts, the Toshiba device did not respond to the DATAx packet that follows the IN token.
During a SETUP transaction, the device must accept the DATAx packet, and the only reason NOT to return an ACK/NAK/STALL handshake is if the DATAx packet was missing or corrupt. Since the analyzer was able to successfully read and verify the DATAx packet, the read issue must be with the Toshiba part?
Does the Toshiba always need three tries ? (does it ever never ACK, or take dozens of tries ?)
Maybe that is by design, and it used the NAK to 'buy time' to get things in order ?
I understand some companies do use the retry aspect to mask their own issues....
Does the Toshiba always need three tries ? (does it ever never ACK, or take dozens of tries ?)
Maybe that is by design, and it used the NAK to 'buy time' to get things in order ?
I understand some companies do use the retry aspect to mask their own issues....
I haven't seen a repeatable pattern in any particular device, other than it happens most often in 3.0 parts. NAKs are common and do, indeed, signal that the device is listening, but is not yet ready to deal with data. Typically, the NAK retry ceiling is quite high, and for some functions, it can be indefinite. For genuine bus errors or corrupt packets, the spec suggests three retries before giving up on that particular transaction phase. My retry implementation is still pretty simple, so improvements there, or maybe even just upping the retry counts, could get the 3.0 parts "reliable" too -- as long as you don't look at it through the eyes of the analyzer
Was just wondering if garryj's keyboard driver could be used for games.
It's fine for normal use, but for games more than one key can be down at same time.
If I remember right the regular USB keyboard reports show up to 6 keys down at a time.
So, it should be possible...
Was just wondering if garryj's keyboard driver could be used for games.
It's fine for normal use, but for games more than one key can be down at same time.
If I remember right the regular USB keyboard reports show up to 6 keys down at a time.
So, it should be possible...
Yep, 6 key rollover is part of the boot protocol. What needs to be added to the demo is to report a "key up" event for each keypress that's detected, and then it should be close to being game-ready.
Any luck getting your USB code to work with V19 garryj?
I made the v19 instruction changes and it assembles, but doesn't yet work. I've been diverted to other things of late, so I have yet to get the time to figure out where things went wrong. I'm hoping to get some time over the weekend to work on it.
I didn't quite get to where I wanted to be over the weekend with the USB demo. I am getting complete send/receive USB transactions over the wire with P2v19 at 120Mhz, both low-speed and full-speed, but complete device enumeration is still elusive. Unfortunately, a subtle v18->v19 editing blunder had me chasing my tail for quite a while >:(. With that behind me, I'm hoping things will smooth out a bit going forward.
@Rayman, I'll try to focus on getting at least LS mouse working in the "minimal" version ASAP.
P2v20 USB LS/FS mouse and keyboard demos. For those that have run my prior demos, this is the "minimal" version that takes the quickest route to read and configure a USB LS/FS mouse/keyboard, wired or wireless (not BlueTooth) that exposes the "boot protocol" interface, and sends device movement/key output to the serial terminal.
Development board: Prop123-A9
Tested on FPGA images: Prop123_A9_prop2_v20.rbf, Prop123_A9_prop2_v20_64smartpins.rbf
Serial terminal: Parallax Propeller Serial Terminal (Windows), 3Mbaud, TX pin 62.
USB smartpins 32 (D-) and 33 (D+).
NOTES
Mouse & keyboard: The GRN8 LED (host cog) and GRN12 (driver cog) should be lit
upon device connect, and off at disconnect. If either LED remains lit after
disconnect, a code reload is likely required.
When the mouse is connected, but idle, the GRN13 LED should blink. When mouse
movement data is sent to the serial terminal, GRN13 should be on while the data
is streaming, and back to blinking when idle. The keyboard code does not yet
have this feature implemented.
I have been diverted to other things for a while, but finally had some quality time to try to get my USB demo code running on the newest v20 FPGA image. The initial time-constrained attempts to update it to the P2v19 image didn't go very well. After the code edits to implement the v19 instruction changes, the USB i/o looked good, but the code would quickly hang, rarely able to complete an entire bus transaction. Updating to v20 didn't change things much. This was code that has been pretty stable since around the FPGA image v13 days. I have tried both of the v20 images, with the same results.
The code now is, I hope, functional enough to see if it works on other dev boards than mine. IMO there was something in the v18->v19 update that has changed the equation, and the only suspicion I have at this time is that it may involve the JCTn/JNCTn/POLLCTn events and/or their behavior when mixed with an interrupt that is triggered on a "CTn = CT" event. I have verified that LUT read/write sharing, and LUT register write events via the POLLSEn instructions appear to work as expected. Also, while trying to figure out why things weren't working, I replaced the LUT sharing POLLSEn event on LUT writes to COGATN and it also worked as expected.
The tests consist of four program files: USBMouse.spin2, USBKeyboard.spin, USBMouseFSFail.spin2 and FailFSMouseKbd.spin2. Hopefully, testing and examination by others can lead to shedding some light on what may be happening, 'cause right now I don't have anything close to a definitive reason as to the why :depressed:
If you diff the USBMouse.spin2 program with any of the others, you'll notice that there are a very few lines of code that have been changed, yet one file will work, and the other doesn't (at least on my FPGA board).
USBMouse.spin2: This file should work with both low-speed and full-speed mice that expose the "boot protocol" interface. The detection/configuration of a boot protocol keyboard has been suppressed to focus on just the mouse functionality.
USBKeyboard.spin2: Same as above, but with mouse detection/configuration suppressed.
USBMouseKbdFail.spin2: This file has both mouse and keyboard detection enabled, and this was working on pre-v19 code. Two CTn timers are used to trigger the mouse and keyboard polling intervals (via the dpoll_data subroutine). Each device poll interval is 8ms and they trigger 4ms apart. With only one device configured, it works. But add the second device with its timer, and it doesn't. The USB analyzer shows both devices are getting configured correctly, but when the polling timers are set and running, it looks like their CTn = CT flags never get set, which results in the driver cog getting stuck in its main->dpoll_data->main loop. With full-speed devices, the analyzer shows the host cog happily churning out the 1ms frame interval packets, but there's nothing for it to do, so I don't think it's involved. I don't have any low-speed keyboard/mouse combos that support the boot protocol to test, but I'm pretty sure they wouldn't work either if the problem was in the driver cog.
USBMouseFSFail.spin2: This file is identical to USBMouse.spin2, with the exception of the poll_waitx subroutine. The behavior I'm seeing is that the low-speed mouse works, but a full-speed mouse has a major fail upon the first USB SETUP packet put on the bus. My USB analyzer shows that the full-speed 1ms frame interval packets transmitted using the host cog "CTn = CT"-triggered ISR is functioning as expected, but when the first SETUP packet is transmitted, the non-ISR code will call poll_waitx to time an inter-packet delay, and that is where it looks like things go south. The frame packets are still getting transmitted correctly, but it appears that the non-ISR poll_waitx code is in a spin-lock waiting for its POLLCT3 event flag to be set to signal the end of the inter-packet delay, but after waiting at least the ~36 seconds for the 120Mhz clock timer rollover, no joy. AFIK there should be no functional difference between the POLLCTn vs. JNCTn loop constructs? At low-speed there is a 1ms frame timer too, but it consists of a single EOP strobe (three LS bit times = ~2us), which makes the frame duration a little shorter than the FS frame packet, which takes ~3us. Could this be a factor?
Finally, an odd, but potentially important quirk, that I can reproduce with the USBMouse.spin2 file, is that if the mouse consistently works over several connect, exercise and disconnect cycles, search the file for the parse_dev_desc label, comment out the NOP, and run the program again. On my system just commenting the NOP out causes the code to never get to the device polling stage, i.e. the 8ms polling interval timer appears to never trigger. Conversely, should your mouse not work, try commenting out the NOP to see if it starts working. The device polling routine is cog exec, and this code is hub exec. It's in the hub exec code that the mouse polling interval timer gets initialized, just before it returns to the "main" loop that is cog exec. Could cog <-> hub transition be a possible factor?
orgh
' /* parse_dev_desc
'------------------------------------------------------------------------------
' Parse the Device Descriptor. For now just parse out the string indexes. Root
' out additional info as needed.
'------------------------------------------------------------------------------
' On entry: Reg devent: eventID.
' Reg dpar1: device address and control pipe endpoint (0).
' Reg dpar2: start address of the cached device descriptor struct.
' On exit:
'------------------------------------------------------------------------------
parse_dev_desc
nop
mov ctrl_ep_addr, dpar1 ' Save the ctrlep/addr of the device
mov device_base, dpar2 ' Save start address of device descriptor
loc ptra, #@sz_getdev_result ' Since the intent is to parse the device
mov dpar2, dpar3 ' descriptor, the result *should* always be ACK
jmp #dtx_result_to_con
I hope at least some folks will be able to give this a go, to see if they get similar results. At this point, I'm pretty much stuck until a resolution is found.
There were so many instruction changes, I'm sure it's a nightmare to update a big code like yours...
One problem I had (or maybe still have) is that if the name changes on an assembly command and you didn't change it, it might not be treated as an error, just a label...
.... The USB analyzer shows both devices are getting configured correctly, but when the polling timers are set and running, it looks like their CTn = CT flags never get set, which results in the driver cog getting stuck in its main->dpoll_data->main loop.
... My USB analyzer shows that the full-speed 1ms frame interval packets transmitted using the host cog "CTn = CT"-triggered ISR is functioning as expected, but when the first SETUP packet is transmitted, the non-ISR code will call poll_waitx to time an inter-packet delay, and that is where it looks like things go south.
... but after waiting at least the ~36 seconds for the 120Mhz clock timer rollover, no joy.
Finally, an odd, but potentially important quirk, that I can reproduce with the USBMouse.spin2 file, is that if the mouse consistently works over several connect, exercise and disconnect cycles, search the file for the parse_dev_desc label, comment out the NOP, and run the program again. On my system just commenting the NOP out causes the code to never get to the device polling stage, i.e. the 8ms polling interval timer appears to never trigger.
Hmm, be interesting to see how this runs across different FPGAs, as it's starting to sound like maybe that 120MHz is too optimistic in overclocking ?
Can you do some small test cases of the suspect opcodes ?
Comments
Got a chuckle from that last bit. I know exactly how that feels. When my kids were very young I wanted them to be comfortable with computers so I put some games and a paint program on my computer (Win 3.1) and let them play on it. Quite an educational adventure having to undo all the inadvertent changes they made.
But, I think I'm better off with mouse or keyboard anyway...
But, have had to unplug and replug USB mouse a couple times to make it go..
In my testing full-speed sometimes may need additional disconnect/connect attempts before it gets a good enumeration. Low-speed should be pretty solid.
Any chance that matters?
I've got the Amazon Basics mouse, and it's low-speed. Is the mouse connected to the USB shield at startup? Don't really think this would matter, though. Do you have any debug output going to your terminal from the USB host? If something goes awry at connect, the host should output an error message if the initial device descriptor request fails.
Its maybe one in 12 or so reprograms that it doesn't work until unplugged and replugged
But maybe my messing with the code messed it up somehow
Minor improvements to device enumeration success on connect. Low-Speed devices are very solid, and Full-Speed is also solid when using USB 1.x and 2.0 devices. USB 3.0 devices are not as accommodating, and may take several connect/disconnect attempts before a clean enumeration can be achieved. My meager bus analyzing skills have so far failed to determine why that may be. Since High/Super speeds are beyond the P2's capability, I don't know how much of an issue this would be.
I've got a low-budget analyzer that only targets low/full speed, and don't have a mixed-signal o'scope, so I'm running somewhat blind when it comes to what, exactly, is happening on the wire
I don't think any mice or keyboards or any other HIDs are USB 3.0 are they?
If not, might not matter...
Do you have a list of parts that do not enumerate ?
Does the FPGA USB testing use a differential pin buffer, as I think the final silicon will.
The FPGA pin nodes are also likely to be faster than final process.
I don't think a standard USB transceiver can connect readily to the P2 image, but you could try 22 ohm/22pF LPF to see if that makes any difference, and maybe also try the longest, 'lossiest' cables you can find.
What scope do you have ?
Even if it cannot see the HS USB stuff, it may be able to identify when it is present, as I think that is reduced swing (similar to LVDS)
@jmg
I've got a mixed bag of 3.0 thumb drives: Lexar, HP, SanDisk and Toshiba. All are finicky, some more than others. My focus has been on getting the 1.x and 2.x devices as reliable as I can, and there's much more to do there, so I haven't been too keen on burning time on what is essentially a side-trip. I'm mostly a software guy, and my skills with logic analyzers is limited (but growing), but with o'scopes (a 100MHz, 2-channel Rigol) I'm barely at the basics.
There is usually some sort of 'have a go' at differing speeds, but I would have expected a slave to follow the host, and not 'try anything fancy' until asked...
Here is a better explanation : See Negotiating High Speed
http://www.usbmadesimple.co.uk/ums_6.htm#negotiating_high_speed
Looks like it does rely on correct BUS termination, in order to have the 800mV not be seen ?
Another possible test would be to try 84MHz or 96MHz Sysclk ?
This would remove any jitter from the BUS signals, to check/eliminate if that is having an effect ? - it may be that the USB 3.0 parts have a fussier PLL scheme, tuned for higher speeds and not tested with more ropey 12MHz signals.. ?
I think that needs a PLL tweak in the FPGA, and depends on how much margin exists in the builds.
84MHz is not much of a push ?
I'd certainly like to test if it's possible to tweak the FPGA to 84 or 96MHz? Or should there be no worries if the P2 silicon is clocked at > 96MHz?
Does the Toshiba always need three tries ? (does it ever never ACK, or take dozens of tries ?)
Maybe that is by design, and it used the NAK to 'buy time' to get things in order ?
I understand some companies do use the retry aspect to mask their own issues....
I think Chip builds to 80MHz timing, which means 84MHz is probably there in margins and room temperature allowances, & 96MHz might be more of a push.
It's fine for normal use, but for games more than one key can be down at same time.
If I remember right the regular USB keyboard reports show up to 6 keys down at a time.
So, it should be possible...
@Rayman, I'll try to focus on getting at least LS mouse working in the "minimal" version ASAP.
There's no rush though
Development board: Prop123-A9
Tested on FPGA images: Prop123_A9_prop2_v20.rbf, Prop123_A9_prop2_v20_64smartpins.rbf
Serial terminal: Parallax Propeller Serial Terminal (Windows), 3Mbaud, TX pin 62.
USB smartpins 32 (D-) and 33 (D+).
NOTES
Mouse & keyboard: The GRN8 LED (host cog) and GRN12 (driver cog) should be lit
upon device connect, and off at disconnect. If either LED remains lit after
disconnect, a code reload is likely required.
When the mouse is connected, but idle, the GRN13 LED should blink. When mouse
movement data is sent to the serial terminal, GRN13 should be on while the data
is streaming, and back to blinking when idle. The keyboard code does not yet
have this feature implemented.
I have been diverted to other things for a while, but finally had some quality time to try to get my USB demo code running on the newest v20 FPGA image. The initial time-constrained attempts to update it to the P2v19 image didn't go very well. After the code edits to implement the v19 instruction changes, the USB i/o looked good, but the code would quickly hang, rarely able to complete an entire bus transaction. Updating to v20 didn't change things much. This was code that has been pretty stable since around the FPGA image v13 days. I have tried both of the v20 images, with the same results.
The code now is, I hope, functional enough to see if it works on other dev boards than mine. IMO there was something in the v18->v19 update that has changed the equation, and the only suspicion I have at this time is that it may involve the JCTn/JNCTn/POLLCTn events and/or their behavior when mixed with an interrupt that is triggered on a "CTn = CT" event. I have verified that LUT read/write sharing, and LUT register write events via the POLLSEn instructions appear to work as expected. Also, while trying to figure out why things weren't working, I replaced the LUT sharing POLLSEn event on LUT writes to COGATN and it also worked as expected.
The tests consist of four program files: USBMouse.spin2, USBKeyboard.spin, USBMouseFSFail.spin2 and FailFSMouseKbd.spin2. Hopefully, testing and examination by others can lead to shedding some light on what may be happening, 'cause right now I don't have anything close to a definitive reason as to the why :depressed:
If you diff the USBMouse.spin2 program with any of the others, you'll notice that there are a very few lines of code that have been changed, yet one file will work, and the other doesn't (at least on my FPGA board).
USBMouse.spin2: This file should work with both low-speed and full-speed mice that expose the "boot protocol" interface. The detection/configuration of a boot protocol keyboard has been suppressed to focus on just the mouse functionality.
USBKeyboard.spin2: Same as above, but with mouse detection/configuration suppressed.
USBMouseKbdFail.spin2: This file has both mouse and keyboard detection enabled, and this was working on pre-v19 code. Two CTn timers are used to trigger the mouse and keyboard polling intervals (via the dpoll_data subroutine). Each device poll interval is 8ms and they trigger 4ms apart. With only one device configured, it works. But add the second device with its timer, and it doesn't. The USB analyzer shows both devices are getting configured correctly, but when the polling timers are set and running, it looks like their CTn = CT flags never get set, which results in the driver cog getting stuck in its main->dpoll_data->main loop. With full-speed devices, the analyzer shows the host cog happily churning out the 1ms frame interval packets, but there's nothing for it to do, so I don't think it's involved. I don't have any low-speed keyboard/mouse combos that support the boot protocol to test, but I'm pretty sure they wouldn't work either if the problem was in the driver cog.
USBMouseFSFail.spin2: This file is identical to USBMouse.spin2, with the exception of the poll_waitx subroutine. The behavior I'm seeing is that the low-speed mouse works, but a full-speed mouse has a major fail upon the first USB SETUP packet put on the bus. My USB analyzer shows that the full-speed 1ms frame interval packets transmitted using the host cog "CTn = CT"-triggered ISR is functioning as expected, but when the first SETUP packet is transmitted, the non-ISR code will call poll_waitx to time an inter-packet delay, and that is where it looks like things go south. The frame packets are still getting transmitted correctly, but it appears that the non-ISR poll_waitx code is in a spin-lock waiting for its POLLCT3 event flag to be set to signal the end of the inter-packet delay, but after waiting at least the ~36 seconds for the 120Mhz clock timer rollover, no joy. AFIK there should be no functional difference between the POLLCTn vs. JNCTn loop constructs? At low-speed there is a 1ms frame timer too, but it consists of a single EOP strobe (three LS bit times = ~2us), which makes the frame duration a little shorter than the FS frame packet, which takes ~3us. Could this be a factor?
USBMouse.spin
poll_waitx getct hct3 addct3 hct3, hctwait .wait ' pollct3 wc ' if_nc jmp #.wait jnct3 #.wait retUSBMouseFSFail.spin2:
poll_waitx getct hct3 addct3 hct3, hctwait .wait pollct3 wc if_nc jmp #.wait ' jnct3 #.wait retFinally, an odd, but potentially important quirk, that I can reproduce with the USBMouse.spin2 file, is that if the mouse consistently works over several connect, exercise and disconnect cycles, search the file for the parse_dev_desc label, comment out the NOP, and run the program again. On my system just commenting the NOP out causes the code to never get to the device polling stage, i.e. the 8ms polling interval timer appears to never trigger. Conversely, should your mouse not work, try commenting out the NOP to see if it starts working. The device polling routine is cog exec, and this code is hub exec. It's in the hub exec code that the mouse polling interval timer gets initialized, just before it returns to the "main" loop that is cog exec. Could cog <-> hub transition be a possible factor?
orgh ' /* parse_dev_desc '------------------------------------------------------------------------------ ' Parse the Device Descriptor. For now just parse out the string indexes. Root ' out additional info as needed. '------------------------------------------------------------------------------ ' On entry: Reg devent: eventID. ' Reg dpar1: device address and control pipe endpoint (0). ' Reg dpar2: start address of the cached device descriptor struct. ' On exit: '------------------------------------------------------------------------------ parse_dev_desc nop mov ctrl_ep_addr, dpar1 ' Save the ctrlep/addr of the device mov device_base, dpar2 ' Save start address of device descriptor loc ptra, #@sz_getdev_result ' Since the intent is to parse the device mov dpar2, dpar3 ' descriptor, the result *should* always be ACK jmp #dtx_result_to_conI hope at least some folks will be able to give this a go, to see if they get similar results. At this point, I'm pretty much stuck until a resolution is found.
Thanks!
One problem I had (or maybe still have) is that if the name changes on an assembly command and you didn't change it, it might not be treated as an error, just a label...
Anyway, I'll try it soon. Thanks!
Can you do some small test cases of the suspect opcodes ?