Just my $0.02 – I am also observing 2.9 to 3.1 mA current with cables disconnected. Funnily enough, having an SPI flash or 8 pieces of pca9555 chained up on i2c and powered from bp5 does not make much difference on the current consumption. Not that it should, though. 
2 Likes
When programming a big winbond chip I did see the current spike. It was pretty cool. Probably we should have some averaging in the current measurement, but it only happens every 500ms at present.
1 Like
Yeah, it’s obvious that flash programming takes a wee more current, compared to minimal consumption while reading. That’s why fast NVMe ssd disks get very hot during sustained writing.
1 Like
Big progress today, but while reworking the amux and shift libraries I introduced a nasty bug into the power supply (which is tightly tied to both). I’ll push to a new branch, but there won’t be a new firmware until I find that bug.
Updates:
- v/V command reworked into command system
- amux, shift, RGB, lcd function libraries
- Installed new help system and mode command system in all modes
- flash command installed in spi mode flash
- Scope move display mode help to the new help command “help display”
- Detect firmware and hardware mismatch, blink red and do not continue
- No power at buffer warning help function
- Removed flicker from continuous voltage measurements
- info command ported to global command system.
I hoped to get a little further, but I lost a lot of time trying to fix the power supply bug.
New items:
- Install no power at buffer warning in all relevant commands
- move ui_info_error to ui_help_error
3 Likes
Huge update just pushed. Almost all commands have detailed help. The PSU is reworked and really solid - there was a concurrency issue with both cores accessing the ADC. I added a spinlock and everything seems fine now.
A lot of the improvements are under the hood. Tons of spaghetti code has been moved into clean libraries in /pirate/ and most commands are neatly contained in the /command/ folder.
Some notable updates:
- Mismatched hardware and firmware (REV8 preview board and REV10 production boards) is now detected and the Bus Pirate will flash red. Hopefully this sames some frustration.
- All modes now have mode help (? mode) that lists available mode commands. There’s only a few now, but there will be a bunch more by the end of today.
- Try “? display” for display help (scope mode). "hd’ is no longer a supported command.
- just about everything has extended help with the -h flag.
- New convenience functions for handling help in modes and commands. see /command/global/dummy.c
Now I’m going to start in on the modes, and adding no voltage warning to everything.
3 Likes
I2C cleanup in progress. The address scanner is now moved to a mode command instead of a macro.
scan
For a normal scan
scan -v
For a verbose scan with lists of part numbers.
scan -h
And of course a help display.
I need to move the rest of the “macros” to commands, and then I’m going to rework the PIO script a bit. I know @grymoire was having some issues with I2C, and I tracked it down to the clock stretching. I’ll make clock stretching optional, I think for most people it’s not useful in a prototyping environment.
2 Likes
The three sample device demos have been moved to mode commands. I kind of feel like the macros were more intuitive, but this way we can have help and options.
demo si7021
Maybe instead there should be a demo command with arguments?
I did not take out the clock stretching yet, I want to see if anyone objects strongly.
I’m going to try to clean up 1Wire and UART modes yet today. In 1-Wire I’d like to add a verbose search/scan that also processes any device it finds (temperature reading, dump eeprom, etc).
1-wire is almost done. For some reason I tackled the useless version and unknown hash issue. Hopefully it looks like this now. I’m pushing to see if it works on the compile server too.
1 Like
I am wondering if commit hash is not better than date…?
Because commit points directly to particular version and date you have to additionally lookup. Or maybe both?
1 Like
1Wire almost done. Then I’m going to see if I can get the scope working again.
@AreYouLoco oh, it defo is better. All the infrastructure is there for it too, but it will take half a day to rework my build server script to pass it. I thought for now, this is better than “unknown” 
2 Likes
Updated UART mode. The GPS NMEA packet decoder and transparent UART bridge (usb to serial mode?) are now commands with help. There is a new reusable “VOUT unpowered” notification help function in both, I’ll spread that everywhere eventually.
Next up LED, then I’m going to hack at the scope a bit more. The major rework should be finished tomorrow with SPI, that’s gonna be a huge cleanup.
ETA: LED doesn’t have any commands/macros, so it was easy to update. I hope someone makes some awesome eye candy commands
I started a new scope command that wraps all the scope functionality into a single command:
scope run //change to display mode and start scope
scope stop //pause scope
scope t //configure trigger or enter interactive mode
scope x //adjust X axis
scope y //adjust Y axis
scope exit //reset display mode
It took a bit of rework so it’s not ready yet. There is also some freezing happening, probably during DMA teardown/cleanup.
1 Like
The latest autobuild has a number of little updates:
- SPI mode cleanup, completes the cleanup and “librarization” of bus pirate hardware functions.
- KHz fixed to kHz globally
- additional chips in the flash programmer database
- Fix for dumping flash chips identified by ID instead of JEDEC SFDP tables
1 Like
Just noticed one odd thing while trying the new build.
I’m in SPI mode abd I type help mode. One of the responses is
Available mode commands:
flash Unavailable
Why is it unavailable?
(I don’t have anything connected)
I’ll try more tests later. But I like that when I try to execute flash I get a message that tells me that I need a proper voltage. I always appreciate error messages that not only tell me about a problem, but then tell me how to fix it. 
haha it means the help string isn’t configured. The command is very much available. Thank you for pointing that out, I’ll fix it.
Thanks again. I added the help, and changed the help not defined error message to be less confusing.
I was testing a flash chip, and I disabled power before disconnecting and reconnecting. This is the response. I just want to verify if this is a correct message.
SPI> w
Power supply: Disabled
SPI>
Error: Current over limit, power supply disabled
Seems to be a race condition between disabling the power supply and flipping the bit to turn off the check on the other core. Does it happen every time? I can’t reproduce it, but I can make it more robust based on what I think is happening.
1 Like
The latest firmware has a new half duplex UART mode. This is a single data wire open collector bus that requires a pull-up resistor.
This mode is specifically designed to work with SIM cards with 8/E/2 UART settings. The UART runs in the RP2040 PIO though, and should work with all the same settings as the normal 2 wire UART mode (data bits, parity, stopbits).
You can use this mode to get the ATR from mobile phone SIM cards, as well as debit/credit chip cards.
This week is going to be pretty focused on hardware: shipping the next batch of Bus Pirates, and 5 adapter boards should start production. I’d like to get through this list of fixes though:
- SPI mode flash chip variable not zeroed bug, flash dump unknown chips by range
- Remove I2C clock stretching or make it optional
- Rework BIO library a bit. Test for buffer direction before changing pin IO. New bio2buf and bio2pin functions. Maybe mode system_claimpin to bio
- scope - clean up new command, check freezing issue with Paul, detailed help
- universal power and pullup check helper function, install everywhere
- SIM card query and ATR parser in half duplex UART mode
1 Like
A while back I added this message with a link to the firmware download, the hardware revision, and the name of the file to load.
Has anyone noticed that and found it useful?
Has anyone loaded the incorrect firmware and seen the angry red blinking?
Basically, if you don’t know what your hardware revision is (for example it’s inside a case), then you definitely have revision 10.
Revision 8 is a handful of boards we made for interested developers, it didn’t come in a case and it says “REV8” on the PCB top and bottom. You would probably know if you bought one of these early boards.
This situation still needs some finesse. Maybe rename the files, or put the rev8 in a folder in the .zip. Rev8 could go in a different thread, but that would have it’s own issues. I could just stop compiling the rev8 and replace the boards for anyone who noticed…
There’s an update that links to the latest firmware at the bottom of the forum thread.
With LEDs disabled, the LEDs play for a bit at startup before the configuration is loaded. I’m going to change that to a subtle color coded power up sequence, then move to the saved mode or the default mode if none.
3 Likes