dangerousprototypes/buspirate5-firmware

Bus Pirate v5 Firmware

buspirate5-firmware's Issues

Use MicroPython for full flexibility

Hi,
when the buspirate was introduced, running on an PIC uC. The software landscape for microcontrollers was still pretty much C...

However, now we have tools like MicroPython. As I used both projects intensively I always dreamed of having a buspirate running MicroPython as "OS".
This would enable users to rely on a complete programming language. In an interactive session you could easily define functions which set-up the buspirate, define the protocol, send initialisation code, request or send data, even very complex scenarios, etc.

Furthermore, with the help of the vfat memory (something the buspirate and MicroPython have in common), the community could build up libraries for all kind of chips. Within individual MicroPython files the entire communication protocol can be embedded and the buspirate can provide functions to test chips on different levels, from bit-by-bit up to a single high level read_sensor() command.

Yet other libs can be more generic, dealing with byte-juggling, formating, filtering, searching, fault detection, etc.

For me, that would be a perfect combination of two great projects

Missing NACK when reading in I2C mode

Reading I2C eeprom (24C64) content last byte before stop is ACKed instead of NACKed.

Steps to reproduce:

1. Switch to I2C mode
2. Connect eeprom
3. Enable power, and pullups
4. Execute command: [0xa0 0x0 0x0 [0xa1 r:10]

Actual behavior:
Last read byte is ACK instead of NACK

I2C START
TX: 0xA0 ACK 0x00 ACK 0x00 ACK
I2C START
TX: 0xA1 ACK
RX: 0x00 ACK 0x00 ACK 0x00 ACK 0x00 ACK 0x00 ACK 0x00 ACK 0x00 ACK 0x00 ACK
    0x00 ACK 0x00 ACK
I2C STOP

Expected behavior:
Last read byte is NACKed

I2C START
TX: 0xA0 ACK 0x00 ACK 0x00 ACK
I2C START
TX: 0xA1 ACK
RX: 0x00 ACK 0x00 ACK 0x00 ACK 0x00 ACK 0x00 ACK 0x00 ACK 0x00 ACK 0x00 ACK
    0x00 ACK 0x00 NACK
I2C STOP

I suspect that hardcoded bytecode is a problem in line:

BusPirate5-firmware/mode/hwi2c.c

Line 137 in 0a5dc67

bool ack=(next?(next->command!=4):true);

Use constants from bytecode.h instead.
Both
https://github.com/DangerousPrototypes/BusPirate5-firmware/blob/main/bytecode.h#L50
and
https://github.com/DangerousPrototypes/BusPirate5-firmware/blob/main/bytecode.h#L52
should be accepted

Workaround:
Use START_ALT syntax { just before stop to trigger NACK on read:
[0xa0 0x0 0x0 [0xa1 r:10{]

Choosing non-standard SPI options freezes upon config recall

Hi there,

I'm currently trying to get a chip working that has idle high clock and trailing edge (so SPI options Polarity 2, Phase 2). Entering this mode after choosing these options works fine, but if you exit the mode and try to re-enter it, the Bus Pirate completely locks up here:

Mode > 6

Use previous settings?
 SPI speed: 1250 kHz
 Data bits: 8
 Clock polarity: 

The only solution is to delete the bpspi.bp file from within the Bus Pirate interface (removing it via the USB drive that appears doesn't seem to work, the file just re-appears after replugging -- possibly a separate bug?).

Steps to reproduce:
Open serial terminal
Hit m to choose mode, followed by 6 for SPI
Chose the options as follows: clock (doesn't matter), data bits (I've been choosing 8), Polarity 2, Phase 2, chip select 2 (active low)
Unplug the Bus Pirate OR use m to go to Hi-Z mode
Re-enter SPI mode and the entire board will lock up, not responding to any commands until after a power cycle.
I am using firmware built on commit 87b1d8c

Different value of current current on Buspirate display and TTY

When changing values of voltage with W option within SPI mode I see current draw arround 3-5mA in terminal and arround 200mA on display, both are constantly changing. It probably doesn't clear leading digits on screen as the value could be like 203.5ma on screen and 3.5mA on TTY and second digit on screen also changes when draw ramps for a while over 10mA.

Not able to power SPI flash with 1.8V

I'm not able to power SPI with 1.8V in way that I can further proceed with SPI operations:

SPI> W
Power supply
Volts (0.80V-5.00V)
x to exit (3.30) > 1.8
Maximum current (0mA-500mA), <enter> for none
x to exit (none) >
1.80V requested, closest value: 1.80V
Current limit:Disabled

Power supply:Enabled
Vreg output: 1.8V, Vref/Vout pin: 1.8V, Current: 84.4mA

SPI> flash probe

Error: No voltage detected on VOUT/VREF pin
Hint: Use W to enable power, or attach an external supply

There is no issue with 3.3V. Is it software or hardware limitation/issue?

I2C Device Address in Search Macro

On BP3, the I2C search macro would show the 7 bit device address in parenthesis next to the 8 bit read and write addresses:

Running the search macro on BP5 against the same device only returns the R/W addresses and not the device address itself:

Looking at the printf line in hwi2c.c, this appears to be intentional and not a bug.

BusPirate5-firmware/mode/hwi2c.c

Line 480 in 0da7c47

if(!ack) printf("0x%02X(%c) ", i, ((i&0x1)?'R':'W'));

I would propose that showing the base device ID in the search mode, while not technically necessary, makes for a more predictable experience as users will likely be more familiar with referencing the device in their code by the 7 bit address.

Current limit prompt locks up UART

Was trying to enable the power supply in DUMMY1 mode.

DUMMY1> W
Power supply
Volts (0.80V-5.00V)
x to exit (3.30) > 
3.30V requested, closest value: 3.30V
Set current limit?

At that point, I get a line break, and then any characters I type are at first echoed back in the first column, but after typing a few characters they start to be echoed back normally (each character moving the cursor forward). However, the RETURN key does nothing, and the system seems totally locked up until I unplug and replug the USB connector.

What is the prompt expecting -- a Y/n or a numeric value? Is this intended behaviour or is this a bug?

EDIT: Just tried the same thing in I2C mode, having the same bug. I haven't updated the firmware since receiving the device -- not sure if it supports me just dragging and dropping the .uf2 file like with other RP2040-based systems? I will try that now with the main branch which I built earlier today.

Broken BBIO mode

Can't enter BBIO mode.
It looks like this commit broke it: 3ac0351

BBIO mode is unusable.

Building under Windows?

Is there any specific instructions for building under Windows. I have the PICO SDK 1.5.1 install already.

Thanks!

Enable the GitHub "Wiki" and "Questions" sections

It would be nice to have the documentation coupled with the source code here. Additionally, I think there is another feature called "Questions" or something like that. It's a good place for people to ask questions about the project without opening an issue (which is often the only way to talk to the developers).

As far as documentation goes, I'd be happy to help out in that area but I'm not sure what's already been done or where it's hosted so far? Or maybe there isn't anything yet?

Help does not fit on screen

Typing h to get a list of commands scrolls of the top, so the full list of commands cannot be seen - even whgen using a very large window:

Use macro string ids instead of int

It'd be nice, backwards compatible and from what I gathered from the code easy to implement string ids instead of integers.

instead of macro 1 we could do macro get_status

thoughts?

Colours do not come out as shown in tutorial

Using a an ANSI colour compatible terminal with VT100, I get some colour, but nothing like that shown on the tutorial pages

Build failed on MacOS 14.4, Apple Silicon

The Cmake passed, while make filed at this stage:

[ 28%] Building C object CMakeFiles/bus_pirate5_rev8.dir/fatfs/ffunicode.c.obj
[ 28%] Building C object CMakeFiles/bus_pirate5_rev8.dir/translation/base.c.obj
[ 29%] Building C object CMakeFiles/bus_pirate5_rev8.dir/mode/binio.c.obj
[ 29%] Building C object CMakeFiles/bus_pirate5_rev8.dir/mode/binio_helpers.c.obj
[ 29%] Building C object CMakeFiles/bus_pirate5_rev8.dir/mode/logicanalyzer.c.obj
/Users/User/src/BusPirate5-firmware/mode/logicanalyzer.c:13:10: fatal error: build/logicanalyzer.pio.h: No such file or directory
   13 | #include "build/logicanalyzer.pio.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/bus_pirate5_rev8.dir/build.make:1308: CMakeFiles/bus_pirate5_rev8.dir/mode/logicanalyzer.c.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:1560: CMakeFiles/bus_pirate5_rev8.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

Building under Linux - illegal character

I had a minor issue while building the firmware on a Linux system.
When compiling the *.pio files there was an illegal character error on some of the #defines
I checked, and these files had at the end of each line.

I solved the problem by typing

sudo apt install dos2unix
dos2unix *.pio