Firmware development updates

I tried my rev8 BP and it works. I noticed the SPI speeds were different (400 vs 100). I’m going to copy the config file from my BP8 to my BP10 and try that.
Hmm. Just did. Same jig. Same commands. My BPrev8 works and the BPrev10 doesn’t.
It passes selftest.
Incidentally, if I try selftest after the “w” and “P” command it fails. The second time it passes.

Update
One of my chips works fine on my rev8. A second does not. I get

PI> (1)
Probing:
		Device ID	Manuf ID	Type ID		Capacity ID
RESID (0xAB)	0x14
REMSID (0x90)	0x14		0xef
RDID (0x9F)			0xef		0x40		0x15

SFDP (0x5A): not found
SPI> flash
Flash device manufacturer ID 0xEF, type ID 0x40, capacity ID 0x15
Error: SFDP signature error. It must be 0x50444653 'SFDP'
Warning: Read SFDP parameter header information failed. The SPI_FLASH does not support JEDEC SFDP.
Found a Winbond W25Q16BV flash chip (2097152 bytes)
Flash device reset success
1 Like

Thank you so much for the additional info. This is seeming really weird.

Self-test should only be limited to HiZ mode with everything off. That might cause this. It seems the prohibition on running in other modes is not working at the moment. I’ll push a fix.

W25Q16BV

I pulled the datasheet and this chip does not have SFDP parameter tables. Instead, the flash library recognizes it from the RDID 0x9f command and knows how to program it.

As to why rev8 works and rev10 fails - I have to guess a hardware failure because I’m not seeing this on any of the REV10 boards here, but I will do some more testing with this hint in mind.

ETA: your settings look fine to me. Anything 12.5MHz and lower should work.

End of command line input: pos1=0, c=0HiZ> command 1; command 2&& command 3||
Command start: 5, end 40
Command length: 35
Got end of command: ; position: 14,
Got end of command: && position: 25,
Got end of command: || position: 37,
End of command line input: pos1=0, c=0HiZ>
Command start: 40, end 41
Command length: 1
End of command line input: pos1=0, c=0HiZ>

Taking another stab at getting the command line parser into better shape. I tried last week but didn’t like the result. I think I’m getting close though. If it weren’t for the atomic dual core USB stuff and all the circular buffers and queues we could use something off the shelf.

Sorry for the slow updates here. The command line is tricky and I’m juggling it with shipping and another big production batch.

HiZ> flash -h
usage:
flash [init|probe|erase|write|read|verify|test]
[-f ] [-e(rase)] [-v(verify)] [-h(elp)]
Initialize and probe: flash probe
Erase and program, with verify: flash write -f example.bin -e -v
Read to file: flash read -f example.bin
Verify with file: flash verify -f example.bin
Test chip (full erase/write/verify): flash test

read, write and erase flash chips using SFDP info if available
init Reset and initialize flash chip. Default if no options given. flash
probe Probe flash chip for ID and SFDP info. flash probe
erase Erase flash chip. flash erase [-v(erify)]
write Write file to flash chip. flash write -f {file} [-e(rase)] [-v(erify)]
read Read flash chip to file. flash read -f {file}
verify Verify flash chip against file. flash verify -f {file}
test Erase and write full chip with dummy data, verify. flash test
-f File flag. File to write, read or verify. flash verify -f {file}
-e Erase flag. Add erase before write. flash write -f {file} -e
-v Verify flag. Add verify after write or erase. flash write -f {file} -v

the flash memory programming command help menu. Usage is very git like:

flash write -f example.bin -e -v

Write file example.bin, erase first, verify erase & write.

This uses the latest command line optional arguments parser that has the ability to scan within the current user input for strings or numbers based on position or -flag.

The new command line optional argument parser appears to be in good shape for now. The previous system was still attached to the Bus Pirate v3 idea that we could only parse user input going forwards.

Previously we controlled the command line read pointer at the base level, any read from the buffer advanced the pointer. It was a one-way street with a mess of handling functions all over the place.

bool cmdln_args_find_flag(char flag, command_var_t *arg);
bool cmdln_args_find_flag_uint32(char flag, command_var_t *arg, uint32_t *value);
bool cmdln_args_find_flag_string(char flag, command_var_t *arg, uint32_t max_len, char *value);
bool cmdln_args_uint32_by_position(uint32_t pos, uint32_t *value);
bool cmdln_args_string_by_position(uint32_t pos, uint32_t max_len, char *str);

The new functions scan over the whole buffer looking for strings, integers, and -flags. Five pretty easy to understand functions extract command line arguments from within mini programs like the flash command.

Still no push. There’s still a TON of cleanup to get everything else in the firmware using these commands, but this is a really big improvement. I’ll try to get it out today.

The latest firmware has the new parser and updated flash command. Please let me know if you find anything that doesn’t work, it’s a ton of updates.

Use previous settings?
UART speed: 115200 baud
Data bits: 8
Parity: None
Stop bits: 1

y/n, x to exit (Y) > x

All modes now have the pretty y/n default settings prompt with for yes or x for exit.

image image

Fixed a bug in I2C mode where the speed setting was not used by the PIO SDK I2C example. Verified at 100khz and 400khz. Removed option for 10bit mode temporarily because the SDK I2C example doesn’t support it. The I2C mode general weirdness seems to be the the clock stretching bit of the PIO code. I don’t have an immediate fix for that, maybe a option during setup in the future. I will rewrite this PIO program in the nearish future.

I don’t have much time left today, but I’m going to see what progress I can make on 2-wire mode and SLE4442 smart cards.

Tomorrow will be SPI cleanup and digging into SPI binary support for programmers, JTAG, etc.

1 Like

image

The latest firmware has a 2WIRE mode for generic bidirectional 2 wire buses with open collector outputs. Macro (1) performs an Answer To Reset for ISO 7816-3 chip cards like the SLE4442/SLE4428.

Major updates/fixes to bit inversion for MSB/LSB read/writes (l/L command). LSB currently only works in 2Wire mode (needed for SLE4442 chip cards), but will be implemented everywhere now that it is tidied up.

The bit inversion command | also got a rework and seems to be functioning correctly now.

Got a bit side tracked with some internal fixes. Library updates and updates to dummy command this weekend, then I’ll dig into SPI next week.

1 Like

Great progress Ian Sir. Keep up the good work.

2WIRE mode is implemented. It is the first mode in BP5 with bitwise commands, and it is so good! The PIO lets us manipulate pins despite being a hardware peripheral. I look forward to implementing this in the other modes.

image

The latest firmware implements the concept of “mode specific” commands.

  • “Global commands” work in every mode (with the exception of maybe HiZ mode)
  • “Mode specific commands” work only in one mode. The command struct for mode commands is tucked neatly in the mode .c source file, to avoid dragging headers all over the place.

In this example, I’m adding an SLE4442 chip card utility, which is only useful in 2WIRE mode. It is only available in the 2WIRE mode, and it’s presence doesn’t pollute the other mode namespace.

Hopefully a push with the SLE4442 utility tonight. Tomorrow I’ll add a new command line float value parser, then clean&rework W (power supply) command and the bio buffered IO commands. I’ll add examples to the dummy command for using the new psu and bio libraries.

1 Like

image

Mode h help command now shows any available mode apps. This list is generated automatically from the mode apps struct so it will stay current.

image

While walking to the market I was thinking about moving the 1-wire and I2C address search macros to a mode-based scan app. Then it occurred to me that we can reuse the macros as actual user assigned macros.

SPI>macro 1 [0x30 0 0][0x31 r:4]
Macro 1 saved
SPI> (1)
Macro 1: [0x30 0 0][0x31 r:4]
SPI>

A macro assignment/recorder app saves the macros to the mode json configuration file.

I suppose we could load them to ram on mode start, or cache them as used, or just be slow/lazy and run them straight from storage.

Since a bunch of Bus Pirates have shipped, I’m trying to give the code a quick cleanup. All the current mode “macros” and global commands are being moved to the new system.

While I move everything over, I’m pulling the hardware logic from the UI logic. The hardware logic is going in a folder /pirate/ and will become “libpirate”, a library for using the Bus Pirate hardware from other firmware (such as the logic analyzer ports and JTAG debugger ports).

I’m also documenting every library in the dummy.c command template .

>W 3.3
>W 3.3 100

The first update is to the power supply W command. It now accepts two trailing arguments: voltage and current. If no current is given, no limit will be set. If no arguments are given, the typical menu prompts are displayed.

1 Like

image

Does this kind of help menu make sense? I’m updating everything using the new help system as I go.

3 Likes

About half of the commands are ported to the new system and have advanced help available with the -h flag.

I added a bit of extra info when jumping to bootloader. It knows the hardware version and presents a link. I think that might be handy, we had a question on twitter about what file to use with a board.

Currently working to clean up the ?/h/hd stuff. Help will be more advanced with options, filters, and maybe search.

Evidently I broke the scope mode with the command line updates. I will get that fixed too.

For better or worse, the show stopper bugs are worked out and I’m going to push updates as I make them.

There are bound to be bugs, please let me know if you find any.

Check out the new help:
-?/h/help - all give access to help system
-?/h/help mode - show mode help
-?/h/help -h - show help help

2 Likes

Big push on the way. I am deep in the rework/cleanup. You can see it taking shape:

  • /pirate/ folder with all the base functions for interacting with the bus pirate hardware
  • /commands/global/ and /commands/<mode> hold individual source files for the various bus pirate commands.
  • try the -h flag with commands for the extended help menu (see list below)

Quite a bit of progress, but still a day or so to go. Today’s updates:

  • disk commands (cd/ls/mkdir/rm/format/cat/hex)
  • a/A/@ aux pin control
  • | = conversion commands
  • # $ system commands
  • self-test (big cleanup here)
  • dummy command
  • help command (try ?/h/help for general help, ?/h/help mode for mode specific help
  • added mode help to HiZ mode
  • l/L bitorder setting
  • p/P pullup resistors
  • pause
  • w/W PSU. Try W 3.3 or W 3.3 100

New Help

image

? or h or help show the general (global) command list/help

image

Add the key word mode to see mode specific help. This combines the oddly weird ?/h dual commands.

image

Of course if you forget or need a hint, the help command accepts a -h flag that explains how to use it.

It would be nice to get the display mode help in here too, but I will need to study that a bit more.

1 Like

This new structure is a great improvement. I am amazed at your energy, Ian. I have a small suggestion if you don’t mind. After typing “h -h”, I was momentarily confused by the response

HiZ> h -h
usage:
?|h|help [global|mode] [-h(elp)]
Show global commands: ?
Show help and commands for current mode: ? mode
help for Bus Pirate commands and modes
?/help Commands to access the help system
global Show global command list, default option
mode Show mode specific commands and help
-h How to use the help system

At first glance, I thought there were command “global” and “mode” commands because I am used to looking at the end of a message. (the help page scrolls out of sight a lot)

It’s the line

help for Bus Pirate commands and modes

I know the first line shows these are arguments, but beginners may have first time confusion as they learn their way around.

Something like

Append these arguments to get more help

And you could give examples like

? help - Commands to access the help system
? global - Show global command list, default option
? mode - Show mode specific commands and help
? -h - How to use the help system

Another suggestion.Since “h”, “help”, and “?” are synonyms,
may I suggest you use just one as the standard, but you accept all three?

it might be confusing to some when you say “?/help” in the help menu. Are they different? Perhaps the top level response could be (I’m having trouble putting in tabs)

get more help
? - This message (“h” and “help” can also be used)
? {option} - Detailed help, type “? ?” to see options
{command} -h -Additional help for command

And instead of “hd” use “? display”

2 Likes

Thank you for having a look. I agree with you, and also find it a bit confused myself.

Append these arguments to get more help
And you could give examples like
? help - Commands to access the help system
? global - Show global command list, default option
? mode - Show mode specific commands and help
? -h - How to use the help system

I will add something like this.

The thing is, “global” doesn’t actually do anything. It was just there for consistency. the mode modifier is what matters - so maybe there’s an easier way to represent it without that.

The combined ?/h/help is a nightmare. I don’t include them in the options menu because it’s too long and breaks the tab :rofl: What would the “standard” be? I’d like to keep ‘?’ because it’s Bus Pirate classic. I could care less about ‘h’ :slight_smile: help i kind of like.

And instead of “hd” use “? display”

That will happen, but I didn’t write that code and I need to poke around and see how to intercept the help.

All good comments, and all stuff also on my mind as do the cleanup. The nice thing is all these commands are cleanly separated and have their own files now, so making changes will be a breeze going forward. For example here is the help for help.

That’s probably my last push for the day. There is sun light for the first time in months and I need to touch grass while I have the chance.

Unless there are some special requests, I’m going to proceed like this:

  • v/V command (command is simple, but I need to overhaul the entire analog mux system and update everywhere in the code that uses voltages)
  • shift register library (this includes making simple facade functions for things controlled by the shift registers, and updating everywhere in the source that uses it)
  • amux library - this controls the analog mux. either measuring a single pin, or “sweeping” the range and updating variables with a measurement from each. amux uses shift register, so there’s a lot of interaction between these first three items and they really do need help if anyone but me is to understand how it all goes together.
  • Install command and help system in all modes
  • flash command->spi mode flash command install.. Check non-SFDP flash handing,
  • 1-wire scan - move to mode command, check the device library and make the colors pretty like I2C
  • I2C scan - move to mode command, this will also be good for the verbose mode that attempts to identify the chips.
  • I2C, 1-wire - move other device demos to mode commands. tame the disgusting pile of spaghetti code that is I2C
  • All protocols - move hardware interfaces to simple basic libraries in /pirate for reuse
  • Scope - new scope command why is is not getting commands? Find out how to move display mode help to the new help command “help display”
  • measure freq/generate freq. My two least favorite bits of the code will get the treatment last.
  • Update pacman status indicator to work right when file size or chip size mismatch
  • logic command - install as global command

I image this is 2 maybe 3 more days of code rework. If you have a priority please let me know and I will work on it, dependencies allowing.

3 Likes

Love the new PSU command. I’ve been using the BP5 recently to experiment with the cutoff values of different battery protection chips (I.E. if battery drops below X volts, disconnect the load), and being able to give voltage on the command line is a big time saver if you’re trying to make multiple small changes like 3.0-2.9-2.8, etc.

Does look like there might be a bug as of the latest (407ff95) firmware build though. Seems like whatever value I give for the current always returns an error the first time I try to turn on the PSU, but works as expected after that.

While on the subject of the PSU, I always see that 1.7 to 1 .9 mA current even when nothing is connected. If that’s expected behavior (internal consumption somewhere in the circuit), would it be possible to add an offset so the display reads zero? Potentially something user-configured, if that value is not relatively stable across hardware variations.

2 Likes

I’m glad you’re enjoy the supply. I am a big fan of the trailing arguments too, it makes it so easy.

The PSU should be working now. There was a bit for current limit enabled that was inverted during my cleanup. I added a != and we’re good to go now.

There is some base level of current because the current sense resistor is the first thing in the power supply. It measures leakage through various places, the current consumed in the VREG, current consumed by the buffer chips, various pull-downs, etc. There is also some offset in the op-amp too, and the RP2040 ADC is slightly dodgy I’ve read.

Since sketching out the design for the PSU I’ve intended to have a calibration routine to set exact top and bottom values for voltage and current, and save it to storage. Now that we have options and arguments this can be added to the W command (W -c?). Since we’re using the cheap-o Diodes INC vreg instead of the impossible to source and expensive Microchip part, the resistor set values are really odd and there’s a bit of slack at the high and low range in the VREG margining circuit. I’ll look at this after the current re-org.

Nice that you have only 1.9mA standing current, I usually have around 2.4. I guess this is the difference in offset of our opamps and current sense resistor tolerance. Production boards are built with a higher quality ‘A’ grade op-amp in the current sense circuit, my board may not actually have that upgrade :slight_smile:

2 Likes