EZ_USB_MIDI_HOST_PIO_example.ino stops handling MidiInCallbacks after ~ 3 Seconds of MIDI Device Inactivity

[SoerenSofke]

Hi,

I really appreciate this library, as it provides an excellent starting point for my own project, which is to create a MIDI message filter. I intend to instrument EZ_USB_MIDI_HOST on my Adafruit Feather RP2040 with USB Type A Host, connect a MIDI device to the USB Type A Host connector on the Feather and a PC with a software synthesizer on the USB Type C connector on the Feather.

However, I can not even make the given example, e.g. EZ_USB_MIDI_HOST_PIO_example.ino run as expected.

My development environment

• Fedora Linux, Version 40
• Arduino IDE, Version 2.3.2
• EZ_USB_MIDI_HOST, Version 2.0.0
• PICO PIO USB, Version 0.5.3, #4
• Adafruit Feather RP2040 with USB Type A Host

Things that work as expected

• Compilation and upload of EZ_USB_MIDI_HOST_PIO_example.ino with modification in setup1(), e.g.

  // Sets pin USB_HOST_5V_POWER to HIGH to enable USB power
  pinMode(18, OUTPUT); 
  digitalWrite(18, HIGH);

• Serial monitor in Arduino IDE output diagnostic strings, incl. diagnostics regarding incoming MIDI messages, e.g.

  21:27:11.549 -> EZ USB MIDI HOST PIO Example for Arduino
  21:27:11.549 -> Core1 setup to run TinyUSB host with pio-usb
  21:27:12.065 -> MIDI device at address 1 has 1 IN cables and 1 OUT cables
  21:27:12.808 -> C1: Note on#51 v=16
  21:27:13.001 -> C1: Note on#51 v=0
  21:27:13.130 -> C1: Note on#51 v=28
  21:27:13.259 -> C1: Note on#51 v=0
  21:27:13.422 -> C1: Note on#51 v=11
  21:27:13.583 -> C1: Note on#51 v=0

Things that do NOT work as expected

• Once the connected MIDI device does not send MIDI events for more than ~ 3 seconds, the Arduino software EZ_USB_MIDI_HOST_PIO_example.ino stops handling MidiInCallbacks, e.g. onNoteOn, onNoteOff, but also onMIDIdisconnect, etc.

• The MIDI device cannot be hot-plugged, i.e. it must be connected to the USB Type A port before Feather is powered up (which is less important for now but might be an issue as well).

How to proceed

• I would not rule out mistakes in compiling the sources or configuring the Feather. So please make suggestions and challenge my approach.
• I would not exclude that my expectations are wrong. So please challenge them as well.
• If more information is needed to help me run the example, please give me detailed instructions to follow. My project really depends on this library, and I would like to give you the best feedback I can.

Thanks, Sören

[rppicomidi]

@SoerenSofke Thank you for taking the time to file this issue. I see nothing wrong with your expectations.

I do not have the feather board, so I can only take guesses on how to help. I will try to figure it out with you if you will work with me. Please accept my apology in advance if you have already done the basic steps.

First, verify you have selected the Adafruit Feather RP2040 USB Host board as the board type in the Arduino IDE.

Next, do you have a way to measure the power output of the Feather's USB host port? If so, please verify that you are measuring a full +5VDC between the USB A port's VBus pin and ground. Measure before you plug the device to the port and afterwards. The Feather board uses the RP2040's GPIO 18 to turn on the 5V VBus power to the host port. I am not sure if the software activates the pin or not. If the power is good before you plug in but not afterwards, then the surge current of the device you are plugging in may be too high or you may be otherwise overloading your computer's USB port's power output capability. If you have a powered hub you can put between the computer and the Feather board or between the Feather board and your MIDI device, that may solve the problem.

If power is a steady 5V, please modify the example code to not transmit MIDI to your MIDI messages to your device. That will tell us if the problem is related to sending to your MIDI device. You can disable the transmissions by commenting out the sendNextNote() function call in the loop() function as follows:

void loop() {    
    // Handle any incoming data; triggers MIDI IN callbacks
    usbhMIDI.readAll();
    // Do other processing that might generate pending MIDI OUT data
    // Commenting this line out ==> sendNextNote();

    // Tell the USB Host to send as much pending MIDI OUT data as possible
    usbhMIDI.writeFlushAll();

    // Do other non-USB host processing
    blinkLED();
}

If none of these things solve the problem, please tell me more about the brand and model of the MIDI device you are plugging to the Feather board.

[SoerenSofke]

Dear @rppicomidi,

First, verify you have selected the Adafruit Feather RP2040 USB Host board as the board type in the Arduino IDE.

The board selected is of type Adafruit Feather RP2040 USB Host

please verify that you are measuring a full +5VDC between the USB A port's VBus pin and ground

• I measure 5.08 V without the MIDI device attached
• I measure 5.05 V with the MIDI device attached

The Feather board uses the RP2040's GPIO 18 to turn on the 5V VBus power to the host port. I am not sure if the software activates the pin or not.

In my initial post, I mentioned that I modified setup1() in order to power VBus with 5V. As you assumed, the default configuration was not allowing for a proper supply of the attached MIDI device.

Compilation and upload of [EZ_USB_MIDI_HOST_PIO_example.ino]>(https://github.com/rppicomidi/EZ_USB_MIDI_HOST/blob/2.0.0/examples/arduino/EZ_USB_MIDI_HOST_PIO_example/EZ_ USB_MIDI_HOST_PIO_example.ino) with modification in setup1(), e.g.

// Sets pin USB_HOST_5V_POWER to HIGH to enable USB power pinMode(18, OUTPUT); digitalWrite(18, HIGH);

If you have a powered hub you can put between the computer and the Feather board or between the Feather board and your MIDI device, that may solve the problem.

I followed your suggestion and used a powered USB hub. However, this changes the power-up sequence to an unfavorable order, i.e. the MIDI device is turned on before the Feather boots, and as a consequence the Feather does not detect the MIDI device at all, which may be suspicious in itself, but is the same as without the powered USB hub.

If power is a steady 5V, please modify the example code to not transmit MIDI to your MIDI messages to your device.

I conducted this experiment in advance without mentioning it in my initial post, since it did not change my observation: Not handling incoming MIDI events after some seconds of MIDI device inactivity.

I do not have the feather board, so I can only take guesses on how to help.

If you like, I would like to sponsor you with a bunch of Adafruit Feather RP2040 USB host boards to test your code. In my opinion, your software library is great and a perfect complement to this very board. Many hobbyists like me will most likely use your library with this very Feather board. So please send me your e.g. Paypal and I will send you the money to support this project.

Best, Sören

[rppicomidi]

@SoerenSofke Thank you for your generous offer to sponsor my work here. I must decline. The MIDI projects I do for fun. The only reason I have not yet purchased the feather board is my workshop already has too many boards in it. I am currently working on a different issue with the Arturia BeatStep Pro. Once I am through with that bug, I will attempt to duplicate the issues you are seeing with hardware that I have. If I am unable to duplicate them, I will order one of those feather boards myself.

[rppicomidi]

@SoerenSofke

I have a little time to work on this. I am not seeing any of the issues you are reporting with just my Raspberry Pi Pico board hand-wired to a USB A connector powered via the Pico board's built-in micro USB port. I plan to order a feather board this week.

Can you tell me what your MIDI test device is? There might be something special about the device that is confusing my software. The MIDI devices I am using to test are a Korg nanoKONTROL2 and a Yamaha Reface CS. When it is idle, the nanoKONTROL2 sends nothing to the USB Host. The Yamaha Reface CS, on the other hand, is constantly sending MIDI clock and Active Sensing.

This is not an issue you reported, but I will bring it up anyway. The example code will block until the feather board's USB C port is connected to a computer with an active serial terminal. That means that the feather's USB host will not react to the MIDI device unless the feather board is connected to a PC with the Arduino IDE with the serial monitor window open or some other serial port terminal.

[rppicomidi]

@SoerenSofke Because you mention not ruling out compile issues, please tell me how you have set up the Arduino IDE options under the "Tools" menu. In particular, what are your settings for

• Debug Level
• C++ Exceptions
• CPU Speed
• Optimize
• RTTI
• Stack Protector
• USB Stack

?

[SoerenSofke]

Dear @rppicomidi

I have a little time to work on this.

I am glad to hear that. I will try to report as well as I can to help you reproduce my issue.

Can you tell me what your MIDI test device is?

The two MIDI devices I use for testing are (incl. diagnostic outputs):

• ESI Xjam (The release of the Pad is treated as a NoteOn with velocity 0, which is MIDI-compliant but not seen very often these days)
• Arturia MicroLab

With both MIDI devices, I see the same issue that the example stops handling MIDI callbacks after ~3 seconds of MIDI inactivity, be it e.g.

• onNoteOff
• onNoteOn
• onMIDIdisconnect

During inactivity, none of my devices is sending any kind of messages. At least, this is what I retrieve when using MIDI View on Windows (not my primary PC for development).

The example code will block until the feather board's USB C port is connected to a computer with an active serial terminal.

Thanks for bringing this up. I am aware of this behavior by looking at the source code.

please tell me how you have set up the Arduino IDE options under the "Tools" menu

Please see the standard configuration I am using below:

Btw, to rule out a hardware defect of my Feather board, I tested with a second one I recently ordered and see the exact same issue.

[rppicomidi]

@SoerenSofke Try changing the "Optimize" setting to -O3.

I just noticed that the console output you posted looks a bit more complex than I would expect from the source code. I deliberately made the prints short because the callbacks run on the same processor that is running the USB host code. Did you modify the prints in the example code, or did your console program expand the output for you? If you modified the prints, please try with the unmodified serial prints. There are buffers that can back up if they are not drained quickly enough. If you need to do extensive work on data like fancy print formatting, you should use the Pico SDK queue function to move data MIDI data from core1 to core0.

If none of these suggestions fix your issue, please post the USB descriptors for your two test devices. The easiest way to do that in Linux is

lsusb

to get a list of all USB devices plugged to your computer, along with their VID:PID numbers

lsusb -d (the MIDI device VID:PID number) -v

If I can't figure anything out from the USB descriptor, I might ask you for a USB sniffer trace. If you don't have access to a commercial USB packet sniffer (I don't), it is straightforward to build your own USB sniffer with a RP2040 board. I use this one.

[rppicomidi]

@SoerenSofke Also, if you don't want to spin up your Windows PC to look at MIDI output from your devices, you can use the amidi command on your Linux PC. See man amidi for more information.

[SoerenSofke]

Dear @rppicomidi

Try changing the "Optimize" setting to -O3.

This change does not have any positive effect. The issue is still present.

I just noticed that the console output you posted looks a bit more complex than I would expect from the source code.

I did not change any `Serial.printf' statements. You are probably referring to the timecode at the beginning of each line. I expect the Arduino IDE to add this, since it's my wall clock time that the Feather doesn't know.

If none of these suggestions fix your issue, please post the USB descriptors for your two test devices

Please check the output of lsusb for the two MIDI devices I am using:

lsusb -d 1c75:020a -v

Bus 003 Device 020: ID 1c75:020a Arturia Arturia MicroLab
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 [unknown]
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1c75 Arturia
  idProduct          0x020a Arturia MicroLab
  bcdDevice            2.00
  iManufacturer           1 Arturia
  iProduct                2 Arturia MicroLab
  iSerial                 3 7021400202030478
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0065
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      1 Control Device
      bInterfaceProtocol      0 
      iInterface              0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength       0x0009
        bInCollection           1
        baInterfaceNr(0)        1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         1 Audio
      bInterfaceSubClass      3 MIDI Streaming
      bInterfaceProtocol      0 
      iInterface              0 
      MIDIStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength       0x0041
      MIDIStreaming Interface Descriptor:
        bLength                 6
        bDescriptorType        36
        bDescriptorSubtype      2 (MIDI_IN_JACK)
        bJackType               1 Embedded
        bJackID                 1
        iJack                   6 
      MIDIStreaming Interface Descriptor:
        bLength                 6
        bDescriptorType        36
        bDescriptorSubtype      2 (MIDI_IN_JACK)
        bJackType               2 External
        bJackID                 2
        iJack                   0 
      MIDIStreaming Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (MIDI_OUT_JACK)
        bJackType               1 Embedded
        bJackID                 3
        bNrInputPins            1
        baSourceID( 0)          2
        BaSourcePin( 0)         1
        iJack                   7 
      MIDIStreaming Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (MIDI_OUT_JACK)
        bJackType               2 External
        bJackID                 4
        bNrInputPins            1
        baSourceID( 0)          1
        BaSourcePin( 0)         1
        iJack                   0 
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
        bRefresh                0
        bSynchAddress           0
        MIDIStreaming Endpoint Descriptor:
          bLength                 5
          bDescriptorType        37
          bDescriptorSubtype      1 (Invalid)
          bNumEmbMIDIJack         1
          baAssocJackID( 0)       1
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
        bRefresh                0
        bSynchAddress           0
        MIDIStreaming Endpoint Descriptor:
          bLength                 5
          bDescriptorType        37
          bDescriptorSubtype      1 (Invalid)
          bNumEmbMIDIJack         1
          baAssocJackID( 0)       3

and

Bus 001 Device 023: ID 2573:0036 ESI Audiotechnik GmbH Xjam
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 [unknown]
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x2573 ESI Audiotechnik GmbH
  idProduct          0x0036 Xjam
  bcdDevice            1.55
  iManufacturer           1 ESI
  iProduct                2 Xjam
  iSerial                 3 midi
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0065
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      1 Control Device
      bInterfaceProtocol      0 
      iInterface              0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength       0x0009
        bInCollection           1
        baInterfaceNr(0)        1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         1 Audio
      bInterfaceSubClass      3 MIDI Streaming
      bInterfaceProtocol      0 
      iInterface              0 
      MIDIStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength       0x0041
      MIDIStreaming Interface Descriptor:
        bLength                 6
        bDescriptorType        36
        bDescriptorSubtype      2 (MIDI_IN_JACK)
        bJackType               2 External
        bJackID                 2
        iJack                   0 
      MIDIStreaming Interface Descriptor:
        bLength                 6
        bDescriptorType        36
        bDescriptorSubtype      2 (MIDI_IN_JACK)
        bJackType               1 Embedded
        bJackID                 1
        iJack                   0 
      MIDIStreaming Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (MIDI_OUT_JACK)
        bJackType               1 Embedded
        bJackID                 3
        bNrInputPins            1
        baSourceID( 0)          2
        BaSourcePin( 0)         1
        iJack                   0 
      MIDIStreaming Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (MIDI_OUT_JACK)
        bJackType               2 External
        bJackID                 4
        bNrInputPins            1
        baSourceID( 0)          1
        BaSourcePin( 0)         1
        iJack                   0 
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
        bRefresh                0
        bSynchAddress           0
        MIDIStreaming Endpoint Descriptor:
          bLength                 5
          bDescriptorType        37
          bDescriptorSubtype      1 (Invalid)
          bNumEmbMIDIJack         1
          baAssocJackID( 0)       1
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
        bRefresh                0
        bSynchAddress           0
        MIDIStreaming Endpoint Descriptor:
          bLength                 5
          bDescriptorType        37
          bDescriptorSubtype      1 (Invalid)
          bNumEmbMIDIJack         1
          baAssocJackID( 0)       3

If I can't figure anything out from the USB descriptor, I might ask you for a USB sniffer trace.

Sure. I could also foresee instrumenting an Arduino board and using it as a MIDI test pattern generator. This should be very simple and create a reproducible MIDI test pattern that can be used on your side and mine to ensure exactly the same stimuli for both of us.

Best, Sören

[rppicomidi]

@SoerenSofke Thank you for sending the descriptors. I don't see anything unusual about either descriptor, so I will need more data.

I have ordered a Feather board directly from Adafruit. I am not sure how long it will take to get to me. Sure, a common test platform may be good. The Arturia MicroLab is low cost enough that I might buy one if I can't duplicate your issues with the Feather board and a device I have.

If you are willing to take the time to make a USB packet trace of the scenarios that do not work, I think that is a good next step. It may be helpful to debug your packet trace tool first by plugging into a computer that successfully works with your MIDI devices. If you do decide to take computer USB host traces, please save them. It would be useful to see any differences. Because one issue takes more than 3 seconds to happen, it may be helpful to use a streaming USB sniffer. This one may do the job if you tell it to filter out SOF packets. I have not tried that one yet but I will if you would like my help with it. When you send traces, please send them as attached data files instead of screen shots or copy/paste text. Thanks.

[SoerenSofke]

Dear @rppicomidi

I have ordered a Feather board directly from Adafruit

I really appreciate your engagement. Thank you for your great support.

If you are willing to take the time to make a USB packet trace of the scenarios that do not work, I think that is a good next step.

I checked the instructions and the needed ingredients. I think I can create a USB sniffer by the end of the week. I will keep you posted as soon as I have the USB traces in place.

Best, Sören

[rppicomidi]

@SoerenSofke I have tried the tana USB packet sniffer and confirmed it produces a pcap format file that works with Wireshark. I captured over 30 seconds of data. A few things about the Python capture program pico_usb_sniffer.py: It had to install the pyserial and and sliplib python libraries using the pip3 command. That is:

pip3 install pyserial
pip3 install sliplib

There is no user interface on the capture program other than the command line. My sniffer probe enumerated on /dev/ttyACM1, so the command line I used was

python3 pico_usb_sniffer.py -o capture.pcap /dev/ttyACM1

Once I ran the program, I had to press CTRL+C to stop it. To view the data, I ran wireshark and used the File->Open menu item. Hope this information is helpful.

[SoerenSofke]

Dear @rppicomidi

Today I made the USB packet sniffer board with the following setup:

• Blue USB Cabel: Arturia MicroLab MIDI device
• Red USB Cable: Linux PC
• Black USB cable: Linux PC

Sequence of Operation

1. I have plugged in the blue USB cable to atach the Arturia MIDI device
2. I started the USB-packed sniffer python software: python3 pico_usb_sniffer.py -o capture.pcap /dev/ttyACM0.
3. I plugged in the red USB cable (initialization of Arturia MicroLab should be in the USB trace)
4. I played 15 keys on the Arturia MicroLab (data should be in the USB trace)
5. I unplugged the red USB cable (teardown of Arturia MicroLab should be in the USB trace, if any)
6. I stopped the USB packet sniffer with CTRL+C

The Trace Please find the trace attached: microlab-2-pc.zip

Analysis While I can open the trace in Wireshark, I am not able to understand the reported data. If you can confirm valid data, I will trace the USB traffic between the Feather board and the Arturia in the next days. The Raspberry Pico I used as a USB packet sniffer was purchased for this very experiment. I could also use it to test your EZ_USB_MIDI_HOST_PIO_example.ino to see if the same problem occurs on this device.

I look forward to your feedback.

Best, Sören

[rppicomidi]

Thank you for the trace data. Either your packet sniffer is reading the data wrong, or there is a problem with your setup. You can tell there are problems because the trace is reporting CRC errors. For example, look at the sequence from packet 65 to packet 71. This sequence is the Linux PC Host reading the device descriptor from the device. In the Wireshark UI, click on packet 70, then expand the USB Packet line.

Frame 70: 21 bytes on wire (168 bits), 21 bytes captured (168 bits)
USB Packet
    PID: DATA1 (0x4b)
    Data: 1201000200000040751c0a02000201020502
    CRC: 0xde9c incorrect, should be 0x1fdf
    [CRC Status: Bad]
    [Source: 0.0]
    [Destination: host]

The CRC Status is bad. That means there is an error in the data. You can compare the data in the Data: line with the device descriptor you captured using lsusb.

Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 [unknown]
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1c75 Arturia
  idProduct          0x020a Arturia MicroLab
  bcdDevice            2.00
  iManufacturer           1 Arturia
  iProduct                2 Arturia MicroLab
  iSerial                 3 7021400202030478
  bNumConfigurations      1

The sniffer is reading that the last 2 bytes of the data, iSerial and bNumConfigurations, are wrong: They should be 0x03 0x01 and the sniffer captured 0x05 0x02.

Now please look at packet 71. The host responded with ACK, which means that the host did not detect an error in the data. You can verify that by issuing the lsusb -d 1c75:020a -v command at the host again and verify that the device descriptor still shows the same initial 18 bytes.

That says to me that the problem is in the sniffer. Some possibilities:

• Are you using two different brands of USB A female breakout board? It is hard to tell from the photo how the D+ and D- pins are wired. I assume you double-checked the wiring of the D+ pin in particular because I believe that is what the sniffer code samples.
• I would connect the USB ground pin to a Pico board pin closer to the USB sniffer data pins. It probably won't make much difference, but it is worth a shot.
• How long is the red cable to your your host? You want that cable to be very short. I recognize that you cannot shorten the blue cable because it is captive to your keyboard.
• Did you build the sniffer .uf2 image yourself, or did you download the .uf2 image from the GitHub page? I want to rule out build errors if it is possible.

Let me know if what I wrote is clear.

[SoerenSofke]

Dear @rppicomidi

Are you using two different brands of USB A female breakout board? It is hard to tell from the photo how the D+ and D- pins are wired. I assume you double-checked the wiring of the D+ pin in particular because I believe that is what the sniffer code samples.

I can ensure that the pin assignment was done correctly. However, I used pins / headers between the Raspberry PICO and the USB male/female breakout. Maybe the connection was not stable during data recording.

I would connect the USB ground pin to a Pico board pin closer to the USB sniffer data pins. It probably won't make much difference, but it is worth a shot.

See your point

How long is the red cable to your your host? You want that cable to be very short. I recognize that you cannot shorten the blue cable because it is captive to your keyboard.

30 cm. However, I could also plug the male USB connector directly into my PC, reducing the impact of the red cable at all.

Did you build the sniffer .uf2 image yourself, or did you download the .uf2 image from the GitHub page? I want to rule out build errors if it is possible.

No, I used the .uf2 image from the release page.

In my attempt to improve the electrical connection between the Raspberry PICO and the USB male/female breakout, I destroyed a relevant pad on the PICO. So I ordered a new board and will retry the data capture in a few days.

In the meantime, I will test EZ_USB_MIDI_HOST_PIO_example.ino with the Raspberry PICO.

Best, Sören

[SoerenSofke]

Dear @rppicomidi,

Meanwhile, I've come to the conclusion that it's not the handling of MidiInCallbacks, but the diagnostic strings sent in each MidiCallback that cause the problem of getting stuck after ~3 seconds of inactivity. Let me explain what I have done:

1. In addition to using the Adafruit Feather with USB host, where I first observed the issue, I also tested using a regular Raspberry Pico (not Pico W). I saw the same problem again.
2. I implemented the onNoteOff and onNoteOn function as follows

static void onNoteOff(Channel channel, byte note, byte velocity) 
{
    digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));    
}

static void onNoteOn(Channel channel, byte note, byte velocity) 
{
     digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));    
}

I can see that the LED toggles every time I press or release a key on Arturia MicroLab or a pad on ESI Xjam, even after very long periods of inactivity.

What do you think?

Best, Sören

[SoerenSofke]

Dear @rppicomidi

I have further investigated the conditions under which receiving messages from the serial port stopped after 3 seconds of inactivity. Here are my findings:

1. It does not work under Linux using the built-in serial monitor in the Arduino IDE.
2. It does not work under Linux in Putty
3. It does not work under Linux using screen in a terminal
4. It works on Windows (e.g. built-in serial monitor in Arduino IDE)

So I would conclude that something on my Linux machine is causing the problem. However, I can see that the timeout is disabled, which I check with stty.

Best, Sören

[rppicomidi]

@SoerenSofke Sorry I have not been more responsive. I am fighting illness. I will respond when I am able.

[rppicomidi]

@SoerenSofke Finally feeling well enough to this morning to try something. I received the same Adafruit RP2040 Feather with USB Host board you are using. I made what I think are the same minor modifications you made to the example sketch to switch on USB power.

I am afraid I cannot duplicate your issues. Hot plugging works fine. The code does not stop running. I notice that even the red LED near the board's USB connector blinks correctly.

I am attaching my sketch for you to try. As before, set optimization level to -O3. Set USB Stack to Adafruit and CPU Speed to 120 MHz. I am using the built-in Serial Monitor terminal. Library versions I am using Adafruit_TinyUSB 3.3.1 EZ_USB_MIDI_HOST 2.0.0 MIDI_Library 5.0.2 Pico PIO USB 0.6.0 usb_midi_host 1.1.1

I am using core Raspberry Pi Pico/RP2040 3.9.3

Arduino IDE 2.3.2

EZ_USB_MIDI_HOST_PIO_example_fix.zip

[SoerenSofke]

Dear @rppicomidi

I am glad that you are recovering quickly.

Please take a look at my last 3 comments above. I think I have a better understanding of the situation, even if I have not finally identified the fundamental root cause. However, it seems that the Feather and related firmware are working fine, but the problem was somehow caused by the Linux PC not receiving the diagnostics messages correctly.

I recently migrated from Fedora Linux to Nix OS (that was on my list anyway) and will test the situation again later today.

Best, Sören

[rppicomidi]

@SoerenSofke If you have identified the issue on your end as a problem with your terminal software in Linux, is it OK to close this issue?

[SoerenSofke]

Dear @rppicomidi

Yes, indeed. I will close the issue as it was caused by my development PC / OS and not by your MIDI host library or the Feather board.

Best and many thanks for your great support in supporting the root cause analysis Sören