Debugging with a single LED

[Philip Pemberton]

Here's a good mind bender for the gurus...

I have a device with an FPGA and a PIC microcontroller (among other
things). The two communicate over a 12-line link:
8 multiplexed data/address lines -- can be In or Out
2 Address Load lines -- low and high. Inputs to the FPGA.
Read and Write -- inputs to the FPGA

I can make these outputs or inputs on the PIC, and can do the same on the
FPGA. The I/O state above is simply how they're configured in the
"working" hardware.

Problem is, the boards I'm getting back from manufacturing have really
shoddy yields. 70% failure rate. I'm getting bridges and opens, nearly
always on the PIC-to-FPGA lines. Anyway, enough of that. Suffice it to
say, I have a stack of almost-working boards with various issues. Visual
inspection is not finding them, and shotgun-resoldering the PIC and FPGA
tends to cause more problems.

Basically: I need to find the shorts and opens, and fix them, without
affecting the rest of the pins (which I assume to work). In order to do
this, I need to know where those shorts and opens are.

Problems:
1) I don't know which pins work. I can't even guarantee that any of
them work.
2) The only real output the FPGA has is an LED
3) I'd like to find as many shorted pins as possible in each test pass.
If I can find and eliminate them all, so much the better.

So far the best idea I've come up with (actually a friend came up with
it) is to load a bitstream which reads the state of the other 10 lines.
The FPGA clocks out 20 '0' bits, a '1', then the state of the 10 pins.
This allows the PIC/PC combination to automatically test the whole set of
remaining combinations.

Can anyone think of an easier way to do this?

Thanks,
--
Phil.
usenet10@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "10" with the last two digits of the current year

 

[Allan Herriman]

On Sat, 20 Nov 2010 23:22:48 +0000, Philip Pemberton wrote:

Here's a good mind bender for the gurus...

Problems:
[snip]
2) The only real output the FPGA has is an LED

When I worked at Fujitsu, we had a controller board with a GPIO driven
status LED on its front panel. When it was in debug mode (e.g. after a
crash), software on the target system would implement a bit-bashed UART
and send the resulting bits to the LED. We had a little gizmo with a
phototransistor and an line-powered RS232 buffer that would send the bits
back to a serial port on a PC so the debug results (in this case a stack
trace) could be seen on a terminal emulator program. A magnet in the
gizmo held it on to the panel in the right place above the LED.

You shouldn't have any trouble rolling your own UART to do something
similar. If it's a Xilinx part, I recommend a picoblaze + picoblaze uart
combination if there's more than a trivial amount of information to send.

Cheers,
Allan

 

[Newman]

On Nov 20, 7:22 pm, Allan Herriman <allanherri...@hotmail.com> wrote:

On Sat, 20 Nov 2010 23:22:48 +0000, Philip Pemberton wrote:
Here's a good mind bender for the gurus...

Problems:
[snip]
  2) The only real output the FPGA has is an LED

When I worked at Fujitsu, we had a controller board with a GPIO driven
status LED on its front panel.  When it was in debug mode (e.g. after a
crash), software on the target system would implement a bit-bashed UART
and send the resulting bits to the LED.  We had a little gizmo with a
phototransistor and an line-powered RS232 buffer that would send the bits
back to a serial port on a PC so the debug results (in this case a stack
trace) could be seen on a terminal emulator program.  A magnet in the
gizmo held it on to the panel in the right place above the LED.

You shouldn't have any trouble rolling your own UART to do something
similar.  If it's a Xilinx part, I recommend a picoblaze + picoblaze uart
combination if there's more than a trivial amount of information to send.

Cheers,
Allan

If it is a Xilinx FPGA, you may also consider using the JTAG UART IP
block where you can get terminal information via the jtag connector.
You may also consider sending a walking 1 and walking 0 across the
interface to the FPGA and observing the signal with chipscope if you
have it.

 

[saar drimer]

Can anyone think of an easier way to do this?

Are the JTAG pins available?

If so, Chipscope with VirtualIO should be the easiest for this kind of
debug. You can desolder the PIC and manually loopback/short the pads
and then change the stimulus through the chipscope GUI and see if the
signals propagate. With one design you can then test all routes. If
this is an Altera device, use SignalTap.

saar.

 

[Philip Pemberton]

On Mon, 22 Nov 2010 08:07:28 -0800, saar drimer wrote:

Are the JTAG pins available?

If so, Chipscope with VirtualIO should be the easiest for this kind of
debug. You can desolder the PIC and manually loopback/short the pads and
then change the stimulus through the chipscope GUI and see if the
signals propagate. With one design you can then test all routes. If this
is an Altera device, use SignalTap.

I thought SignalTap was monitor-only and couldn't twiddle pins?

Hmm.

Thanks,
--
Phil.
usenet10@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "10" with the last two digits of the current year

 

[kevin93]

On Nov 20, 3:22 pm, Philip Pemberton <usene...@philpem.me.uk> wrote:

Here's a good mind bender for the gurus...
....
Phil.
usene...@philpem.me.ukhttp://www.philpem.me.uk/

I often have a similar architecture for communication with my FPGAs.
Do the wires go direct from the PIC to the FPGA? If so then shorts at
the FPGA will affect the lines at the output of the PIC and it will be
able to detect them.

1) Write diagnostic code for the PIC that verifies the state of the
FPGA communication lines after setting them - this is to detect shorts
on the lines to the FPGA. Run through all combinations of the lines
that do not cause the FPGA to be active on the shared bus (maybe do it
with the FPGA unconfigured).

2) Now write diagnostic code that writes to a loopback register on the
FPGA and run through all combinations to verify all the data bits.
This will detect any opens in the lines.

If you have intermittent faults you may need to run these tests many
times in a loop to detect occasional failures.

Opens can sometimes be tricky as the capacitance of the line may hold
the state - one solution is to arrange to set the bus to a different
state (e.g inverted) between the write and the read to ensure you are
really reading the data from the FPGA.

You can speed up these tests by doing walking ones or zeros rather
than all combinations (be aware of which particular lines may short).

Once you have these running reliably you can be pretty confident that
you have communication working.

kevin

 

[Nial Stewart]

So far the best idea I've come up with (actually a friend came up with
it) is to load a bitstream which reads the state of the other 10 lines.
The FPGA clocks out 20 '0' bits, a '1', then the state of the 10 pins.
This allows the PIC/PC combination to automatically test the whole set of
remaining combinations.

Can anyone think of an easier way to do this?

YES!

Tis exactly the sort of situation the 1 pin interface was designed for...

http://www.1pin-interface.com/


All you need is one unused FPGA pin routed to a header (with a ground) to
give bi-directional control and status to the FPGA.

If you're loading a custom debug build you can use any exisitng header pin
that has a fairly local GND.



Nial

 

[Philip Pemberton]

On Tue, 23 Nov 2010 11:47:12 +0000, Nial Stewart wrote:

Tis exactly the sort of situation the 1 pin interface was designed
for...

http://www.1pin-interface.com/

All you need is one unused FPGA pin routed to a header (with a ground)
to give bi-directional control and status to the FPGA.

If you're loading a custom debug build you can use any exisitng header
pin that has a fairly local GND.

Shame my budget won't stretch to another ÂŁ100+ debug pod.. that looks
perfect for the DiscFerret ATE

Anyway, I tracked down the problem -- the PLL isn't running. At all.
ExtClkIn is toggling at 20MHz as it's supposed to, but the PLL never
locks. All the internal logic runs off the PLL, including the Parallel
Master Port. No PLL means no clock, no PMP function, basically "He's
DEAD, Jim!"

Now I need to figure out why I have two EP2C8As with dead PLLs. Then
replace them. Those things are a pig to desolder, even with a hot-air
station...

--
Phil.
usenet10@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "10" with the last two digits of the current year

 

[Nial Stewart]

Shame my budget won't stretch to another ÂŁ100+ debug pod..

I'd like to be selling it a bit cheaper but the volumes are prototype
quantities, even the enclosure is > Ł10 per unit.

The interface voltage is configurable so it can be used on any future
FPGA board you design.

The 'marketing' angle is that compared to your time it isn't that expensive,
if you save an hour on three projects it's paid for itself.

that looks perfect for the DiscFerret ATE

Eh?

Anyway, I tracked down the problem -- the PLL isn't running. At all.
ExtClkIn is toggling at 20MHz as it's supposed to, but the PLL never
locks. All the internal logic runs off the PLL, including the Parallel
Master Port. No PLL means no clock, no PMP function, basically "He's
DEAD, Jim!"

Now I need to figure out why I have two EP2C8As with dead PLLs. Then
replace them. Those things are a pig to desolder, even with a hot-air
station...

This isn't a problem I've seen in any of my designs so I'm afraid I can't
offer any words of wisdom. Have you scoped your supply rails?

I'd be careful to track down the problem so you know it isn't that something is
marginal though. You don't want more units to start failing in the field.


Nial.