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

Bus Blaster JTAG debugger / JTAG circulate/echo operation?
I'm investigating using my bus blaster to replace an old parallel-port JTAG setup. (It's for an old proprietary ASIC)

For the most part, everything seems fine, the original authors of the test software were nice enough to carefully contain everything in three main routines:
scan_ir (just what you think it is)
scan_dr (also what you think it is)

But then there is a 'circulate_dr' function, that's a scan_dr read-only, but it's setup so just before each clock, it echos the input to the output. I guess that would allow the jtag to cycle the entire chain through and put all the original data back in the shift registers when reading. This doesn't seem to be standard, from what I can tell, but it's used repeatedly for this device.

The FT2232 doesn't do this echo on a normal JTAG_Read (using FTDI's FTCJTAG.dll). Perhaps there's a way to get it to do it directly via the D2XX.dlls and lower level MPSSE stuff?

I could easily fake this with the CPLD, by having a GPIO set a mux that sources TDI from either the FT2232 or an echo of the TDO input. That's one thing awsome about this setup. But I'm wondering if anyone else has seen anything like this or if it can be done directly in the FT2232. At the end of the day, it may be easiest to go with the XDS100, which has the same capability and would be easy to sell to management, I suppose. I'm just curious if anyone has ever seen anything like this.

General discussion / Any guess why PICkit freaks out when I power-cycle target?
My pickit 3 is having serious problems when I power up the target after it's already connected to USB (no big deal), but that includes even power-cycling the target while the pickit is connected.

That is to say, if the pickit is connected to the PC and the target while the target is off, and then I turn the target on, the pickit will no longer even communicate with the PC until I disconnect & reconnect the USB cable. Note that I am not using the pickit to power the target.

Start with pickit connected to PC and target, target's supplies are OFF. First I try to connect in MPLAB X:
Code: [Select]

Connecting to MPLAB PICkit 3...
Firmware Suite Version.....01.28.92
Firmware type..............dsPIC33F/24F/24H

Target device was not found. You must connect to a target device to use PICkit 3.

Totally normal, of course. Now I turn on the target's supplies without touching the pickit 3, and then try again:

Code: [Select]
Connection Failed.

Note that's the same message you get if the pickit is not responding, not if the target isn't responding.

Now leaving the target power on, I disconnect & reconnect the USB cable, and it works:
Code: [Select]

Connecting to MPLAB PICkit 3...
Firmware Suite Version.....01.28.92
Firmware type..............dsPIC33F/24F/24H

Target detected
Device ID Revision = 3003

The following memory area(s) will be programmed:
program memory: start address = 0x0, end address = 0x3ff
configuration memory

Programming/Verify complete

Target Halted

And lastly, stop the debug session, do a power-cycle on the target, and try again:

Code: [Select]
Connection Failed.

This makes the pickit 3 pretty much 100% worthless for in-circuit debugging if the target uses its own supplies. Any guesses on what is causing this or how to reset the damn thing without unplugging & replugging the USB every single time?

Note: The target device is a pretty simple TI ua7833 linear reg, and has a totally floating supply with a low inter-winding capacitance power transformer. I might try wiring target ground to earth ground, which is OK for development, even though ultimately the circuit must float. Right now the only ground connection to the circuit is through the pickit 3, but again given the power transformer I'm using, it shouldn't be a problem.
Project development, ideas, and suggestions / Power supply teardown / Upgrade (suggestions needed)
Hi all,

After watching the power supply threads here and elsewhere not really turn into anything yet, I'm going to go through the process of taking an older HP power supply (usually various kinds are available on ebay for less than a hundred bucks), doing a tear down and repair (the one I got is 230v, needs to be changed to 110, has some other minor issues). I'm hoping to document the process as well.

After getting it up and running, I'm also going to convert it over to full digital control. The end result will be some modular PCB's that could be used with almost any older HP/Agilent power supply (they all use virtually identical feedback/control circuits), and then daisy chained together to a master controller that will interface either via Bluetooth directly to an android device, or via usb to a PC (or r-pi) and then to a Linux or android front end via tcp/ip.

So I'm just interested in feedback as far as:

1) Should I just do a blog with pictures/text, or is it worth doing some videos? Combination of them? There will probably be long gaps in the process as I'm busy with school and/or getting PCB's made and such.
2) Is it worth trying to document software/firmware design process and/or PCB layout? I'm planning on switching from eagle to diptrace so I'll be kind of a newbie with the software, so that might be pretty ugly to watch.
3) I'd like to experiment with the android front end (I've done tons of java, I just need to learn the new UI layout stuff), is it worth making it work on a phone or just stick with tablet designs (probably a Nexus 7 as reference device).
4) Is it worth exploring Bluetooth SPP? It seems generally sketchy making it work, but then if it works on the standard nexus devices that's probably good enough. This avoids all the usb nonsense as well. The alternative is connecting to a PC or r-pi (probably using MCP2200 or FT232 for vid/pid's sake) and then using tcp/ip after that, which is fine but just adds more layers.
5) I'm most comfortable with atmel/avr, though I'd like to get into PIC too, but I feel that might be just one too many things to learn & deal with. Just wondering if people had strong opinions on the matter.

My plan is to make all the designs & software open/free, of course.
Project logs / avr usb breakout & RS-422 "IR" blasters

So there's a few things here:

Bottom right is an at90usb162 breakout I had made at seeed. I pretty much stole the Teensy's reset circuit, so I don't know that I should put up the gerbers. But I added a few important features for me, such as an AP2141 current-limited load switch which lets me put unlimited capacitance on any daughter cards without issue. I also added extra ESD protection ic's on the bottom (just special zener 4-packs). There's space for a 3.3v regulator, not used for this design.

The other board can be populated two ways. The one attached to the usb breakout is a simple 3x RS422 transmitter. The other boards are isolated RS422 receivers and attiny25's used as IR blasters. Right now I'm not actually doing 38khz modulation, because these boards are going to be hard-wired internal to the equipment being controlled. An open-collector transistor output will pull-down the IR module's output (which is also open-collector) to fake an IR signal.

The receiver boards could be easily changed to daisy-chain compatible with a very simple re-spin, it just wasn't an issue for me, I intended to use three separate cables since my controlled equipment is not in easily daisy-chained locations anyway.

After moving to almost all SMD parts I can say that 1206 parts are actually a joy to work with, and 0805's are acceptable. 0603's are quite doable but a real pain, so I only intend to use them where absolutely necessary. I had no problems with the IC's, using a hoof tip on my metcal, they were very very easy.

I've already tested transmitting codes from the PC via virtual serial port, and it's working OK so far. Haven't hooked it into the equipment yet, that should happen this week. I also need to wire up a 3x4 keypad to the micro.

I'm hoping now that the open USB stack for PIC is coming together I'll eventually switch and make it into a PIC18F breakout.
USB Infrared Toy / Non-USB IRtoy?
I haven't looked at the code, but from what I understand, the IRtoy's USB controller just creates an internal virtual serial port, right? If one were to move its interface to the real serial port on the device (and then possibly chose a non-usb micro) and give each IRtoy an address using jumpers, then it should be possible to place a large number of them on a RS-485 network.

I'm building a small RS-422 (star, not daisy-chained) network of attiny25's used as IR blasters (though they are hardwired with open-collectors, so they produce IR codes, but have no actual IR LEDs). We're using it to control multiple cheap component-type video switches to save some guys buying a massive video mixing panel.
Project logs / LED scoreboard (upd: 5/8)
Sort of... this is my final project at tech school, and one of the instructors indicated he wanted a large LED display to show competitor #'s at horse shows. (Show's who's performing, who's up next and such, so riders outside the showroom can see when they're up.) Basically it's a huge 30-element 7 segment display.

Just got the PCB's from seeed:

There will be ten pairs of display/driver boards, strung together by cat5 for the data lines. The xbee/microcontroller in the bottom right is only populated on the first one, obviously.

It's really just a huge string of 74HC595's driving npn bjt's wired as little CCS's for 4-element strings of LEDs. Not the most exciting thing ever but going through the whole process of circuit design, parts selection, pcb layout, firmware & PC software, while keeping under a budget and on time was really interesting to do.

The XBee radios that I'm using are pretty freaking awesome, I must say. For what they can do, the cost is pretty reasonable.

And lastly, I owe huge thanks to DP because the bus pirate and ols have been absolutely invaluable for our final project class. With seemingly everyone using zigbee/xbee or a serial accelerometer or something, they've been in constant demand in our final project class. At least two other kids have ordered bus pirates and even the instructor is getting one... perhaps part of the curriculum one day? :)
Open Bench Logic Sniffer / Second endpoint/VCP for sump pump?

Will the PIC's alternate USART be available as a second virtual com port by default? I've been thinking about adding some hardware I2C and/or SPI triggering to the design and would want a second channel to the FPGA during operation so I can test and debug it without trying to extend the SUMP software or protocols at first. If I recall though, you were planning the second UART to be for alternate PC<->PIC communication, not PIC<->peripherals.

Alternately, I remember you mentioning the PIC had two SPI's as well, one pin configurable and one hard-wired. I'm assuming the hardwired one is the in-circuit programming header? Obviously there's going to be a way to program the FPGA's SPI flash from the PC, but is there any way to access either SPI while the virtual com port is up on USARTa for normal operation?