USB Error and reset when using UART bridge to read data

General
1

Hi all,

I’m currently using the BP5 to read out some binary system information with the following configuration:

UART speed: 921600 baud
Data bits: 8
Parity: None
Stop bits: 1
Hardware flow control: None
Signal inversion: Non-inverted (Standard)

After setting the BP in bridge mode and doing a couple of reads using python and pyserial my buspirate usb connection drops and windows gives me the error that the usb device is not recognised. After removing the usb cable and rebooting the BP everything is back operational.

Does anyone know what i’m doing wrong or how to fix this?

Kind regards,

Michael

config:
Bus Pirate 5 REV10
Firmware main branch @ 96d092f (2024-10-10T04:14:29Z)
RP2040 with 264KB RAM, 128Mbit FLASH

2

Hi Michael,

Thank you for the bug report. I’m looking into it now.

ian

3

Hi Ian,

If needed I can send you my python code for reference, unfortunately I can not send you my target for debugging :slight_smile: .

Thank you for looking into it!

4

Hey again,

I can confirm there is an issue with large transfer sizes.

image

Used your config settings and started bridge with a “loopback” between TX and RX.

Using RealTerm sent 10 characters at a time, repeating 10-120 times (1200 characters per write) was ok. At 1400 continuous characters I experienced the lock up.

    while(true){
        char c;
        if(rx_fifo_try_get(&c)){
            uart_putc_raw(M_UART_PORT, c);
        }
        if(uart_is_readable(M_UART_PORT)){
            c=uart_getc(M_UART_PORT);
            tx_fifo_put(&c);
        }
        //exit when button pressed.
        if(button_get(0)) break;
    }

The bridge function is simple. My guess is one of the queues isn’t getting emptied in time, core 0 freezes while waiting for a queue slot, then the incoming queue fills and the usb buffer overflows.

The only immediate work around I can think of is to introduce some delay every 1200 or so characters, but I understand that is not reasonable in a lot of situations.

I will need to do some additional research on the UART peripheral and run this under debug to find a complete fix. I’ll keep you updated.

5

Thank you for looking into it!