I have hard time to find the purpose of second tty device after connecting buspirate. Is it compatible with legacy Buspirate ? I’ve attempted to set SPI mode and pass second TTY to flashrom but nothing happends. Whatever protocol is supposed to be ther maybe we can add some feedback on the first terminal interface, by side of voltages displayed to inform what is the interface mode and state ?
The first interface is ASCII interface the second is binary. But this depends on the mode.
SPI doesn’t have a bridge mode. It has a built-in “flash” mode to read and write. I’ve used flashrom with other boards (i.e. tigard, Bruschetta, etc.) But not with BusPirate.
And yes - BusPirate’s ability to read flash is much slower than the hardware-based boards.
The binary interface is used for a logic analyzer function (sigrok), and the HDPLXUART mode.
I haven’t used the UART bridge mode, but I think it that case is uses the first interface - so you have to disconnect your terminal interface program, and connect your application to the first interface.
Have I got that right?
I should point out the original BusPirate (V3) only had one port, therefore the UART bridge mode switches between text and binary.
I think V10 does the same thing - for compatibility with the old BP? It does seem slightly inconsistent, if you assume interface 1 is commands and interface 2 is direct/application.
Not sure that is correct, my testing with HDPLXUART is using the text interface. But that does suggest that using the binary interface, second serial over usb might be good for anything that goes bridge mode, leave the text interface for command mode. No longer need to use button to exit bridge.
So honestly I don’t see a point in switching single UART between binary/text for compatibility - whatever way it was implemented in legacy version we can still use dedicated UART in compatibiltiy mode. At the same time keeping the master UART for Buspirate UI . Unless the reason is computing power/multiplexing resources but then master UI can just be paused with appropriate information printed right before.
Going forward to SPI usecase - this is implemented similar way in Flipper Zero which works with some SPI flash chip BP has hard time even to identify. The problem with ‘standalone’ mode which Flipper has and BP tries to implement same way is that you are reading data over slow protocol and then transfer it over also slow emulated USB storage. Just for reading some roms it’s acceptable but sometimes you don’t want to use only read/write full dump options for SPI flash. Sometimes you want to read, write particular bytes to particular offsets(pages) with some state of the art software or python script on host computer when interfacing with some device you are not yet familiar. Having to adapt to BP firmware everytime for this or using interactive commands is IMHO overkill both from development effort and time spent on particular project tested with BP. If it’s main role is interface, let it be interface while nice standarole features could be just a convinience add-ons.
1 Like
The second UART is for the binary mode. The previous Bus Pirate had a shared single UART and it was kind of a mess getting in and out of the terminal and binary modes.
I started a “compatible” binary mode, but all the software that supports the old Bus Pirate seems to have a lot of bit rot. So, instead of resurrecting an old mess that isn’t actually compatible with anything, I want to design something really nice that will be usable and stable over the long term.
This is something I prepared for some weeks ago when I reworked all the protocol and base stuff into reusable libraries.This week I am working on the binary mode, specifically SPI, to get going with flashrom, JTAG, and some other utilities.
Can I have the part number for chips the bus pirate can’t identify? We’re using this open source universal serial flash library:
1 Like
Sorry I wasn’t clear enough. By ‘identify’ I mean not the process of matching manuf code etc, but detecting those at all- gettng any response from chip at all. The chip is Dell SPI Bios Flash ‘in vivo’ of unpowered mainboard PCB . I don’t have exact memory marking but the vendor is XMC, 256Mbit, . it’s supposed to work with 1.8V as well as 3.3V . Flipper is able to talk with it every time while BP hardly. I’ve got it working few times after enabling Pull ups ,setting voltage to 1.8V (after patching with Fix for proper reading and threshold value of VRef in SPI flash mode by nuschpl · Pull Request #30 · DangerousPrototypes/BusPirate5-firmware · GitHub ) and freq to 50kHz. But it’s not always reproducible. I bet some cross talk might be present over 40-50cm cables , but this is not happening with Flipper Zero with same setup WSON 8x6mm pogo pin probe + same length of cables.
That’s interesting, intermittent reading with in-circuit chip. My guess would be that there is a load somewhere in the circuit that is preventing a proper high level due to the protection resistors on the Bus Pirate IO pins. There were several trade-offs between high power IO and a sane current limit that doesn’t blow out a pin on a DUT when inevitable mistakes are made during prototyping. I will see if I can get an old mother board and try it with a scope to watch what happens.
I accepted your pull request, however amux_sweep(); needs to be run to update the analog voltage values. Would you please let me know if this is still working for you after this change? I pushed to main, and a compile should be available shortly.
I was wondering about that if I need to poll for those values first but it was working, is there a chance this is called by some other logic after PSU was powerd on ? Like display/tty measurements update logic ?
The PSU calls it several times to produce error codes. So you are probably safe, but it doesn’t take but 60us so we might as well be super sure.