I'm having trouble with a long USB 2.0 configuration descriptor -- 75 bytes.

Initially, I was seeing my Linux host complaining in dmesg about being unable to read the descriptor, after I'd added another interface with two alternate settings. Here's how the problematic descriptor looks:

with descriptors.DeviceDescriptor() as d:
    d.idVendor  = 0x16d0
    d.idProduct = 0x0f3b
    d.iManufacturer = "ShareBrained"
    d.iProduct      = "Tedium X8"
    d.iSerialNumber = "deadbeef"
    d.bNumConfigurations = 1

with descriptors.ConfigurationDescriptor() as c:

    with c.InterfaceDescriptor() as i:
        i.bInterfaceNumber = 0

        with i.EndpointDescriptor() as e:
            e.bEndpointAddress = USBDirection.IN.to_endpoint_address(1)
            e.wMaxPacketSize   = 64
            e.bmAttributes     = USBTransferType.INTERRUPT
            e.bInterval        = 4

    with c.InterfaceDescriptor() as i:
        i.bInterfaceNumber = 1
        i.bAlternateSetting = 0

    with c.InterfaceDescriptor() as i:
        i.bInterfaceNumber = 1
        i.bAlternateSetting = 1

        with i.EndpointDescriptor() as e:
            e.bEndpointAddress = USBDirection.IN.to_endpoint_address(2)
            e.wMaxPacketSize   = (1 << 11) | 24
            e.bmAttributes     = USBTransferType.ISOCHRONOUS
            e.bInterval        = 1

    with c.InterfaceDescriptor() as i:
        i.bInterfaceNumber = 2
        i.bAlternateSetting = 0

    with c.InterfaceDescriptor() as i:
        i.bInterfaceNumber = 2
        i.bAlternateSetting = 1

        with i.EndpointDescriptor() as e:
            e.bEndpointAddress = USBDirection.OUT.to_endpoint_address(3)
            e.wMaxPacketSize   = (1 << 11) | 24
            e.bmAttributes     = USBTransferType.ISOCHRONOUS
            e.bInterval        = 1

I built a test case based on FullDeviceTest that demonstrates the problem in simulation:

# Read our configuration descriptor (with subordinates).
try_config_length = 33
handshake, data = yield from self.get_descriptor(DescriptorTypes.CONFIGURATION, length=try_config_length)
self.assertEqual(handshake, USBPacketID.ACK)
self.assertEqual(bytes(data), self.descriptors.get_descriptor_bytes(DescriptorTypes.CONFIGURATION)[:try_config_length])

If I set try_config_length to 32 or less, the test case passes. If 33 or larger, it fails. Examining the simulation output in GTKWave, I tracked the apparent culprit to this line in ConstantStreamGenerator, which appears to be sized wrong (5 bits wide) for the intent of max_length_width, which I take to express the number of bits used to represent max_length. Indeed, if I change that line from:

bytes_sent     = Signal.like(self._max_length_width)

...to:

bytes_sent     = Signal(self._max_length_width)

...the test case passes. That is, until I reach try_config_length of 64, which fails for a different reason which I imagine is a separate issue.

...
  File "./enumerate_test.py", line 155, in test_enumeration
    handshake, data = yield from self.get_descriptor(DescriptorTypes.CONFIGURATION, length=try_config_length)
  File "/home/jboone/src/fpga/luna/luna/gateware/test/usb2.py", line 512, in get_descriptor
    descriptor = yield from self.control_request_in(0x80,
  File "/home/jboone/src/fpga/luna/luna/gateware/test/usb2.py", line 434, in control_request_in
    pid, packet = yield from self.in_transfer(data_pid=USBPacketID.DATA1)
  File "/home/jboone/src/fpga/luna/luna/gateware/test/usb2.py", line 350, in in_transfer
    pid, packet = yield from self.in_transaction(
  File "/home/jboone/src/fpga/luna/luna/gateware/test/usb2.py", line 323, in in_transaction
    self.assertEqual(pid, data_pid.byte())
AssertionError: 75 != <USBPacketID.128|64|DATA0|ACK|OUT: 195>

If I were to guess, this is a wMaxPacketSize0 issue, but that's just intuition speaking, not real data.

I'm holding off submitting a pull request, because I'm skeptical my ConstantStreamGenerator change is the extent of what's necessary. I just don't grasp the code well enough yet to know that the change I made was the appropriate one, as the meaning of max_length and max_length_width seem a bit muddled in my brain...

Could LUNA be extended with other protocol analysis (SPI, I2C,MIPI etc..) using the 16 user defined I/O ports as generic I/O ports and bring those pins to the outside of the enclusure on a header ? This would make LUNA a very lucrative alternative to other $1000+ USB2.0 and multiprotocol analyzers. Not being familair with LUNA yet, suppose this would be grabbing a bunch of samples into the buffer and send them to the host software that for example Sigrok/PulseView or other open source software could analyze ?

Yesterday, a photo of the case that was posted in the Discord channel. I was told to post my feedback regarding the silkscreen design here, so I'm doing that now.

I'll preface these statements by saying that I'm not a designer and don't have any experience in that area--these are just the issues that I, as a (future) user, had with the design. So, please don't grant these statements any undue authority. Also, these are just my opinions, so please feel free to ignore them if you think they're wrong.

Issues

Text orientation

My first issue is that the text is oriented in three directions, and somewhat inconsistently so. For instance, the "Host" and "Sideband" labels are rotated 90 degrees clockwise, and the "Target" label is rotated 90 degrees in the opposite direction. That all makes sense, since it means you can easily read the labels while looking at the ports you're plugging cables into. But then the labels for the "DFU" and "Reset" buttons have no rotation, despite the buttons being on the same sides of the case as those ports whose labels are rotated 90 degrees. I can understand the thought process behind that--the expectation is that the device would primarily be oriented with the ports on the left and right sides, and the user can easily read the "DFU" and "Reset" labels in that orientation and then just feel for the buttons. But to have text that's so close together oriented perpendicularly, as in the case of the "Sideband" and "DFU" labels, is somewhat confusing, and doesn't look very good. But then rotating "DFU" to be in line with "Host and "Sideband" would put it in conflict with the "Debug" LED labels, so something would need to be done about those, too.

Indicators for each port's size

Without port width indicators like the "Target" label has (the lines the the left and right of the text), it's non-obvious where each port starts and ends. e.g., it'd be nice to see something like ┌──Host──┐┌Sideband┐ (or ┌──Host──┬Sideband┐ or whatever) to make that more clear.

LED labeling

Similarly, the "Debug" and "FPGA" labels could use some separation from and better indication of what LEDs they cover. For instance, maybe the LED spots could have a line covering all them, and then put the "Debug"/"FPGA" labels above that line. Maybe something like this (but with the text actually underlined as well):

__Debug__   ___FPGA____
● ● ● ● ●   ● ● ● ● ● ●
A B C D E   5 4 3 2 1 0

Or, if labels start to get cluttered, the LED labels could be put in a "call out" (I don't know if that's the right term), where a line goes over the top of the LED spaces and links to a different area where the actual labels are. Kind of like what you might see on some PCBs with densely-packed clusters of components.

Clutter

The design is simultaneously "too cluttered" and "has too much negative space". What I mean by that is, first, it seems the logos for the Luna itself and GSG were placed to fill as much of the space as they could, while leaving a large empty space in the middle. That's not to say I'd like to see that space filled--rather, I think it would be better to decrease the sizes of both logos, and also possibly even condense them into one (GSG logo plus "LUNA" text, and nothing else) or put them on the back of the case. Speaking of which...

The CE mark should not be on the front of the case. I realize that it was probably placed there since it may cost less to only mark the top side of the case, but whether or not something is CE-certified is generally not something I need to stare at every day. Instead, what I as a user find useful to see are the following (in no particular order):

• The port labels (so I know what to plug where, without having to consult the manual).
• The LED labels (again, so I don't have to consult the manual to know what they mean).

So if it's at all possible, I would suggest putting the full Luna logo and the CE mark on the back of the case, and then, since the GSG name is already a part of the Luna logo, skip the GSG gears entirely. Or, the GSG logo could be kept on the front side, but centered.

Design mockup

A picture's worth a thousand words, so here's a sloppy mockup I did of a "fixed" design:

The two big circles are where the GSG logo would go. The design is not to scale (again, it's a sloppy mockup), and so maybe some of these design decisions might not work exactly, but I think this does a decent job illustrating my suggestions. I'm still not really happy with the labeling for the FPGA LEDs, since having all the digits in a horizontal line makes me want to read them like a single number, but I can't really think of a much better way to do that that wouldn't end up making some other aspect of the design worse.

Anyways, I'm eager to hear what people think about my comments/mockup.

This may well be a user error, but this is what I attempted:

With LUNA_PLATFORM=luna.gateware.platform.fomu:FomuPVT

In luna/examples/soc/hello/

$ python3 -m hello_world_soc
module: luna.gateware.platform.fomu  name: FomuPVT
INFO    | __init__    | Building and uploading gateware to attached Fomu PVT/Production...
INFO    | simplesoc   | Physical address allocations:
INFO    | simplesoc   |     00000000-00001000: <luna.gateware.soc.memory.WishboneROM object at 0x7f026399c5b0>
INFO    | simplesoc   |     00001000-00002000: <luna.gateware.soc.memory.WishboneRAM object at 0x7f026399c910>
INFO    | simplesoc   |     00002000-00002004: (rec uart_divisor r_data r_stb w_data w_stb)
INFO    | simplesoc   |     00002004-00002008: (rec uart_rx_data r_data r_stb)
INFO    | simplesoc   |     00002008-0000200c: (rec uart_rx_rdy r_data r_stb)
INFO    | simplesoc   |     0000200c-00002010: (rec uart_rx_err r_data r_stb)
INFO    | simplesoc   |     00002010-00002014: (rec uart_tx_data w_data w_stb)
INFO    | simplesoc   |     00002014-00002018: (rec uart_tx_rdy r_data r_stb)
INFO    | simplesoc   |     00002020-00002024: (rec uart_ev_status r_data r_stb)
INFO    | simplesoc   |     00002024-00002028: (rec uart_ev_pending r_data r_stb w_data w_stb)
INFO    | simplesoc   |     00002028-0000202c: (rec uart_ev_enable r_data r_stb w_data w_stb)
INFO    | simplesoc   |     00002040-00002044: (rec timer_reload r_data r_stb w_data w_stb)
INFO    | simplesoc   |     00002044-00002048: (rec timer_en r_data r_stb w_data w_stb)
INFO    | simplesoc   |     00002048-0000204c: (rec timer_ctr r_data r_stb w_data w_stb)
INFO    | simplesoc   |     00002050-00002054: (rec timer_ev_status r_data r_stb)
INFO    | simplesoc   |     00002054-00002058: (rec timer_ev_pending r_data r_stb w_data w_stb)
INFO    | simplesoc   |     00002058-0000205c: (rec timer_ev_enable r_data r_stb w_data w_stb)
INFO    | simplesoc   |     00002060-00002064: (rec leds_output r_data r_stb w_data w_stb)
INFO    | simplesoc   | 
INFO    | simplesoc   | IRQ allocations:
INFO    | simplesoc   |     0: uart
INFO    | simplesoc   |     1: timer
INFO    | simplesoc   | 
INFO    | simplesoc   | 
Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/home/tim/greatscottgadgets/luna/examples/soc/hello/hello_world_soc.py", line 103, in <module>
    top_level_cli(design, cli_soc=design.soc)
  File "/home/tim/greatscottgadgets/luna/luna/__init__.py", line 140, in top_level_cli
    products = platform.build(fragment,
  File "/home/tim/icebreaker/icebreaker-nmigen-examples/env/src/nmigen/nmigen/build/plat.py", line 95, in build
    plan = self.prepare(elaboratable, name, **kwargs)
  File "/home/tim/icebreaker/icebreaker-nmigen-examples/env/src/nmigen/nmigen/build/plat.py", line 135, in prepare
    fragment = Fragment.get(elaboratable, self)
  File "/home/tim/icebreaker/icebreaker-nmigen-examples/env/src/nmigen/nmigen/hdl/ir.py", line 39, in get
    obj = obj.elaborate(platform)
  File "/home/tim/greatscottgadgets/luna/examples/soc/hello/hello_world_soc.py", line 92, in elaborate
    uart_io = platform.request("uart", 0)
  File "/home/tim/icebreaker/icebreaker-nmigen-examples/env/src/nmigen/nmigen/build/res.py", line 62, in request
    resource = self.lookup(name, number)
  File "/home/tim/icebreaker/icebreaker-nmigen-examples/env/src/nmigen/nmigen/build/res.py", line 57, in lookup
    raise ResourceError("Resource {}#{} does not exist"
nmigen.build.res.ResourceError: Resource uart#0 does not exist

USB2.0 8.5.1 states:

High-speed devices must support an improved NAK mechanism for Bulk OUT and Control endpoints and transactions. Control endpoints must support this protocol for an OUT transaction in the data and status stages. The control Setup stage must not support the PING protocol.

We observe that hosts running Linux 5.18 sometimes issues PING tokens during control requests, and not handling them means those requests are unable to complete, resulting in the device failing to enumerate correctly.

This patch solves the issue by always returning ACK to PING tokens received during data OUT and status OUT stages. In most cases ACK is the correct response since we're ready to handle data, and in the few cases it's not, we'll just fall back to letting the request handler return a NAK to the following data packet.

GetDescriptorHandlerSingleMemory handles GET_DESCRIPTOR calls and stores all descriptors in a single memory. It uses the same interface as GetDescriptorHandler and is a drop-in replacement.

The MIDI example works if I restrict it to one output only, otherwise the descriptor would get too large (see https://github.com/greatscottgadgets/luna/issues/86)

Just a thought, but by adding git repositories to setup.py, downstream projects can simply specify luna as a dependency, and pip install will take care of the rest.

Here is an example of a use case I have in mind. https://github.com/BracketMaster/nmigen-tinyfpgabx/blob/master/requirements.txt#L1

Some potential changes for r0.3:

• [x] Re-spec 3V3 regulator to reduce ripple; or at the least, remove its bypass capacitor.
• [x] Improve grounding / thermal connections for the USB PHYs.
• [x] Potentially switch between the active-high and active-low versions of our load switches / switch the load configuration to reduce leakage.
• [x] Replace the USB PHY pull-up resistors with pull-down ones.
• [x] Replace the 60MHz oscillator with the cheaper / lower-jitter SIT1602BC-73-33E-60.000000E.
• [x] Re-evaluate availability and see if switching the 1V1 regulator to its larger package (EF vs EE) makes sense.
• [x] Clean up redundant input caps (C6, C40, C47) on 3V3 regulator (U3).
• [x] Remove redundant C45.
• [x] Change R17, R19, R21 to 5%.
• [x] Add TC2030-NL footprint for SWD.
• [x] Improve pin 1 marking of oscillator Y1 footprint.
• [x] Add "Substitution" BOM field ("any equivalent" for most passives).
• [x] Select LED components and matching series resistors.
• [x] Move LED silkscreen labels closer to LEDs.
• [x] Connect PROGRAM_N to a nearby 3V3 FPGA I/O to allow for easier Debug Controller-less operation.
• [x] Potentially swap the SAMD21 with a SAMD11, for cost reduction.
• [x] Potentially move to USB-C connectors, instead of microUSB.

ZLP is sent with the DATAX PID, which is supposed to be toggled from the previous value. It seems USBInTransferManager is not doing that.

When sending ZLP, we do need to toggle DATA, but we don't need to swap the buffers. Right now, these two functions are done by the same signal. Hence we need to split them.

There's a non-zero chance of user error here. This is what I attempted (from memory):

• I created and entered a virtual environment (python -m venv)
• In nmigen/nmigen/, I ran python3 ./setup.py install
• In greatscottgadgets/luna/, I ran pip3 install poetry, poetry install
• I connected a cable from my laptop's USB port to the Luna board's "Debug/Alt Port"
  • There was a slow-blinking green LED, and a row of dim red (w/ one green) LEDs
• I ran poetry run applets/interactive-test.py
  • The green LED(s) momentarily ran a bouncing back and forth pattern
  • The row of red LEDs got brighter
  • This output was returned on the terminal:

INFO    | __init__    | Building and uploading gateware to attached LUNA r0.2...
INFO    | __init__    | Upload complete.
INFO    | selftest    | Connected to onboard debugger; hardware revision r0.2 (s/n: eebbd5a905b435050213e29382f031ff).
INFO    | selftest    | Running tests...


Automated tests:
        Debug module:   ✗ FAILED        (register 1 was 63, not expected 1413829460)
        Host PHY:       ✗ FAILED        (PHY register 0 was 3182280431, not expected 36)
        HyperRAM:       ✗ FAILED        (RAM register 0 was 3182280431, not one of expected (3201, 3206))
        Sideband PHY:   ✗ FAILED        (PHY register 0 was 3182280431, not expected 36)
        Target PHY:     ✗ FAILED        (PHY register 0 was 3182280431, not expected 36)

• [ ] change IC1 (FPGA) from 256 caBGA to 381 caBGA package, retaining ability to switch back to 256 caBGA later
• [ ] change U8, U9, U11 (USB PHYs) to USB3320
• [ ] rename Sideband port to "Control" and use as primary port for control of both FPGA and Apollo)
• [ ] rename Host port to "Aux" for auxiliary functions including MitM
• [ ] enhance Target-C PD/CC I/O with FUSB302B or similar Type-C controller
• [ ] connect shields of all USB connectors together
• [ ] disconnect USB shields from GND except through ferrites or 0 ohm resistors (populated by default)
• [ ] replace U1, U12, U13 (Target VBUS switches) with FET solution
• [ ] add Target VBUS voltage and current monitoring
• [ ] replace d1, D8 (5V diode OR) with FET solution
• [ ] move HyperRAM to FPGA pins in a DQS group if possible for both 381 caBGA and 256 caBGA variants
• [ ] increase clearance around U6 (microcontroller) to allow future replacement if necessary
• [ ] restore 1.8 V supply as an assembly option, supporting either 1.8 V or 3.3 V HyperRAM
• [ ] add pin straps for hardware version detection
• [ ] increase LED spacing
• [ ] add USB switch to Control port
• [ ] improve microcontroller D+/D- routing/reference plane
• [ ] maybe remove J5 (FPGA JTAG) if it is in the way
• [ ] maybe move Pmod connectors to the same side to support 24-pin Pmods
• [ ] maybe remove unpopulated SMA connectors
• [ ] maybe replace SMA connectors with high speed edge connector
• [ ] maybe add test points for DFU button, SBU signals

I followed the documentation and installed the dependencies, but an error was reported when I ran the command poetry install. It seems that the version of lambdasoc cannot match. What should I do?

kevin@kevin-virtual-machine:~/workspace/luna$ poetry install Installing dependencies from lock file

Because lambdasoc (0.1.dev27+gefd5442) @ git+https://github.com/ktemkin/lambdasoc.git@HEAD depends on nmigen (*) which doesn't match any versions, lambdasoc is forbidden. So, because luna depends on lambdasoc (0.1.dev27+gefd5442) @ git+https://github.com/ktemkin/lambdasoc.git, version solving failed.

Hello! I was wondering if Luna can be used out of the box as USB-UART bridge with an example. Do you think it's possible to generate a DTR and a RTS signals? Essencially I want to use the ECP5 to act like a USB-UART bridge to interface a ESP32 with a computer. It'd be amazing if it'd be possible to flash firmware via the USB-UART bridge to the ESP32 too! And the ESP32 can use DTR and RTS signals to put itself it bootloader mode, like so: Do you think it's possible? Thanks a lot ;)

The AP22811 have been marked as NOT RECOMMENDED FOR NEW DESIGN by Diodes lately, shall we consider use its successor, AP22818, as USB power switch at U1, U12, U13? Edit: both of them are NOT suitable for luna's design, see my latter comment.