Arturia Beat Step Pro no data

[ctag-fh-kiel]

Describe the bug
Tried the C-Example usb_midi_host and connected a Beat Step Pro, the device is recognized with 2 Midi Cables, but no midi data is received

To Reproduce
Steps to reproduce the behavior:

1. Use example and connect Beat Step Pro

Screenshots
Logs:
Pico MIDI Host Example
MIDI opening Interface 1 (addr = 1)
MIDI opening Interface 1 (addr = 1)
MIDI descriptor parsed successfully
MIDI device address = 1, IN endpoint 1 has 2 cables, OUT endpoint 2 has 2 cables

What is your setup like?

• C
• What build machine OS and version: MacOS 14.5
• Version of this library : master
• Version of build software pico-sdk 1.5.1, tinyusb master
• How are you loading build images to the target: debug_probe

[ctag-fh-kiel]

Here is a screenshot of the logs, left side working with Novation Launchpad, right side stuck with Beat Step Pro
Beat Step Pro allocates bulk endpoint, Launchpad allocates int endpoint, does this mean anything to you?

[rppicomidi]

@ctag-fh-kiel Thank you for taking the time to report this issue.

To help you with this issue, I need some more data.

• Which C example are you running (usb_midi_host_example) or ('usb_midi_host_pio_example`)?
• What version of the usb_midi_host code are you using?
• Instead of screenshots, please attach text files with the log output. I have to look at my issue template. Screenshot is probably not what should be there.
• Please attach a text file dump of the USB descriptors for the device that does not work. In MacOS homebrew you can use the command lsusb to find the vid:pid numbers and then lsusb -d vid:pid -v to get the full descriptor
• Is there any indication that transmission to the Beat Step Pro is working? How about to the Launchpad?
• Please describe the hardware that is running the test program.
• What are you doing on the Beat Step Pro to send data?

To answer your question about the bulk vs. interrupt endpoint, USB data connections within a device are called endpoints. Each endpoint type has different characteristics. The important thing here is that USB MIDI 1.0 class spec says to use Bulk endpoints for data transfer; the Beat Step Pro is doing this correctly, so that is not the issue. Some implementations erroneously use Interrupt endpoints, but my driver supports both.

In the meantime, I will try my Arturia KeyLab Essential 88 again to make sure I have not introduced a bug by accident.

[ctag-fh-kiel]

@rppicomidi Thanks a lot for getting back!

• I have been using usb_midi_host_example
• Using usb_midi_host 1.1.1
• Log files are attached (including a log from Elektron Digitone (working))
• USB descriptor of the Beatstep Pro is attached
• I can't say if the Beatstep Pro receives data from usb_midi_host_example, I would have to see how I could check that, as it can't produce a sound by itself
• For the Launchpad I can say that send/receive works, same for an Elektron Digitone no problems (both logs attached)
• I am using a custom PCB based on a standard rp2040 setup, using the the USB lines attached to a USB-A jack
• Starting the sequencer on the BSPro and pressing the trigger pads + rotating the controls to send midi data, I have checked the CC mappings (Arturia Midi Controll Center) and the BSPro should send messages, cross checked this with the BSPro in Ableton, where it works fine

Arturia-BSPro-ErrorLog.txt
Arturia-BSPro-USB.txt
ElektronDigitoneLog.txt
NovationLPMiniLog.txt

[rppicomidi]

@ctag-fh-kiel Thank you for the data. I am puzzled. As I read the configuration descriptor from BSPro error log and from the device info in the BSPro file, the BSPro has the same USB descriptors as my Arturia Keylab Essential 88 keyboard except for the device descriptor product ID. My keyboard works fine with the example code. On my keyboard, the LEDs behind the transport controls turn on and off one after the other as expected and the terminal outputs the correct MIDI data in response to key presses.

For your reference, the output of the command lsusb -d 1c75:02ca -v is attached (from a Linux PC. I was sure Mac Homebrew has a version of the lsusb command that produces the same output).
KeylabEssential88_USB_descriptor.txt

I would like to try to debug one thing at a time.

First, there may be a power issue. May I ask you try again by connecting the BSPro via a powered USB hub? If that does not work, please try the other devices you have that are known good. If they work and the BSPro does not, then I believe we can rule out electrical issues.

Second, the BSPro may not like receiving the note messages the code sends. Please disable the MIDI messages sent to the BSPro by commenting out line 127:

send_next_note(connected);

Then rebuild and see if the example code reacts to any of the drum pad taps, knob turns, or button presses.

If that does not work, may I ask if CTAG have a USB analyzer of any sort? If so, a trace of what is going on may be telling.

If not, I will see if anyone I know has a BSPro they could lend me. That will be a longer route because I am traveling soon and won't return until July.

[ctag-fh-kiel]

@rppicomidi Thanks again for testing. I have checked the power situation with a 2A supply, should be fine.

Attached another dump from lsusb this time from linux, somehow homebrew lsusb did not work correctly.
The descriptor seems to be a bit longer than the one from your Keylab.
I tried commenting out L.127 no success either, attached the log from that experiment.

I don't have access to a usb analyzer unfortunately.

Thanks for your help! :)

BSPro-no-send-next-note-log.txt
BSPro_USB-2.txt

[rppicomidi]

@ctag-fh-kiel Thank you for the new data. Short answer. I do not believe descriptor parsing is the problem. Also, there is nothing in the Error Log that you sent that looks unusual to me. Can you confirm that the BSPro is it running the latest firmware? If so, I will need a USB trace to investigate further (to compare a working version with a Mac, PC or Linux computer vs. this TinyUSB driver).

Longer answer:

The descriptors for the BSPro and the KeyLab are the same length. The only differences between the descriptors are in the device descriptor (the BSPro uses 500mA max power and the Keylab on 100mA) and the MIDIStreaming Interface descriptors (the BSPro has the jack descriptors in a different order from the Keylab and the BSPro has an error in the MIDIStreaming Interface Descriptor header (the wTotalLength field is off by 2 for some reason). However, the usb_midi_host driver ignores the MIDIStreaming Interface descriptors unless you enable the jack string support, and it also ignores the wTotalLength field in the MIDIStreaming Interface Descriptor header; it relies on the wTotalLength field in the Configuration Descriptor instead (0x85 = 133 bytes).

[ctag-fh-kiel]

Hi there, Yes, I updated my BSPro to test if that is the issue, it runs on the latest firmware. Thanks for further investigations :)

…

On Mon, Jun 17, 2024 at 8:11 PM rppicomidi ***@***.***> wrote: @ctag-fh-kiel <https://github.com/ctag-fh-kiel> Thank you for the new data. Short answer. I do not believe descriptor parsing is the problem. Also, there is nothing in the Error Log that you sent that looks unusual to me. Can you confirm that the BSPro is it running the latest firmware? If so, I will need a USB trace to investigate further (to compare a working version with a Mac, PC or Linux computer vs. this TinyUSB driver). Longer answer: The descriptors for the BSPro and the KeyLab are the same length. The only differences between the descriptors are in the device descriptor (the BSPro uses 500mA max power and the Keylab on 100mA) and the MIDIStreaming Interface descriptors (the BSPro has the jack descriptors in a different order from the Keylab and the BSPro has an error in the MIDIStreaming Interface Descriptor header (the wTotalLength field is off by 2 for some reason). However, the usb_midi_host driver ignores the MIDIStreaming Interface descriptors unless you enable the jack string support, and it also ignores the wTotalLength field in the MIDIStreaming Interface Descriptor header; it relies on the wTotalLength field in the Configuration Descriptor instead (0x85 = 133 bytes). — Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZMGRUW4K7UDSP2ISQJUGDZH4RFTAVCNFSM6AAAAABJKAVBHSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZUGAZDKOJQGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ctag-fh-kiel]

I have been able to get a hold of a USB analyzer, attached both traces (Launchpad and BSPro) edit attached new BSPro trace, where after 1.39s only bursts with the same data are sent.
I used the same cable, which works when directly connected to the PC for both controllers.
USB-Traces2.zip

[ctag-fh-kiel]

Attached some screen captures of the acquisitions, interestingly the BSPro goes into some sort of a burst mode after 1.3s or so, not following a 1ms frame pattern. Whereas LP Mini stays in sending frames every 1ms.
USB-Traces-ScreenCaps.zip

[rppicomidi]

@ctag-fh-kiel I have returned from my travels. To make sure I understand, your BSPro runs the latest firmware and yet usb_midi_host still fails to work.

Also, what software are you using to generate the traces? I can read CSV data into a spreadsheet, but it is nicer if the software can decode data packets into USB requests, descriptors, and so forth. For example, if you used PulseView, the raw traces would be useful to me because I also have that software and could apply the USB Request protocol decoder.

[ctag-fh-kiel]

Hi there, yes, BSPro latest firmware and usb_midi_host still fails.
I have used PicoScope. I could provide you with the raw data as well, but it will be huge. Let me know if needed.

[rppicomidi]

@ctag-fh-kiel Ah, I see the request decoder is already there. My mistake. No need to send raw data.

Would you please include a CSV trace where the BSPro successfully connects to a computer and transmits MIDI data to the computer? It may give a clue to the difference.

The decoded trace you sent shows a normal enumeration sequence and at time 1.14987083692566, a normal set configuration packet. The BSPro seems to always NAK IN requests from the host on endpoint 1, which should mean the BSPro is not ready to send data. All of that looks normal on first glance. It looks like the "burst mode" after 1.3 seconds is the host repeatedly trying to start a bulk IN transfer and the BSPro repeatedly sending NAK to indicate it has nothing to send.

[rppicomidi]

@ctag-fh-kiel I am also this week going to try out some USB packet sniffers based on a Raspberry Pi Pico board. https://github.com/tana/pico_usb_sniffer and https://github.com/ataradov/usb-sniffer-lite. I suspect those will be simpler to use than the analyzer you are using. I will let you know what I find.

[ctag-fh-kiel]

Attached a trace when BSPro is connected to Mac and works fine, the data looks different. I think it seems more normal similar to the Launchpad (which worked with usb_midi_host).
BSPro-mac-usb.csv

[ctag-fh-kiel]

All traces are without actually sending Midi data, they are all from power on to ready to send/rcv...