Skip to main content


This section allows you to view all Topics made by this member. Note that you can only see Topics made in areas you currently have access to.

Topics - alexsunny123

Bus Pirate Support / PIC programmer 13volt (VPP) supply ?.

I'm putting together a collection of circuits for the PIC programmer 13volt VPP supply.

I'm going to prototype a charge pump and a boost converter. The boost converter will be able to make lots of voltages, up to hundreds of volts, but I plan to clamp it at <20 with a zener. I'm also going to try making the boost converter with a BC547 transistor instead of a FET, because the PIC is only 3.3volts and most FETS want 5v for full-on.

Bus Pirate Support / SPI sniffing with the Bus Pirate ?.

I'm currently investigating whether it is possible to do some reverse engineering with the help of the Bus Pirate. Basically, we need to correlate an USB data stream (PC to undocumented device) with a SPI data stream (undocumented device to documented SPI flash chip). I'm not sure whether the undocumented device is just a stupid SPI master which receives SPI commands over USB and passes them through or whether it actually has builtin "intelligence". Dumping the USB data stream is already taken care of, so only the SPI data stream remains, and for that we'd like to use the Bus Pirate.

Some things about the Bus Pirate SPI sniffer mode remain unclear, though:
Quote from:
The SPI sniffer is implemented in hardware and should work up to 10MHz. It follows the configuration settings you entered for SPI mode.

Does this mean the SPI clock must be set in the SPI mode before sniffing, or will the sniffer work at any frequency below 10 MHz regardless of SPI mode speed settings?

Quote from:
The I2C and SPI sniffers now use a 4096byte output ring buffer. Sniffer output goes into the ring buffer and gets pushed to the PC when the UART is free. This should eliminate problems with dropped bytes, regardless of UART speed or display mode. A long enough stream of data will eventually overtake the buffer, after which new bytes will be dropped until space is available.[...]

Both sniffers use the user input buffer as a ring buffer. Any commands entered after the sniffer macro will be lost.
If the ring buffer is full, bytes are simply dropped until there’s free space. The MODE LED turns off if this happens.

Since I want to correlate logs, dropped data is a problem, made more severe by the fact that there will be an almost sustained (that is, there will be a delay in the order of microseconds after each 260-byte communication chunk) data rate of 10 Mbit/s in each direction (MISO+MOSI) with a total length of ~2 MByte per direction. That means I will overrun the 4096 byte ring buffer easily.

After that, will the Bus Pirate empty and fill the ring buffer bytewise and thus end up with a random selection of bytes from the stream being filled in to the freed byte(s) in the ring buffer each time one byte becomes free in the ring buffer? Such a random selection would mean anything past the first 4096 bytes is unusable as trace. OTOH, if the ring buffer is emptied in n-byte chunks (preferably larger than 260) the chunks are still useful.

It seems the MODE LED is the only indicator of a buffer overrun and there is no way to detect such a condition from the Bus Pirate output on the virtual serial port. That makes finding the chunk boundary impossible AFAICS.

Pirate PIC programmer / PiratePICprog console application?..

The .NET programming app 7 wrote is great. It has rescued a bunch of Logic Sniffers, and we learned how to program PICs.

For continued development though, I'd like to build a cross-platform console app. I'm going to use pump-loader as the basis because it has all the parts I need.

This thread will document my progress knocking together an initial simple application framework.

I already documented my attempt to compile pump-loader under MinGW: ... te-loader/

Now I'm going to:
*Modify for binmode entry, setup raw2wire.
*Add ICSP entry
*Add readID
*Use new 4/16 command format in v5 firmware.

I'll be updating my code to SVN here: ... atePICprog

Pirate PIC programmer / Compile pirate-loader with MinGW ?..

I've been playing with mingw for a updated PIC programmer, cross platform, console app. I started by compiling the pirate-loader.c for the v4 bootloader - it's a simple single file with all the components needed (HEX parsing, serial coms, etc). In the source it looks like Piotr made POSIX-compatible read, write, close, and open, functions for windows. When I compile with MinGW I get an error that write, read, and open are already defined in io.h (I guess it already has posix substitutes?). I commented out the version in io.h and it compiles and works fine (I tried removing the version in the app, but it didn't work right, opening serial port error). This doesn't seem like an ideal solution. Does anyone have any suggestions? Here's the prototypes for the functions:

From pirate-loader.c:
   int write(int fd, const void* buf, int len)
   int read(int fd, void* buf, int len)
   int open(const char* path, unsigned long flags)

From MinGW io.h:
//_CRTIMP int __cdecl __MINGW_NOTHROW write (int, const void*, unsigned int);
//_CRTIMP int __cdecl __MINGW_NOTHROW read (int, void*, unsigned int);
//_CRTIMP int __cdecl __MINGW_NOTHROW open (const char*, int, ...);