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 - rsdio

Open Bench Logic Sniffer / loader protocol history? (pump-loader, ols-loader)
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.

Open Bench Logic Sniffer / Anyone using a newer Mac OSX with OLS?
I get the following error when I try to run any of the .dmg images of Jan Willem's OLS client:

"" 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?
Bus Pirate Support / Compile SPISniffer w/o WIN32 ?
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 instead of the live source tree, if that makes any difference.
Project development, ideas, and suggestions / Meeting USB requirement for 10 uF max on Vusb input pins
I have a USB-powered board that needs to feed a couple of regulators (one standard, one boost). Example circuits show either 47 uF or 100 uF on the input of each regulator to help keep the voltage up (combined with 0.1 uF to filter higher frequency noise).

The problem is that the USB specification calls for no more than 10 uF of capacitance on the input of a device between the VUSB and GND pins.  The parallel combination of 47 uF and 100 uF would be 147 uF, which is well over that limit.

What I'm wondering is whether the LDO diode ahead of these caps effectively hides them. Doesn't a diode act like a capacitor? ... or is that only under certain conditions? Since series capacitance is equivalent to less than the minimum capacitance, then it seems like the diode could hide the 147 uF capacitance so long as the diode itself is 10 uF or less.

I tried to build the equivalent circuit in LTspice, but I don't see a "show me the equivalent input capacitance of this circuit" feature. I've graphed the step response, and it seems to reach full voltage by 20 us, but I'm not sure how to interpret that.  I also simulated a simple 10 uF capacitor for comparison, and the rise time also looked to be about 20 us, but the problem there is that I put in a non-zero output impedance for the voltage source, but it seems fairly obvious that changing the output impedance will change the frequency of the simple RC filter and thus alter the rise time. I guess I could scan through the USB specifications again and see if there is some maximum resistance between the power source and the USB Device that I could plug in for a worst case rise time with a 10 uF capacitor, but then I thought it might be simpler to just ask here.

Is there a simpler way to determine whether my USB Device circuit violates the 10 uF maximum equivalent input capacitance for Vusb?  Maybe there's something in LTspice or TINA-TI that I could use.

Note: A dead simple solution would seem to be to drop the bypass capacitors ahead of the regulators to 4.7 uF each, or less, such that their parallel combination is guaranteed to be below 10 uF. But I still want to figure out whether that diode ahead of the caps hides them effectively or not.
Project development, ideas, and suggestions / Cap often burns out with USB hub
I have a PIC board that I designed to take power from either a 5 V jack or USB. There are ON Semiconductor MBRS130LT3G diodes, rated at 1 A and 30 V, from each power source to a common voltage rail where a 3.3 µF bypass cap is placed. The cap is supposed to be rated at 30 V, too, and is a 1206-sized ceramic. Part number is Nichicon F931C335MAA. The only other part connected to this node is a SHARP PQ1M335M2SPQ (a cheap $0.33 3.3 V regulator with 500 mA capacity!)

For some people, this cap burns out, and it might have something to do with questionable USB hubs. I'm trying to figure out how this is possible. Seems fine with computer USB ports.

What baffles me is that the cap is rated for 30 V, so I don't see how it could burn out from a mere 5 V supply, even with a really cheap USB hub.

One major problem is that I cannot be certain that the specified cap is the one being assembled, because I don't really have control of that. At one point, a sample board ended up with a cap that I did not specify, a Panasonic ECJ-3FF1H105Z. But that one is rated for 50 V.

Note that USB recommends 10 µF or less in total Vusb capacitance, to minimize inrush current. That's why I aimed for 3.3 µF for the main cap between the jack and the regulator, assuming that any stray capacitance wouldn't possibly throw the total over 10 µF. I suppose 1 µF wouldn't be bad.

Does anybody have any idea why this cap might be burning out?

Do any of you have stories of USB Devices (that you designed) burning out any of the first few components that connect to the Vusb input jack pins?

I don't expect you guys to necessarily help me with this, but I thought that discussion of USB powered Devices, interesting parts, and common problems might be of general interest.
General discussion / .CAD file preview
Every assembly shop that I've worked with asks for a .CAD file. Eagle can generate these from your project files by running gencad.ulp

I've recently had some problems with electrolytic capacitor polarity not matching between the.plc file and the .CAD file, so I am looking for a free viewer that I could use to double-check things.  It would be preferable if this worked on Mac OS X, but I also have XP installed on my Mac.
Project development, ideas, and suggestions / Low-loss battery supply regulator (buck/boost)
What would you say about a small board that would connect to just about any battery, provide regulated 3.3V or 5V, and keeps going even as the battery discharges down to 3.5V?

BACKGROUND: I'm hacking a couple of Flash_Destroyer boards for a friend to use in her fashion design display. The goal is a Back-to-the-Future-style time display that evokes moving forward in time faster than normal. Stuffing the Flash_Destroyer is a cinch, and the firmware should be really easy. The only catch is how to power the two displays without necessary needing a wall wart (or two). So, my thoughts obviously went to a battery, such as a 9V that might last a while.

PROBLEM 1: A standard regulator wastes a lot of power dropping voltage. For a 9V, that would be 4V lost. Multiplied by the current draw of two Flash_Destroyers, and that might drain the battery faster than necessary. I remember reading a hack online about an LED circuit that someone devised that used inductive boost to keep the LED supply above the minimum forward voltage, and thus kept running after the battery dropped below what would normally work. I figured there must be a chip to do this.

PROBLEM 2: I also thought about rechargeables, but those can put out as much as 9.6V, making the first problem worse. Fortunately, the MAX5092B can handle 72V.

I have a preliminary schematic and layout for a SMD solution. It might make a good Dangerous Prototypes dev/breakout board. There is a header for configuration jumpers. The header could also be used to connect the power supply to a target board via ribbon cable, including access to various control signals.


pins 1-2 : This should normally have a jumper installed, otherwise you'll want to look at the data sheet to determine the proper voltage divider to set a custom voltage (Note: maybe the design should be revised to have an onboard pot that could be jumpered to the SET pin instead).

pins 3-4 : Optional jumper. For real fun, the target circuit being powered could use pin 4 to access the !HOLD function (see data sheet).

pins 5-6 : Optional !RESET signal for the target circuit. This might be handy if you want to make sure your processor stays in reset until the power is ready. Closing the jumper pulls up !RESET, which is fairly useless without a ribbon. (Note: maybe separate jumpers and ribbon header should be designed to separate local configuration from remote configuration)

pins 7-8 : Totally unused. I didn't have a 2x4 header in my library, and I figured a 2x5 ribbon would be more common, so I just used these pins to separate output from input.

pins 9-10 : You probably want to connect these to Enable the supply all the time. Alternatively, the target board could control this signal instead.


CAVEAT 0: SMD is a pain. Maybe the circuit can be converted to discrete parts and redesigned onto a larger board. But if Dangerous Prototypes were to assemble these, and could do so at a decent price, then the SMD factor would not be an issue.

CAVEAT 1: I had hoped to make this board programmable for 3.3V versus 5.0V, but not with these chips. Other Maxim regulators often have a pin to select between the two common voltages, but the MAX5092 requires that you swap chips. The MAX5092A puts out 3.3V and the MAX5092B puts out 5V.

CAVEAT 2: Lithium batteries do not like to be discharged too low, but I'll leave that problem to be solved later. I really don't know how long it would take to discharge a 9V rechargeable.

FINALLY: I expect that this needs to be cleaned up, maybe with mounting holes added, plus more descriptive text on the board itself.

I welcome comments or improvements to the circuit.

General discussion / Atmel and Maxim CEOs join SIA (June 16)
This is old news, but...

Prominent CEOs Join Semiconductor Industry Association's Board of Directors

The Semiconductor Industry Association (SIA), representing U.S. leadership in semiconductor manufacturing and design, today announced that Steven Laub, President and CEO of Atmel Corporation and Tunç Doluca, President and CEO of Maxim Integrated Products, Inc. have joined the SIA Board of Directors. Both CEOs were approved in a unanimous vote during a regular session of the Board of Directors meeting on June 9, 2011.

More Info
Flash_Destroyer EEPROM tester / Available pre-assembled?
Hi, is the Flash_Destroyer available in a pre-assembled form? My friend wants to build an art exhibit with a digital clock running in the background, and the Flash_Destroyer seems like an affordable platform to create such a display (without : colon symbols, of course). Obviously, I'll need to break out MPLAB and write some custom firmware, but that should not be too difficult. However, it appears to only be available as a kit, and my friend is not going to solder this thing together. I could do the soldering, too, but that suddenly adds more work on top of the firmware development. Is there any way to get one already assembled?

P.S. I don't care if the Flash is destroyed already, since the repurposed platform won't use it.

Also, if anyone knows of another 7-digit or more platform for around $13.50 or less that could be hacked, please let me know.
Project development, ideas, and suggestions / Designing USB Devices for proper current and MaxPower
There are some common misconceptions about USB Device design with regard to the amount of current available and the MaxPower field of the USB Descriptors. Many DIY developers simply enter the maximum 500 mA value without consideration for the actual rules and ramifications. Some may think they're playing conservative by entering 100 mA instead, without realizing that they may still be in violation. This topic is intended to illustrate the situation as quickly as possible and open up a discussion if necessary.

Increasing the advertised current value in the USB Descriptors will not give you more current. The USB Device electronics are actually mostly in control of their current draw. The USB Descriptors are just there to warn the USB host computer about what to expect before your device is fully enabled beyond the default 100 mA. The OS version and USB driver versions, as well as any other USB devices plugged into the same port (or internal to the host computer) play their part in the overall current negotiations.

USB is not designed to limit current based upon device request. What actually happens is that a USB host is supposed to have a driver that is aware of the total current capabilities of each port. As each device is plugged in, the USB host driver is supposed to add the requested current to the total. If the requested current goes over the total limit, then the USB host will simply refuse to enable your USB device configuration.

To fully understand USB current limitations, things can easily get very complicated. There are two basic categories, the second of which has a few subcategories.

0) All USB devices (except the new category of 2.5A chargers) are limited to 500 mA. It's not hard to design a USB device that pulls more than 500 mA, and many Apple desktops will gladly supply over 800 mA. It's your responsibility to make sure your circuit does not exceed the limit. Some USB hosts will have current limiters on their ports, but those should not be activated when using properly-designed USB devices. Don't rely on protection: design your circuits to do the proper thing at all times.

1) The first category is a USB device which draws 100 mA or less. This sort of device needs no switching because every device is allowed 100 mA as soon as it is plugged in. There used to be a rule that when the USB device was put to sleep, it would have to reduce its current below 100 mA, but so many devices failed to implement this correctly that USB 2 relaxed the rules significantly. Unfortunately, this probably means that your laptop battery drains faster when its sleeping if you leave such USB device plugged in.

A very important consideration here is that nothing physically enforces this 100 mA limit - certainly not the USB host hardware. The number one thing to remember is that this 100 mA limit is a rule that you must design into your circuit. If you create a circuit that draws more than 100 mA under any conditions, then your device fails to meet USB specifications. All it takes is a resistor of the right value range across the USB 5V supply and you could be in violation without ever realizing it. It's actually rather tough in the DIY world to confirm that you're at or below 100 mA under all conditions.

2a) The next category is for USB devices which need more than 100 mA. This is where the circuit can get complicated, because there must be some sort of software switch that is off by default, and will never turn on unless the USB host grants permission for more than 100 mA. It is your responsibility to make sure that your USB device design does not pull more than 100 mA until it has received permission from the USB host. The USB IR Toy basically needs to keep the IR LED off until the USB host has activated the device. Other circuits might need a special regulator chip with a SHUTDOWN input that controls peripheral circuits so that only the main regulator and CPU are enabled (and hopefully under 100 mA, else you're screwed) by default. In other words, SHUTDOWN must be guaranteed to be active at startup, which may require pull-up or pull-down resistors in case the I/O ports are tri-stated. Then, once the CPU detects that the USB host has granted more current, the CPU can flip some I/O pin that disables the SHUTDOWN and suddenly pulls more power. You must measure the maximum current you need and advertise this value in the USB Descriptors. If the USB host doesn't have enough current to spare, then it will not send all of the USB control messages to your device to fully enable it. Asking for the maximum of 500 mA just means that the USB host will think it's overloaded before it really is, and that reduces the number of devices you can have active on a port.

Again, nothing is watching your device to keep the current below the limit. If your device accidently exceeds 100 mA before it is allowed, then maybe nothing will happen, or maybe the USB port will shut down. You must be totally familiar with all of the functions that your circuit can perform and make sure that nothing can pull current unless the total doesn't exceed the USB specifications.

2b) A special subcategory is when your device might prefer a larger current, but can still operate with limited functions on a lower current. Maybe your device prefers to operate closer to 500 mA, but in the event that the USB host might deny that current request, maybe your circuit could get by with 250 mA if half the functions were shut down and remain shut down. In these situations, your USB Descriptors would have to include multiple Configurations. You'll noticed that the current is not listed in the Device descriptors (where the assumption is no more than 100 mA), but rather each Configuration has a unique current in MaxPower. What the USB host is supposed to do is enable the first Configuration with the highest current request if the total current is not beyond its capabilities. If that first Configuration is too much, then the USB host will instead select the next Configuration with a lower current until it finds one that is not too much for the situation at the moment. When there are more devices attached to one port (via an unpowered hub), there will be less current budget available.

Basically, in every one of these examples, your USB Device should never pull more than 100 mA until the USB Host activates a specific Configuration that advertises more current. By activating a particular Configuration, the USB Host is giving the USB Device permission to draw as much current as was advertised, but no more. As I've stressed above, though, nothing is specifically minding the current of your individual device (other than perhaps a maximum current overload fuse).

Also, when your 500 mA USB Device is suspended (sleep), the current must drop back to 100 mA or less. Simpler Devices can just stop sending data to peripherals, but make sure the I/O pins aren't left in an active state that pulls a lot of current. More complicated Devices with multiple regulators will need to activate the SHUTDOWN line to take those high-current extras off line until the USB Host resumes.

In other words, if your USB Device exceeds the default 100 mA, but you do not design it to control the various current levels as they are enabled, then there is really nothing that the USB Host can do to limit your current. The USB specifications are designed with the assumption that USB Devices will properly advertise their current needs, and properly control their current draw based upon listening to what the USB Host permits. The only thing that the USB Host does is say "Yes" or "No" to a given USB Configuration. After that, it's up to the USB Device to control the current.

Finally, the thing to remember is that current is trickier to deal with than voltage. Have you ever seen those bumper stickers that say SHIT HAPPENS.? Well, I like to paraphrase that by saying CURRENT HAPPENS. Nearly all electronic circuits work by controlling voltages. The current that flows is therefore a side-effect of the load attached to the voltage. In other words, circuit makes voltages, but current happens as a result of those voltages and the specific loads. Your USB Device is the load on the USB Host's port. Your USB Device is therefore entirely in control over the amount of current that is pulled. If you don't pay careful attention and take responsibility for keeping the current within the limits, then unpredictable results will occur.

Post Script:

I have no idea what happens if you plug in more than 5 USB Devices on the same port. Since each gets 100 mA by default, 5 devices would already be at 500 mA. Perhaps the idea is that you can't really go beyond 5 because you'd need a 4-port hub to reach that number anyway. But if you plug a USB hub into a USB hub, it seems like you could quickly exceed the normal limits. I'm sure that the USB specifications say what should happen, but I've never needed to know, and so that's something I'd have to search for.

I also cannot remember whether USB Configurations must occur in order from highest current to lowest current. The USB Host will certainly enable the "first" Configuration that it finds, assuming it doesn't ask for too much current, but I don't know whether you could get fancy and switch up the order based upon some variable besides the current. The few USB Device firmwares that I've developed with more than one Configuration managed to confuse Windows so much that the OS refused to work at all.
Bus Pirate Development / Bus Pirate v4.0 received
I suppose it isn't terribly exciting to announce that I received my BPv4 hardware today. I assume that few people have this platform at the moment, so I thought it might be useful to have a thread where we can stay in touch with others who have the specific hardware. Actual development topics should probably continue in their own threads, so maybe this thread could just be for announcements.

My first project is planned to be using it to hack CAN bus messages in my car, but I don't know how much time I will have. Basically, the Bus Pirate with PIC24 and OTG wiring is an ideal platform for me to experiment with on many project ideas, so I'm not even sure how often I'll be using the Bus Pirate firmware or whether I might develop my own firmware. I'm sure I'll run out of time before I run out of ideas anyway.

P.S. The BPv4 actually arrived on Friday, but I was out hiking for the day and missed signing for the package. It was sent via Registered Mail, which actually makes sense considering the price.
General discussion / Electric Porsche 944
I don't think that this is an open project, but I bet one or two people might be interested in reading about a 1.2 kA motor driver circuit based on the PIC16F877.

Electric Porsche 944

This thing puts out so much torque that it has to be run at 3/4 power to avoid slipping the clutch!
USB Infrared Toy / USB Infrared Toy v2 delivered (photos)
Just received my v2.  Funny thing is that the box from China is marked "5mm LED"

Here are some photos of the opaque blue zip lock and both sides of the finished product.
General discussion / PIC18F14K50 Phantom of the Floppera

[quote author="FunToTheHead"]Features two 3 1/2" drives and two 5 1/4" drives connected to a PIC18f14k50 microcontroller. It interfaces to any MIDI source via MIDI over USB. Straight MIDI would also be possible with an additional small circuit and some minor firmware changes. This initial version can respond to all 128 MIDI notes, and pitch bends +/- 2 semitones.

As it can produce only four simultaneous notes, and each drive has a different range and tonal characteristics, best results are obtained by arranging compositions by hand. However, it features two modes of operation: in one mode, MIDI channels 1 through 4 are played directly on floppy drives 1 through 4. In the other mode, all 16 MIDI channels are read, and notes are "intelligently" divvied out on a first-come, first-serve basis. "Note stealing" ensures that melody lines sound, but chords are often cut short. One or the other produces acceptable results for many unmodified MIDI files straight out of your favorite media player.[/quote]