The v0.6 host would give up if a STALL handshake is received on a control read/write. In my collection of full-speed devices, most enumerate reliably, but a few are finicky. It's kind of like Forest Gump and his box of chocolates :frown:

Does it always stall at the mouse SetIdle()? Sometimes repeated disconnect/reconnect will result in success.

The next drop of the demo isn't far away, and I just ordered this model combo to add to my test group - we'll get it to work

It will also contain a "minimal" host/driver version that has all of the demo's verbose descriptor output code and data removed, making it more suitable for a "production" environment.

<Full-Speed device connected.>
Bummer! I don't know what to do with this device.

Yep, Bluetooth is a whole different animal. From what I've read, finding a Bluetooth keyboard/mouse that supports the HID "boot protocol" interface is a rare animal.

Edit: BTW, the next demo drop can identify all of the USB-IF registered device/interface base class types, from the class/subclass/protocol "triad" that's in the device and interface descriptors. Subclass and protocol identification can get pretty gnarly, so getting detailed info for these is optional, but it's pretty easy to add, if desired. The demo does the full triad for HID, Mass Storage and the Bluetooth subset of the "Wireless Controller" base class.

And the occasional need to reload the FPGA image after a USB error issue is looking like it's resolved (LUT initialization programmer error).

This LUT bug just bit me again...
It's so rare that I think it must be what I just did in code that messed it up...
Takes a while before I realize that it must be this bug and load an old version of code to verify.

There is definitely something wrong with P2V for this to happen.
I'm assuming that PNUT is resetting the P2V.
This should clear all memory, including LUT memory, AFAIK

LUT initialization from COGINIT would have to be optional I think.
COGINIT already allows you to restart a cog without reloading cog ram now.

If LUT is used as a table for video palette or DAC table it has to be loaded post COGINIT anyway.
The same for LUT execution code, it is loaded in a second step from user code.
The remaining use case is for variables/stacks.
In this case a simple REP loop can initialize the RAM or the example above with a template.

One means to manage this could be a choice of Boot-detail, where you can (optionally) 'fill-the-rest' as part of the Loader step.
You can do that 'long-hand' by always giving an image sized to all RAM, but the SW-Fill would be faster.
If ROM manages this as a Build-type switch, that frees up some valuable user code space.

I've been really stumped a few times by what turned out to be just software out-of-order r/w issues in shared hub memory. The solutions were always simple. It was just a matter of realizing where the trip-up was happening. The same issues are potential in shared LUTs.

If you are launching two cogs concurrently with LUT-sharing in mind, it might be good to have each one start by clearing its own LUT and then turning on LUT sharing. Remember that LUT sharing does not makes two LUTs equal, only that they each can receive a copy of their neighbor's individual WRLUT operations.

Garryj, I think I asked before, but do you have a Prop123-A9 board? I can do an updated A9 compile today and post it. It uses bit 3 of the readback status in the USB mode to tell whether SE0/K/J have been valid for 7+ USB bit periods, while bits 2/1/0 express immediate SE0/K/J states, without any delays.

The new compile would also cover the bug where CALLPA/CALLPB and the event jumps couldn't branch backwards using 9-bit relative addresses.

I just took a quick peek at documentation, but don't see any notes that LUT is not initialized by coginit. I think this needs to be made very clear. Maybe in both LUT description section and coginit section.

Also, I didn't see the option of not clearing cog RAM in there either...

Garryj, I think I asked before, but do you have a Prop123-A9 board? I can do an updated A9 compile today and post it. It uses bit 3 of the readback status in the USB mode to tell whether SE0/K/J have been valid for 7+ USB bit periods, while bits 2/1/0 express immediate SE0/K/J states, without any delays.

The new compile would also cover the bug where CALLPA/CALLPB and the event jumps couldn't branch backwards using 9-bit relative addresses.

To me, it sounds like it still loads the cog and just starts from somewhere else besides address #0.

Yes, I agree.
IIRC I started playing with this mode based on a passing comment by Chip of a new feature.
It also needs to mention that stopping the cog clears the DIRx registers too.
This can be a issue if restarting at an address that may skip port initialization.