Hi, I am using the rev 10 buspirate 5 with firmware 0df8700 FROM 10th of january.
Using this its unable to switch to oscilloscope mode.
After entering number 2 for scope display selection in the terminal it gives me the message
“Error: the big buffer is already allocated to #0couldn’t allocate 64256 bytes, scope mode broken”
It would bei great if this could be fixed,
or anybody could point me to an older firmware where this bug hasn’t existed before.
Thanks in advance
I will try to see why this is happening.
For a working firmware, scroll back to maybe February of last year when the scope was first added.
Ian, sorry I didn’t notice this earlier (I’m happy to fix bugs, please poke me when appropriate) - I downloaded the latest bp6 60c6197 build and it seems to work OK for me, we probably need to make some minor changes to the readme (because the mode numbers have changed) - I’ll send you a pull request
Ian - I’ve queued a pull request - 2TR can you tell me if scope mode works for you on the latest official BP software release - new scope.README.md is attached
scope.README.md.txt (5.2 KB)
Hi Paul,
Thank you so much, no worries.
You wrote this way early when the firmware was just starting out.
Shortly after I added a command line arguments parser. I attempted to create a scope command to bring scope in line with the other commands, but I wasn’t very successful. If the original methods of using scope still work, that is fantastic news. I will update the online docs with our updated info.
There are two things related to scope on the horizon.
Hi there,
i just checked the new firmware (ci-buspirate-main-c02f0c9.zip)
with bus_pirate5_rev10.uf2 and the error persists.
It still gives me the output message, that the mode is broken, when i select oscilloscope mode:
"
Display selection
OK I tested it on the BP6, I’ll try it on a 5.
Are you doing anything else at the time (running a logic analyzer?) essentially there’s not a lot of RAM built in to the RPI chips, different features have to share …
It’s past bedtime here in NZ I’ll have a look in the morning
No i ran it freshly after updating the new firmware.
I connected it via usb, ran my terminal (entered a few times an sequence to check for the device´s presence and then i entered ‘d’ for device mode, folllowed by ‘2’ for scope mode.
This is the output, the ‘i’ (info) command provides.
Hope this helps.
Bus Pirate 5 REV10
Firmware main branch @ c02f0c9 (Mar 27 2025 10:39:47)
RP2040 with 264KB RAM, 128Mbit FLASH
S/N: (redacted) 
Storage: 0.10GB (FAT16 File System)
Configuration file: Loaded
Active binmode: Follow along logic analyzer
Available modes: HiZ 1WIRE UART HDUART I2C SPI 2WIRE 3WIRE DIO LED INFRARED JTAG
Active mode: HiZ
Display format: Auto
I noticed by myself that the device binmode was initially set to “follow along logic analyzer”. I set it to " SUMP logic analyzer" and now the broken oscilloscope mode does not break anymore.
Ah - that would explain it - Ian: this needs documenting somewhere (I’m not sure where any ideas?)
Thank you both for the debug.
When FALA is active the big buffer is owned by FALA. Similarly, when SUMP mode is active, and the SUMP port is open and the logic analyzer is configured to capture the big buffer belongs to SUMP.
I think major error here is that the big buffer warning is not properly descriptive. I will update that.
Yesterday we began to receive the new framework for the docs, it should be done in a few days. Then I am doing a 100% update and refresh of the docs. I will include warnings and notes about the buffer sharing wherever relevant.
The Bus Pirates based on RP2350 have twice as much ram, so in theory the buffer wouldn’t need to be shared. However, there may not be enough DMA channels/fabric to run both at the same time (at high speeds…?).
@phdussud has a pending pull request that may reduce the DMA channels needed by the LA from 6 (7?) to 2. I’ve followed up on that because I’m uncertain if that works on RP2040 or just RP2350.
@ian I have developed the code and tested it in isolation on a RP2040 board so yes it will (should) work on a BP5. I tested it integrated in a BP6 (latest version). Another bonus is that the buffer has no alignment constraint.
Thank you all
/*Words words */
I was thinking on changing the error message to describe what someone should do (rather than why it’s failed) - what are the commands that someone would use to turn off FALA/SUMP?
Yes, I’m half way there.
Then it should be a lot clearer what the error means.
OK I’ll let you do it … thanks