USB-midi-device crashes when a lot of pitchbend messages are received [MicroPython v1.29.0]

[psitech]

As I wanted to test receiving MIDI pitchbend messages, I added the following lines to micropython/usb/usb-device-midi/usb/device/midi.py:

    def on_midi_event(self, cin, midi0, midi1, midi2):
        ch = midi0 & 0x0F
        if cin == _CIN_NOTE_ON:
            self.on_note_on(ch, midi1, midi2)
        elif cin == _CIN_NOTE_OFF:
            self.on_note_off(ch, midi1, midi2)
        elif cin == _CIN_CONTROL_CHANGE:
            self.on_control_change(ch, midi1, midi2)
        elif cin == _CIN_PITCH_BEND:              # <------------ Added these 4 lines
            # Pitch bend combines two 7-bit values into a 14-bit unsigned integer
            value = midi1 | (midi2 << 7)
            self.on_pitch_bend(ch, value)             

and

    def on_pitch_bend(self, channel, value):
        pass 

To micropython/usb/examples/device/midi_example.py I added these lines:

    def on_pitch_bend(self, ch, value):
        """Called when Pitch Bend is received. Value is an integer from 0 to 16383 (8192 is center)."""
        normalized = value - 8192
        print(f"PitchBend| Ch: {ch:<2} Raw: {value:<5} Relative to center: {normalized}")

Now when I move the pitchbend on my Arturia MiniLab MKII, it spits out a lot of pitchbend messages (every ~1ms). On a serial monitor, I see this:

After this, the Raspberry Pi Pico 2 hangs and I have to hit Thonny's "Stop/Restart backend" button twice to return/reset the Pico to the REPL.
It seems the rapid messages overflow a queue?

Paul

[agatti]

Thanks for the report.

Just to be sure, can you please try this on MicroPython v1.29.0 to see if it still happens?

[psitech]

Ah, wasn't aware that version 1.29 was released - Thonny 5.0.0 does not offer 1.29 to install..
Unfortunately same problem with 1.29.0 installed:

It does take more messages to crash though - I tried several times.

Paul

[agatti]

Thanks for trying again.

As a quick test I did try your code on an ESP32S3 (don't have a spare RP2350 available right away). I tried spamming pitch bend commands via VMPK on Linux and the USB queue didn't get full: that may either be due to the ESP32S3 being faster or VMPK not sending MIDI events fast enough.

If somebody else chimes in and tries that with a RP2350 before I get to it, I won't mind :)

[agatti]

OK, found something... Using https://pypi.org/project/rtmidi2/ and this bit of code together with the changes mentioned in the issue description:

import rtmidi2
out = rtmidi2.MidiOut()
# Port 1 is 'Espressif Device:Espressif Device MIDI 1 24:0' in my case
out.open_port(1)
while True:
    out.send_pitchbend(0, 0)  # channel, pitch

I get this out:

Traceback (most recent call last):
  File "usb/device/midi.py", line 168, in _on_rx
  File "usb/device/core.py", line 859, in pend_read
AttributeError: 'Buffer' object has no attribute '_b'
Traceback (most recent call last):
  File "usb/device/core.py", line 342, in _xfer_cb
  File "usb/device/midi.py", line 156, in _rx_cb
  File "usb/device/core.py", line 827, in finish_write
AttributeError: 'Buffer' object has no attribute '_b'

Maybe it's not related, but it's worth fixing!

[psitech]

Tried the same test with a Waveshare ESP32-S3-Zero loaded with Micropython 1.29.0.
Also crashes, but without mentioning a trouble source:

Paul

[agatti]

Yes, there's something weird happening here. Looks like when there's a lot of messages rushing in on the ESP32S3 something gets corrupted: the error message in #1158 (comment) shouldn't occur as Buffer._b is guaranteed to exist at all times.

I can even crash the interpreter with a read from unmapped memory from within Buffer.pend_read with a print(dir(self)) as its first line. Explicitly declaring the bytearray as a member variable of Buffer instead of keeping it inside the memoryview doesn't trigger a crash (won't fix the main issue either), but it may have moved things around just enough to change the outcome.

@projectgus You may be interested in this. Seems like the USB stack doesn't react that well with high message rates?

[projectgus]

Thanks for reporting this, @psitech.

RuntimeError: schedule queue full

This happens in the RX handler of the MIDI device which uses micropython.schedule() to defer work so that the callback functions aren't run from inside an interrupt handler. This "schedule" event queue has a limited depth (constant MICROPY_SCHEDULER_DEPTH, the value is 8 on the rp2 port.)

So if you receive 8 messages before all of the previously queued callbacks have run and finished, you may hit this limitation and see this exception.

We should fix this so that it drops the message (and maybe logs a warning) instead of breaking the driver, but MIDI messages will still be lost. To make it work successfully, you'll need to spend less time in the handler:

def on_pitch_bend(self, ch, value):
        """Called when Pitch Bend is received. Value is an integer from 0 to 16383 (8192 is center)."""
        normalized = value - 8192
        print(f"PitchBend| Ch: {ch:<2} Raw: {value:<5} Relative to center: {normalized}")**

Probably the debug print is the thing that's holding it up - the next scheduled callback can't run until the print statement in this callback is finished. It may be the actual "bytes on the wire" of printing is too high, but the other thing is that the format string has to allocate a new string each time - and this may trigger a garbage collection event that stops the callback for tens of milliseconds or longer.

You could try try something like:

def on_pitch_bend(self, ch, value):
        """Called when Pitch Bend is received. Value is an integer from 0 to 16383 (8192 is center)."""
        normalized = value - 8192
        print("PitchBend| Ch:", ch, "Raw:", value, "Center:", normalized)

... that version doesn't allocate, so it can't get stalled by a garbage collection. It's also a few less bytes of output.

If you want the prettier printouts (or if printing at all is still too much), then you'll need to find a way to decouple the prints from the high rate of callbacks - i.e. move the print out of the handler.

the error message in #1158 (comment) shouldn't occur as Buffer._b is guaranteed to exist at all times.

@agatti you have found a very strange bug. It looks different to @psitech's one, though! 🤔

[projectgus]

Oh, actually we don't need more than one internal callback scheduled at a time - so we can track it and not create redundant ones. Will submit a fix for this shortly.

(You may still need to make the print statement more efficient, or when the MIDI message rate is high you may find some are delayed or dropped at another part of the stack.)

[agatti]

Reproduction of my issue can be simplified on the ESP32S3. With regular 1.29.0 from micropython.org and the USB/MIDI python files uploaded to the device with no modifications, this can be used to trigger the crash after the ESP32 is put into USB-MIDI mode:

import rtmidi2 
out = rtmidi2.MidiOut() 
out.open_port(1) 
while True: 
    out.send_noteon(0, 0, 0)

Inserting calls to time.sleep() before sending the event does change the kind of output seen on device. Sleeping for 0.00390625 seconds between sends will trigger the queue full error seen on the RP2350. Sleeping for 0.005 seconds may either trigger Buffer._b not found or just crash the whole thing.

In the latter case the output is as follows:

A fatal error occurred. The crash dump printed below may be used to help
determine what caused it. If you are not already running the most recent
version of MicroPython, consider upgrading. New versions often fix bugs.

To learn more about how to debug and/or report this crash visit the wiki
page at: https://github.com/micropython/micropython/wiki/ESP32-debugging

MPY version : v1.29.0 on 2026-08-24
IDF version : v5.5.2
Machine     : Generic ESP32S3 module with ESP32-S3

Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x4037944c  PS      : 0x00060c30  A0      : 0x820308fa  A1      : 0x3fced4a0  
A2      : 0x3fced554  A3      : 0x3c174504  A4      : 0x3fcb9fb0  A5      : 0x3fcb963f  
A6      : 0x3fced55c  A7      : 0x3fcb963e  A8      : 0x8037944c  A9      : 0x3fced480  
A10     : 0x00009009  A11     : 0x000038a2  A12     : 0x00000006  A13     : 0x3fcb3954  
A14     : 0x3fced4c8  A15     : 0x3fced530  SAR     : 0x00000020  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x0000900d  LBEG    : 0x42054f96  LEND    : 0x42054f9f  LCOUNT  : 0x00000000  


Backtrace: 0x40379449:0x3fced4a0 0x420308f7:0x3fced540 0x420385ad:0x3fced5a0 0x42038677:0x3fced5c0 0x403797a2:0x3fced5e0 0x420308f7:0x3fced680 0x420385ad:0x3fced6b0 0x4206330b:0x3fced6d0 0x42063355:0x3fced710 0x420385ad:0x3fced730 0x42038635:0x3fced750 0x42039304:0x3fced780 0x42039551:0x3fced800 0x42028600:0x3fced830 0x42045486:0x3fced860 0x420307d1:0x3fced890 0x420385ad:0x3fced8b0 0x42038677:0x3fced8d0 0x403797a2:0x3fced8f0 0x420308f7:0x3fced990 0x420385ad:0x3fced9f0 0x4203861a:0x3fceda10 0x42055a71:0x3fceda50 0x42055c2a:0x3fceda90 0x420386fc:0x3fcedb90 0x40379a1d:0x3fcedbd0 0x420308f7:0x3fcedc70 0x420385ad:0x3fcedcc0 0x420385c2:0x3fcedce0 0x42049aae:0x3fcedd00 0x42049d88:0x3fcedd90 0x420280c0:0x3fceddd0

[agatti]

This looks like a VM stack overflow. What happens is that it crashes whilst executing a MP_BC_BUILD_SLICE opcode, and calling mp_obj_get_type(sp[-2]) returns 0x00009009 in my case, which is then deferenced as a pointer to figure out the ->flags member value.

0x00009009 is (_MIDI_NOTE_ON << 8) | _CIN_NOTE_ON, so... :)

[dpgeorge]

This looks like a VM stack overflow

I haven't seen one of those in a long time! If you want to try and debug that particular case, you can try enabling MICROPY_DEBUG_VM_STACK_OVERFLOW.

[agatti]

Thanks for the hint!

With that flag enabled the crash still occurs, even after replacing calls to assert(0) in the overflow/underflow handlers with an illegal opcode (building with DEBUG=1 makes it fail but not crash). I've had to add a print statement in Buffer.pend_read to make it crash with my own build, it seems to be slightly more robust than the official build

The bytecode VM is something outside of my area of expertise :| Assuming the overflow check is correct and not triggering, could it be that whatever is meant to be pushed onto the stack is not complete? As in, the push operation is interrupted by an external event (a new USB packet in this case) and then execution picks up from a new stack pointer that's not correct?

Anyway, the crash can be reproduced with these steps (the board may need to be rebooted a few times, and the script needs to be killed and re-run in that case):

$ esptool erase-flash
$ esptool --port <UART> --baud 460800 write-flash --flash-size=detect -fm dout 0 ESP32_GENERIC_S3-20260824-v1.29.0.bin
$ mpremote mip install usb-device-midi
$ mpremote cp $MICROPYTHON_ROOT/lib/micropython-lib/usb/examples/device/midi_example.py :

Plug the USB port to your computer, connect via the UART and then run import midi_example.

In another window:

$ sudo apt-get install librtmidi-dev # On Debian/Ubuntu
$ sudo pacman -S rtmidi # On Arch
$ python -m venv midibug
$ . midibug/bin/activate
$ pip install rtmidi2
$ cat << EOF > repro.py
import rtmidi2
out = rtmidi2.MidiOut()
for i, p in enumerate(out.ports):
    if p.startswith('Espressif Device:Espressif Device MIDI'):
        out.open_port(i)
        break
while True:
    out.send_noteon(0, 0, 0)
EOF
$ python repro.py

Usually it crashes on the first time, but you may end up with either an exception about Buffer._b not found or it just stops handling incoming MIDI messages (the latter is much more common when the firmware is built with DEBUG=1).

If you want I can create a proper issue in the interpreter repo for the ESP32 crash.