Follow along logic analyzer

image

Bus Pirate 6 uses the RP2350B which has a few extra pins. Some of those make a secondary connection to the IO pins through a buffer chip (U2) to GPIO20…27.

The first step is just to get it going on the new pins with sigrok
- In logicanalyzer.c in logic_analyzer_arm: modify the no trigger program to use either the current base of IO0, or the new secondary GPIO connection.

Which brings up a good question. Is there any point to actually switch between the two methods of IOs? 6 can always look through the secondary buffer. It makes sense to change the setup function to accept a base GPIO and number of consecutive GPIOs to include in the LA.

For use from modes (follow along)

  • A setup function that adjusts the capture speed to eg 4x 8x 16x the protocol bit speed
  • A arm/initi function that doesn’t start the capture
  • A start function to call from the syntax compiler just before output to the bus
  • Stop function to end the capture when output is complete, before the buffer is filled.
  • A function to dump the capture plus empty sample until there is software capable of understanding variable length captures
  • A global logic command that configures the logic analyzer manually (eg you don’t like the auto settings)

Software thoughts:

  • There’s no software support for asynchronous data dumps in sigrok
  • A simple header with each sample dump should contain: channels, capture speed, samples that follow, etc.
  • An auto mode that updates every 30 seconds if no triggers have been detected (like a scope in auto mode)
  • GusmanB has software that may support this, it does periodic updates. I’m more fond of sigrok though because of all the decoders and such

ASCII logic graph:

  • At the top of logicanalyzer.c there’s a messy attempt I made to have a scroll-able logic graph in the terminal. Now that the core opt-args stuff is sorted, that will be a lot easier to clean up.
  • This is probably a horrible but also right time to rework the terminal toolbar. The toolbar should be moved into a clean “toolbox” module. The logic graph will also be a toolbox module. There will be some kind of system for enabling various toolbars that all play well together with the space available in the terminal.

I’ve got a lot of in-progress stuff, but I need to get the first two chunks done this week. When boards start arriving there should be firmware support for anyone interesting in hacking at software.

3 Likes

LA_BPIO0

Added a base pin define for the logic analyzer to all hardware versions. In the 6, this is the secondary buffer. In <6 it is the first IO pin.

Some weirdness: if terminal is open, pulseview won’t connect. Other way around is ok.

Todo:

  • If mode is hiz, enable power supply. If not, don’t. (for 6)
  • Don’t lock the terminal for logic analyzer (for 6)

Happy dance! Setting a trigger on CS and sending some data.

Since the buffers need a power supply when the logic analyzer is used without the terminal, there are some rules:

  • If the terminal is NOT connected or the mode is HiZ, a 3.3volt power supply will be enabled

Again, with a 10% pre-trigger, now we can see the CS pin actually fall.

I pushed these changes, if you have a Bus Pirate 6 any feedback would be motivating :slight_smile:

3 Likes

Not the final product, just a test:

  • Setup logic analyzer before syntax is output to the bus, start capture
  • Send the bus output as normal
  • Halt the logic analyzer
  • Display output as normal
  • Query logic analyzer for number of samples
  • A quick reality check of the last 80 samples (backwards…)

Looks to be coming along. I’m going to push this to an rp2350 branch for the time being.

Protocol

I’m going to add a new binmode with asynchronous “follow along” logic analyzer output. It’s kind of like working with GPS NMEA messages, so my first though is something like that, with all values in ASCII text (or just a binary packet?):

$FALADATA;{pins};{trigger pins};{trigger mask};{edge trigger (bool)}; {capture speed in hz};{samples};{pre-samples (for trigger line)};

Most languages can easily parse CSV. Aside from the trigger pins and mask it shouldn’t be hard to handle.

Then, the client can respond + to dump the current samples as a binary blob.

The trigger stuff isn’t important yet, but it’ll be straight forward to add triggers for more advanced debugging directly from the Bus Pirate terminal. It might be neat if the client can update the triggers on the graph. Adding infrastructure to sigrok for that would be a big undertaking though.

Thoughts? I’ll implement the binmode next.

1 Like

id I say improved DMA? I did! DMA can now do infinite transfers without needing to waste another channel.

I read this. Perhaps the DMA for RP2350 versions can be simplified now?

From an educational perspective, I find this incredibly cool. I’ll use it in my bootcamps to teach students. Thx for this @ian

For it to be truly useful for work, the key is being able to use third-party software to apply high-level protocol filters, take measurements, and do all those things that make a logic analyzer really useful and productive—a good software is essential for that.

Ideally, we could use the Bus Pirate while simultaneously monitoring what’s happening in real-time with software like Logic-Saleae or similar, being able to pause, take measurements, etc.

My goal is to make the experience comparable to when I explain Bus Pirate commands and simultaneously connect the Saleae with an SMD IC clip so students can see what’s happening at a low level for each action (in an intuitive software, with cool features, and easy to use).

If we can’t have real-time monitoring, Please, just use a standard export-format that can be directly imported into PulseView, Saleae (.sal), or similar software to easily analyze the data. If it can’t all be done from the firmware, we could create a Python script or something similar to handle it.

3 Likes

Hi Dreg,

You’re right that integration with PulseView / Sigrok / other software analysis tools multiplies the value. You also mentioned Saleae …

In the past, my understanding was that Saleae did not support importing traces from any other format, and that their own .sal format was closed/proprietary. At the time, this appeared to be core to preventing their hard work (intuitive software) from being used with clone devices. Has this changed? Or, more specifically, is it now possible to create .sal files that can be imported into the current versions of Saleae’s viewer/analyzer (even if some limitations exist)?

This was quite literally the only thing holding me back from picking up one of their devices on an RFID-related project about a year ago … so very interested if their position has changed and the format is now open (or any import capability was added, frankly).

Thanks for sharing any update on this front …

For binmodes I’m installing “hooks” where needed. Modes can attach to a hook or not. Going to expand this a bit as we go.

Also: I’ve been calling this feature FALA in the code and it feels sticky.

2 Likes

Hum, sorry for rapid fire posts, things are moving fast this morning.

I’m going to enable the fala for all hardware versions. There is no reason 5 and 5XL can’t have the feature, but with the huge caveat that what you see is not always what you get. Without that extra buffer high impedance bus (I2C, 1Wire, HDUART, 2Wire) capture will often be incorrect, and any glitches or pull-up issues won’t be visible. However, it keeps everything simple and gives a taste of what’s possible with the new RP2350B chip.

2 Likes

Excited and Curious … how will you enable this on the BP5 (RP2040)?

If it’s not reliable, I would caution against enabling it without at least some warning. While it’s fresh in our minds now from your message above, in six months I won’t remember that it’s not reliable on the BP5. If I then spend hours or days tracking a phantom bug (or not seeing a real one), that would be worse than just not working.

So… maybe show a warning on BP5/BP5XL, with a parameter / switch that bypasses the warning? That would be a good compromise, allowing the cool functionality if wanted, while keeping expectations realistic?

We don’t officially share information about our *.sal capture file format and we’re not ready to commit to keeping that documentation up to date. In addition, we want to avoid making breaking changes to the format which could affect 3rd party integrations.

@henrygab you are right about .sal format… But as a reverser, I don’t see it as a problem haha

2 Likes

Select binmode → FALA

HiZ> binmode

Select binary mode
 1. SUMP logic analyzer
 2. Binmode test framework
 3. Arduino CH32V003 SWIO
 4. Follow along logic analyzer
 x. Exit
 > 4
Binmode selected: Follow along logic analyzer

Currently, setup the fala before entering a mode. the fala capture speed setup is hooked into the mode change for now.

Enter mode

HiZ> m 6


Use previous settings?
 SPI speed: 10 kHz
 Data bits: 8
 Clock polarity: Idle LOW
 Clock phase: LEADING edge
 Chip select: Active LOW (/CS)

y/n, x to exit (Y) >

Actual speed: 10kHz
Follow Along Logic Analyzer capture: 40000Hz (4x oversampling)
Use the 'logic' command to change capture settings.

Mode: SPI
SPI>

Entering SPI mode. By default the fala oversamples mode speed by 4x. The mode change hook is used to display the speed and hint to use the logic command (which is not yet implemented).

Only SPI mode is currently playing nice with the fala

Follow along…

SPI> W 5
5.00V requested, closest value: 5.00V
Current limit:Disabled

Power supply:Enabled
Vreg output: 4.8V, Vref/Vout pin: 4.8V, Current: 1.0mA

SPI> [0x55]

CS Enabled
TX: 0x55
CS Disabled
Logic Analyzer: 33 samples captured
Logic Analyzer Graph:
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
-_______________________________________________________________________________
-__--__--__--__--__--__--__--___________________________________________________
---____----____----____----_____________________________________________________
SPI>

Enable a power supply and send some dummy data.

  • Example graph is backwards
  • Seem to be missing some bits, maybe need a startup delay or we’re counting something wrong.

Next, spitting out data and then debug the timings. This weekend I’ll need to do some extensive surgery on the mode struct.

Firmware

This test firmware, for BP6.
bus_pirate6.zip (184.3 KB)

1 Like

Added 500us delay on either side to get a better look. I’m concerned about that CS pin coming up early during the last clock (remember it’s backwards at the moment). Don’t know if that’s an RP2350 thing and we need to be watching for another bit to clear before transmission is considered complete. Hum.

Listening on the second uart now shows the data notification string. Next to get data dumping.

image

The + command now dumps the FALADATA, in reverse order (newest to oldest sample).

Current todo:

  • Make dump multitasking friendly so it doesn’t freeze the terminal
  • Basic setup through the logic command
  • maybe the VT100 logic graph toolbar through the logic command
  • logic bar: add controls and navigation, new interface for hooks
  • clean seperation between logicanalyzer.c, sump.c, fala.c, and logic_bar.c
  • precalculate a bunch of values and place in extern struct for easy access
  • Add frequency return to all mode _exc functions
  • Add a “get frequency” function to all modes (and maybe replace above with a change mode hook)
  • Testing to see what safety rails we need to unleash this on 5 and 5XL
1 Like

Here’s a firmware that could in theory be used to develop client software :slight_smile: It can capture, it reports FALADATA packets through the second serial port, and it dumps data in response to the + command.

bus_pirate6.zip (192.8 KB)

1 Like

Is it better to have a set of functions to access variables from within a “class” (C file), or expose a struct to access directly? I guess with the functions you don’t have to drag a struct def all around any source that needs one define from the file.

Logic bar is connected to the logic command, but it’s a mess at the moment. Working though. Not very happy with the ***s but better than -_, IMHO.

Going to clean up a bit and push for the day.

Test firmware

No instructions offered, other than the screenshot above :slight_smile:
bus_pirate6.zip (193.1 KB)

2 Likes

IMHO, unless you find a perf blocker, use well-named functions. This will allow you more flexibility to change things (with smaller code changes), simplify finding callers, etc. Some (all) functions will be inherently read-only, which is also really helpful when later wanting to change things around…

1 Like

I’ve started a simple system of hooks to notify code when certain things happen, like mode changes, pre-post syntax runs, etc.

Using this, both the binary port of the follow along logic analyzer and the VT100 interactive logic graph live in harmony. I’m still in the process of fleshing it out a bit.

Going to see if we can use TAB key to switch focus from command line to the logic graph for navigation.

The logic command is also coming together, hopefully in a way that makes sense.

May add an adjustable delay, based on current capture speed, to get a nicer logic graph as well. Maybe 10 ticks or so?

1 Like

It’s pretty solid!

  • navigation in the logic graph works
  • logic has a full help menu
  • binmode “fala” is independent of the terminal logic bar
  • A bunch of cleanup/quality of life helps to avoid gross code
  • a cute little set of hooks to tie everything together. To be expanded later
  • It should work on all versions (but only BP6 data is reliable)
  • New “lock terminal” option in binmode configuration struct eliminates messy locking in the actual mode.
  • Terminal is no longer locked for SUMP or fala modes, but with great power comes great responsibility… (eg I need to write docs next)

TODO:

  • Add a function to each protocol mode to query frequency setting
  • Add 10 sample start/stop delay calculated from sample frequency
  • A new hooks library to service stuff on mode change, etc.
  • Create a TAB key registry and use TAB key to swap logic graph and command line (maybe, we’ll see)

Latest firmware

Also on the rp2350-logicanalzyer branch

bus_pirate6.zip (186.2 KB)

4 Likes