My friend's art project is long over (2011..2019!), but I just thought of another angle:
Does anyone have a spent Flash_Destroyer that they no longer need? I imagine that if you're already burned out the on-board Flash, and really don't want to bother getting a new Flash chip, then maybe you'd like to pass on the board. Contact me via PM if you have one. This isn't anything high priority, I just think it would be fun to have a PIC + LED display around for quick projects.
I realize that it's been about a decade since the initial design, but can anyone provide background history on the protocol that is used to update the FPGA ROM?
For Windows, pump-loader and ols-loader are provided as command-line tools. Also, the protocol used is sufficiently documented that I was able to write a new macOS program that communicates with the OLS to successfully upgrade (or downgrade) the FPGA ROM. So, I don't need help getting things to work as they exist now.
That said, I'm wondering where this protocol originated. It consists of 4-byte (32-bit) commands, plus additional data as appropriate (and very much geared towards the specific page size of the attached serial Flash memory chip). Is this an existing protocol that works with other systems? ... or was the protocol created specifically for the Gadget Factory / Dangerous Prototypes Logic Sniffer?
I've searched the forum here, since I'm more familiar with the Dangerous Prototypes site, but didn't find any notes on the development of the loader protocol. If the answer to my question is somewhere on the Gadget Factory site, please let me know.
I get the following error when I try to run any of the .dmg images of Jan Willem's OLS client:
"LogicSniffer.app" is damaged and can't be opened. You should move it to the Trash.
It's been several years since I used the OLS, but I need to get it running again on my new laptop running 10.8.5 Mountain Lion. I read about the 32-bit / 64-bit issues, so I marked the application's Info to "Open in 32-bit mode" but this did not help.
Is anyone running Mac OS X on a reasonably new Mac (mine is actually rather old, but newer than the last 32-bit machine where I successfully ran the OLS client)?
Is there another client besides JaWi's that will run on OSX?
If you're willing to learn FPGA programming, I think that you could write your own FPGA setup to sniff the DRAM protocol. Instead of storing the raw waveforms (high bandwidth), you could first decode the data and then store only the DRAM data in the FPGA RAM. This would then require a method to upload the data through the PIC, which probably requires some custom PIC programming beyond what it already supports. It's all open source, so you have a decent starting point, but learning FPGA programming won't be easy. In other words, the OLS is a great hardware platform for more than just a Logic Analyzer, but it requires custom programming to do things outside the norm.
I think you'd also need some complex triggers to facilitate grabbing different sections of DRAM on different runs. Or, you could just grab a different address range on each run, filling the FPGA RAM. However, I don't think that your goal of directly accessing the code loaded from Flash will work if you're just sniffing the DRAM lines. You'll be able to see the actions performed by the code in Flash, but you won't actually be able to read the Flash contents (unless the Flash is automatically copied to DRAM and then executed from DRAM - in which case you're in luck).
I'm not sure whether my suggestion here will help with the topic at hand, but it seems to me that the best place for the firmware version is in the USB Device Version Number. Of course, this would be handled differently for the v3 due to the FTDI Chip versus the v4 with the PIC24.
Right now, BPv4 firmware 6.1 is identified as Device Version Number 0.0.2 (0x0002 is interpreted as 0.0.2 according to the USB Specifications). Ideally, I think that should be something like 4.6.1 (0x0461) if you want to combine hardware and firmware versions together, or 6.1 (0x0610) if you're happy with the firmware version alone.
I remember suggesting this before, but maybe it was for the USB IR Toy. In any case, I'm slightly torn as to whether the USB Device Version Number should reflect hardware revisions as well as firmware revisions. At the very least, I think that the firmware version should be reflected in the REV, because the firmware is what provides the number to the host, and the firmware source is where the number comes from. Seems pointless to update the firmware and not update that number. As to whether you want the hardware revision to appear there, too - well, that's up to you guys.
In some respects, I realize that my suggestion might not help some folks, particularly those who are dealing purely with the serial data stream. My suggestion above would require accessing some kind of USB API on the Host in order to retrieve the number. Then again, there's no reason why the version number cannot appear in both places. In the USB Descriptors, it shouldn't hurt to update that number with each firmware release, and the same number can appear in the serial menus and banners.
[quote author="ian"]Yes, it uses the hardware slave mode and follows the bus clock, no setting is needed. All pins will be inputs, and will not interfere with the circuit.[/quote] I'm guessing that you had to use two SPI peripherals to read both the MISO and MOSI lines. I assume that each SPI peripheral is in slave mode and the input is sniffed while the output is unconnected - all through the PIC peripheral patch feature. I suppose all of this is in the BP firmware source, but sometimes I like thinking out loud...
[quote author="ian"]I'll be interested to see what data you can get. 6.4MHz is pretty speedy, if it's too long the BP might have some trouble keeping up without missing CS transitions.[/quote] By the way, the 68HC11 that is the SPI Slave is only running at 2 MHz (8 MHz crystal), and so the SPI cannot run any faster than 1 MHz in both directions. In my particular hardware, the SPI is actually only running at 312.5 kHz, so the Bus Pirate should be fine keeping up with that.
Unfortunately, I haven't been able to get SPIsniffer to see anything yet besides sync, but that may be my hookup.
The LogicSniffer is showing data, though, so I'm slowly making progress.
BPv4 runs fine with firmware 6.1 and SPIsniffer compiled on OSX Tiger (10.4) and running on Tiger (PPC) and Snow Leopard (10.6 Intel).
I still need to hook up the SPI device that I want to hack, but that will be a separate report. This basically seems to show success for compiling the source in this topic on OSX (with minor changes to #define FALSE & TRUE in the serial header).
p.s. My apologies for the glacial pace of my progress, but I keep trying this an hour here or an hour there, and I don't have all of my equipment at both locations.
Someone at Metrix was kind enough to loan me a v3.x Bus Pirate, and it was at least able to get into the proper mode for SPIsniffer. I didn't have anything on hand to test the SPI data, but it was at least promising that the OSX compile ran the code that far.
I'm going to load the 6.1 firmware for sure, and see if it gets as far as the BPv3.
Right now, the 6.0 firmware is not responding to SPIsniffer, so I'm either going to get the firmware bootloader running on OSX or just break out my PICKit 2 and update to 6.1 to see if that works better with SPIsniffer.
If 6.1 is the same, I'll have to debug the SPIsniffer code on OSX. At least 'screen /dev/cu.usbmodemXXXX 115200' is working on OSX.
As for the 6.4 MHz, I have a hunch that the clock is not continuously running, and maybe it was measured incorrectly.
p.s. Does SPIsniffer need to have the SPI clock set, or can it just sniff at whatever clock rate is happening? I assume that all SPI pins are inputs, and the Bus Pirate will use the incoming clock to latch both MISO and MOSI, so I can watch the data flowing from the original master and slave devices without the BP interfering.
It compiles and runs with one change. The only issue I had to fix is
B) TRUE and FALSE are not Standard C
(I just added #define statements in serial.h where they would be found by all three .c files)
So far, I've used the Bus Pirate to measure that my device has a 6.407 MHz SPI clock, assuming that I measured it when it was fully active. Now that I have SPIsniffer compiling, I'm going to see what sort of data is coming through. I hope to write up my hack/repair soon.
I'm ready to embark on an SPI sniffing project, so I am trying to compile SPISniffer for Mac OS X. This should be the exact same task as compiling for Unix.
So far, the main.c source includes A) non-C-standard backslashes in the #include "..framework*.h" references, B) TRUE and FALSE are not Standard C C) Sleep() is not a Unix library, but usleep() and sleep() are.
In serial.c D) The dumphandle declaration should be bracketed by #ifdef WIN32, because it is neither used nor available outside Windows.
I'm still working on this, but I wanted to post what I've found so far to see whether anyone else has this working.
I started with the BusPirate.SPIsniffer.v0.3.zip instead of the live source tree, if that makes any difference.
I believe that Ian is talking about the limitation of the FTDI USB chip, meaning that you cannot simply pass your ADC data on to the host computer.
However, if you wanted to process the audio data with the PIC, maybe even compress it somehow before passing it on to the host computer, then you might have a shot. Unfortunately, this would require custom firmware, because the stock Bus Pirate firmware isn't going to support this. But thinking of the Bus Pirate hardware platform as a potential first step in your own prototyping process, I think it might be a decent starting point.
Now that Ian has mentioned the limits of the FTDI USB link, your next stop is to grab the data sheet for the exact PIC being used on your specific Bus Pirate model (I have the bleeding-edge Bus Pirate v4, so my capabilities are beyond what the v3 can do). Read about the SPI peripheral, and compare the details to your ADC chip's data sheet. If everything looks compatible, then you can probably start developing your own custom PIC firmware. If you have a PICkit 2 or compatible debugging device, and attach it to the ICSP connector on your Bus Pirate, then you can iterate through your own firmware development.
The only problem is that your firmware will overwrite the Bus Pirate firmware, so you have two choices:
1) You can start with the open source Bus Pirate firmware and add your own modes, thus keeping your Bus Pirate usable for other tasks at all times, or
2) You can just make sure you have an image of the latest Bus Pirate firmware on hand so that you can re-load it via ICSP any time you want to switch from your prototyping to using the standard Bus Pirate features. This second option allows you to keep your custom firmware trim and dedicated to just your features. If you're not going to use the standard Bus Pirate features anyway, then this option is really the best.
FYI, I purchased the Bus Pirate specifically as a platform for experimenting with my own prototype projects. When working for clients, I usually start by designing a custom board before I start writing firmware. That has always worked well for me so far. However, when I'm just doing this for fun, without a paying client, I don't really want to spend the money on designing a new hardware platform as the very first step. The Bus Pirate helps by getting some of the work out of the way so I can jump-start. It still requires knowledge of PIC programming, plus some connections with external hardware (to make the project fun), but it's a good choice. You might already know all of this, but I thought I'd mention it anyway as confirmation of your direction. I just hope the Bus Pirate PIC can talk to your ADC, and that you don't need full bandwidth audio over USB.
p.s. The Bus Pirate v4, with its integrated USB replacing the FTDI Chip, just might allow you to write USB Audio Class firmware that could break through the USB serial class bottleneck for full-bandwidth audio. Just be forewarned that writing a UAC firmware is not trivial. I've only seen one open source attempt, and I never got it to work on my hardware (can't remember why).