"Ghosting" on LogicStart's seven-segment display

[Cactus]

Hi,

After taking the baby steps with my brand new Papilio One + LogicStart and playing around with it, I've noticed now that there's a weird ghosting effect going on with the rightmost digit of the seven-segment display: if I set any of the other anodes to low and the rightmost one to high, the segments of the rightmost one still light up faintly. This doesn't happen with any of the other digits.

Now, of course I first thought it was my time-multiplexing code that was wrong, but it even happens with the simplest possible static code:

  SS_DP <= '1';
  SS_ANODES <= "0111";
  SS_SEGS <= "1010101";

This will light up the first digit with a wierd Y-like shape, but will also light up the fourth one slightly.

This started happening after a couple of weeks, and I haven't disassembled and reassembled the LogicStart megawing from the main FPGA board in the meantime, so it kinda just started happening overnight.

Any ideas what this could be? How I could fix it? Please note that it might not be easy for me to get access to a multimeter.

Thanks!

[Jack Gassett]

Hello Cactus,

I'm guessing it is probably just the code, but lets try to establish for sure if that is the case. If you have a Papilio One 500K I just created a new article that walks you through loading a test bit file to the board. If you have a Papilio One 250K let me know, we will need to generate a ZPUino LogicStart variant bit file for it.

Load the bit file and let's see if there is ghosting with the test bit file.

Thanks,

Jack.

[Cactus]

Hi Jack,

Thanks for the quick reply!

Unfortunately, the download link for the .bit file on that page gives me a permission error.

Thanks,

Gergo

[Cactus]

Oh and BTW here's a test circuit I've been using:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use work.lava.all;
use work.all;
entity hello is
  port(SWITCH : in std_logic_vector(7 downto 0);
       SS_DP : out std_logic;
       SS_ANODES : out std_logic_vector(3 downto 0);
       SS_SEGS : out std_logic_vector(6 downto 0));
end entity hello;
architecture str of hello is
begin
  SS_DP <= '1';
  SS_ANODES <= not SWITCH(3 downto 0);
  SS_SEGS <= "1010101";
end architecture str;

With this, I can see that digit #4 flickers (with quite the light intensity) when all of the other digits are turned off (incl. #4), and the flickering remains but the brightness goes down considerably as other digits are turned on with the switches.

Unfortunately, I can't see how that could be a software issue:(

[Jack Gassett]

Does the download link work now?

If not I attached the bit file to this message.

Jack.

LogicStart_QuickStart-1.0-zpuino-1.0-PapilioOne-S3E500-LogicStart-VGAZX.bit

[hamster]

Hi Cactus,

Your code looks great - what is in your UCF file?

Mike

[Cactus]

Hi Jack,

What am I supposed to see after uploading this .bit file to the device? I thought I'd see the LEDs lighting up and the seven-segment display showing some number I can change with the directional buttons -- but I don't see any of this after installing your .bit file: all the LEDs are off and the seven-segment display is empty as well (for reference, the command I used was:

sudo ~/bin/papilio-prog -f ~/Downloads/LogicStart_QuickStart-1.0-zpuino-1.0-PapilioOne-S3E500-LogicStart-VGAZX.bit 

[Cactus]

Hi Cactus,

Your code looks great - what is in your UCF file?

Mike

The UCF file should be pretty much standard. Sorry I couldn't figure out how to attach it, so here it is copy-pasted:

# Generated automatically by kansas-lava-cores
#["CLK_32MHZ","SWITCH<0>","SWITCH<1>","SWITCH<2>","SWITCH<3>","SWITCH<4>","SWITCH<5>","SWITCH<6>","SWITCH<7>","SS_DP","SS_ANODES<0>","SS_ANODES<1>","SS_ANODES<2>","SS_ANODES<3>","SS_SEGS<0>","SS_SEGS<1>","SS_SEGS<2>","SS_SEGS<3>","SS_SEGS<4>","SS_SEGS<5>","SS_SEGS<6>"]
# Clock
# NET "CLK_32MHZ" LOC = "P89" | IOSTANDARD = LVCMOS25 | PERIOD=31.25ns;

# 7-segment display

NET "SS_ANODES<0>" LOC="P67" | IOSTANDARD=LVTTL;
NET "SS_ANODES<1>" LOC="P60" | IOSTANDARD=LVTTL;
NET "SS_ANODES<2>" LOC="P26" | IOSTANDARD=LVTTL;
NET "SS_ANODES<3>" LOC="P18" | IOSTANDARD=LVTTL;

NET "SS_SEGS<6>" LOC="P62" | IOSTANDARD=LVTTL;
NET "SS_SEGS<5>" LOC="P35" | IOSTANDARD=LVTTL;
NET "SS_SEGS<4>" LOC="P33" | IOSTANDARD=LVTTL;
NET "SS_SEGS<3>" LOC="P53" | IOSTANDARD=LVTTL;
NET "SS_SEGS<2>" LOC="P40" | IOSTANDARD=LVTTL;
NET "SS_SEGS<1>" LOC="P65" | IOSTANDARD=LVTTL;
NET "SS_SEGS<0>" LOC="P57" | IOSTANDARD=LVTTL;
NET "SS_DP"      LOC="P23" | IOSTANDARD=LVTTL;

# Joystick
# -- NET "BTN_UP"      LOC="P25";
# -- NET "BTN_DOWN"    LOC="P32";
# -- NET "BTN_LEFT"    LOC="P34";
# -- NET "BTN_RIGHT"   LOC="P36";
# -- NET "BTN_CENTER"  LOC="P22";

# Input SW
NET "SWITCH<7>" LOC = "P91" | IOSTANDARD=LVTTL;
NET "SWITCH<6>" LOC = "P92" | IOSTANDARD=LVTTL;
NET "SWITCH<5>" LOC = "P94" | IOSTANDARD=LVTTL;
NET "SWITCH<4>" LOC = "P95" | IOSTANDARD=LVTTL;
NET "SWITCH<3>" LOC = "P98" | IOSTANDARD=LVTTL;
NET "SWITCH<2>" LOC = "P2"  | IOSTANDARD=LVTTL;
NET "SWITCH<1>" LOC = "P3"  | IOSTANDARD=LVTTL;
NET "SWITCH<0>" LOC = "P4"  | IOSTANDARD=LVTTL;

# LEDs
# -- NET "LED<0>" LOC = "P17";
# -- NET "LED<1>" LOC = "P16";
# -- NET "LED<2>" LOC = "P15";
# -- NET "LED<3>" LOC = "P12";
# -- NET "LED<4>" LOC = "P11";
# -- NET "LED<5>" LOC = "P10";
# -- NET "LED<6>" LOC = "P9";
# -- NET "LED<7>" LOC = "P5";

[hamster]

Your UCF file matches with mine, so that should not be a problem. Q1 through Q4 (just below the display) switch the digits off and on. Is the one driving digit 4 sensitive to a bit of a gentle finger prod?

The ground pin at the top right of the board is directly above Anode3. Is it nice and clean? Crud around there might be dragging the anode low, and turning the display on...

Also, if you remove the LogicStart, turn it around 180 degrees and plug it back in then Wing C will now drive the 7seg (rather than the LEDs and Switches). Maybe you could use that to check if it is the pin on the Papilio One is at fault?

Oh, and if you do flip it around remember that the pins now run the other way round, so A0 becomes C15, A1 becomes C14 and so on...

[Cactus]

Your UCF file matches with mine, so that should not be a problem. Q1 through Q4 (just below the display) switch the digits off and on. Is the one driving digit 4 sensitive to a bit of a gentle finger prod?

So I uploaded two videos demonstrating the problem, complete with my horrible English pronunciation! The first one is me going through the test app from above, and the second one is just a better recording of the flickering:

http://www.youtube.com/watch?v=Wziss5nQ-EQ

I'd like to try turning the board around, but I'm afraid driving output pins as input and vice verse may damage the circuit (or is that a stupid concern?). So instead of experimenting, I'd like to try that only when you or someone else gives me a UCF file for that orientation...

[Cactus]

OK so I figured out the rotated UCF file on my own, based on http://www.gadgetfactory.net/blog/wp-content/uploads/2011/02/Papilio_Pins.png:

# 7-segment display

NET "SS_ANODES<0>" LOC="P11" | IOSTANDARD=LVTTL;
NET "SS_ANODES<1>" LOC="P5" | IOSTANDARD=LVTTL;
NET "SS_ANODES<2>" LOC="P94" | IOSTANDARD=LVTTL;
NET "SS_ANODES<3>" LOC="P91" | IOSTANDARD=LVTTL;

NET "SS_SEGS<6>" LOC="P9" | IOSTANDARD=LVTTL;
NET "SS_SEGS<5>" LOC="P98" | IOSTANDARD=LVTTL;
NET "SS_SEGS<4>" LOC="P95" | IOSTANDARD=LVTTL;
NET "SS_SEGS<3>" LOC="P3" | IOSTANDARD=LVTTL;
NET "SS_SEGS<2>" LOC="P2" | IOSTANDARD=LVTTL;
NET "SS_SEGS<1>" LOC="P10" | IOSTANDARD=LVTTL;
NET "SS_SEGS<0>" LOC="P4" | IOSTANDARD=LVTTL;
NET "SS_DP"      LOC="P92" | IOSTANDARD=LVTTL;

# Input SW
NET "SWITCH<7>" LOC = "P18" | IOSTANDARD=LVTTL;
NET "SWITCH<6>" LOC = "P23" | IOSTANDARD=LVTTL;
NET "SWITCH<5>" LOC = "P26" | IOSTANDARD=LVTTL;
NET "SWITCH<4>" LOC = "P33" | IOSTANDARD=LVTTL;
NET "SWITCH<3>" LOC = "P35" | IOSTANDARD=LVTTL;
NET "SWITCH<2>" LOC = "P40"  | IOSTANDARD=LVTTL;
NET "SWITCH<1>" LOC = "P53"  | IOSTANDARD=LVTTL;
NET "SWITCH<0>" LOC = "P57"  | IOSTANDARD=LVTTL;

With this setup, I get the exact same ghosting issue, which I guess means the problem is on the LogicStart, not on the main board (which I guess is good news if it turns out I need to replace it)

[Jack Gassett]

Hi Jack,

What am I supposed to see after uploading this .bit file to the device? I thought I'd see the LEDs lighting up and the seven-segment display showing some number I can change with the directional buttons -- but I don't see any of this after installing your .bit file: all the LEDs are off and the seven-segment display is empty as well (for reference, the command I used was:

sudo ~/bin/papilio-prog -f ~/Downloads/LogicStart_QuickStart-1.0-zpuino-1.0-PapilioOne-S3E500-LogicStart-VGAZX.bit 

Cactus, this ZPUino bit file has code and data appended to the end of it and needs to be loaded into SPI flash to work correctly. Should be something like:

sudo ~/bin/papilio-prog -b bscan_spi_xc3s500e.bit -f ~/Downloads/LogicStart_QuickStart-1.0-zpuino-1.0-PapilioOne-S3E500-LogicStart-VGAZX.bit -sa 

You will need to find the bscan_spi_xc3s500e.bit file somewhere with the source code you downloaded for paplio-prog.

Jack.

[Cactus]

sudo ~/bin/papilio-prog -b bscan_spi_xc3s500e.bit -f ~/Downloads/LogicStart_QuickStart-1.0-zpuino-1.0-PapilioOne-S3E500-LogicStart-VGAZX.bit -sa 

Jack.

Hi Jack,

Thanks, I got it working with this (although I didn't check the VGA output). Unfortunately, the flickering ghosting issue remains. I am now sure it is a hardware issue.

Is there something I can do to fix this, or do I just need to write it off and order a new one?

Thanks,

Cactus

[Jack Gassett]

Cactus,

I agree, it looks like a hardware issue. No need to write the board off, we will make sure you get a board that works correctly. We just sold out of the LogicStart MegaWing and are waiting for the next batch from our manufacturer. I can make sure the first board from the next batch goes to you to replace the faulty board but I'm not sure how soon that will be. I will ask for an update from our manufacturer on Monday. In the meantime, if you are handy with soldering, I can send you a replacement transistor and 7-segment display right away. I'll contact you with a private message once I know the time frame for the next batch of boards to work out the details.

Very sorry for the inconvenience.

Jack

[alex]

I'll pipe in with my 2c here. The OP mentioned this problem wasn't there to start with but appeared later. Because of that I'd tend to exclude things like dirt on the base of the transistor holding it half open. From the video the transistor still seems to switch on/off so it doesn't appear totally dead. I would suggest just for the lulz to put some pulldowns on the FPGA ucf file, eg: NET "SS_ANODES<3>" LOC="P91"| IOSTANDARD=LVTTL | PULLDOWN; and see how that works, may help with switching the transistor further off.

Also from the video I noticed the display is bright as fark so I checked the schema and I'm a little puzzled, I don't see any current limiting resistors on the 7-seg display. I don't know the part number for the display is so I can't check to see the electrical specs. The transistor is rated to 1/2 Amp so it's beefy enough but really that means with a 3.3V supply, and say .7v drop across the transistor we get 2.6V across the 7-seg LEDs, when in fact most yellow LEDs light up at approx 2.1V. The current is shared across all lit segments, so worst case scenario is only one segment lit, gets all the current. I'd expect say a 47R resistor in series with each segment for a 10mA current limit which will then have a constant current across each segment no matter how many of them are on.

Jack, can you clarify the electrical specs in this part of the circuit? I mean I know they're really designed to me multiplexed but the OP is in this case driving one of them hard at 100% duty cycle and I smell potential trouble if not a little smoke too

[hamster]

May be better to use "PULLUP" as it is active low - but the ghosting is definitely odd.

AFAIK the output drivers on the FPGA provide the current limiting - I felt this was a little dodgy, but when had discussions with others on this and they convinced me that this was perfectly fine as long as you keep within the TPD specs of the device. I still think that it might cause issues with noise on other pins in the same back, but that is just me!

I'm working on the assumption that it was videoed in a dark room....

[Jack Gassett]

Also from the video I noticed the display is bright as fark so I checked the schema and I'm a little puzzled, I don't see any current limiting resistors on the 7-seg display. I don't know the part number for the display is so I can't check to see the electrical specs. The transistor is rated to 1/2 Amp so it's beefy enough but really that means with a 3.3V supply, and say .7v drop across the transistor we get 2.6V across the 7-seg LEDs, when in fact most yellow LEDs light up at approx 2.1V. The current is shared across all lit segments, so worst case scenario is only one segment lit, gets all the current. I'd expect say a 47R resistor in series with each segment for a 10mA current limit which will then have a constant current across each segment no matter how many of them are on.

Jack, can you clarify the electrical specs in this part of the circuit? I mean I know they're really designed to me multiplexed but the OP is in this case driving one of them hard at 100% duty cycle and I smell potential trouble if not a little smoke too

Alex, you are pretty much dead on with most of the electrical specs, the 7-seg datasheet is here. When I designed the LogicStart my initial thought was that we needed current limiting resistors. Then I looked at Xilinx reference designs that used 7-seg displays and saw that they did not include current limiting resistors... I figured that multiplexing the signal, which is needed to control all 4 segments at the same time, would control the current at acceptable levels. But unfortunately that does not account for a "worst case" scenario like this where the full current provided by the transistor, up to 500mA, can be applied to one segment at 100% duty cycle. It's way above the specs of the 7-segment LED... I think I need to rework the design to account for this type of "worst case" scenario going forward by adding in the current limiting resistors. In the meantime, I'm going to move to a transistor that has an Ic maximum of 25mA instead of 500mA. The 7-seg LED has a typical current of 20mA and max current of 30mA so I think this should make things safer in the current design.

Jack.

[alex]

Not sure how an Ic(max)=25mA will work for you unless you plan to use that transistor as a fuse . Remember that one transistor must handle driving up to 8 lit segments incl dp.

To be honest, I'd bang in 33R resistors in series with each segment and stay with current transistor. This way you drive each segment with max 15mA (half of the max rating) while the transistor can still handle 8 segments x 15mA each = 120mA max at 100% duty cycle.

Or you could go as low as 22R, while still being well within the statically safe area but increasing the brightness a bit for when muxing, as each digit will see 25% of max drive current on average at 1:4 mux ratio.

[Cactus]

Cactus,

I agree, it looks like a hardware issue. No need to write the board off, we will make sure you get a board that works correctly.

Hi Jack,

Wow, that sounds like awesome service! However, I'm in no hurry (I can work on my lame projects with just 3 digits for now), and so I'd prefer to wait for you guys to figure out if the current is limited enough with the current design; if not, I'd rather wait for the next iteration of the design to be manifactured.

To answer other questions:

• The video was recorded in a room at night, but with the lights on
  
• Is the transistor dirty -- how do I check? I've tried basically just running my finger over the exposed leads around the display.
  
• Does PULLUP/PULLDOWN on SS_ANODES<3> help -- not at all.
  
• When driving the digits with a constant work cycle, the brightness of the digits definitely depends on the number of digits turned on.
  

Thanks,

Gergo

[hamster]

I just dropped a meter on series with the B segment when driving two anodes (so lighting two LEDs) - seems to be pulling about 50 or 60ma in total (I've blown the low-range fuse on my meter...) so scratch my comment on drive strength.

I can't find any useful reference, but It seems to be that drive strength ensures that logical H and L levels will be within specified voltages when that level of current is being draw from the pin... my apologies!

[hamster]

Hi Again. Must stop replying to myself... :-)

I'm looking through the datasheet (http://www.xilinx.co...heets/ds312.pdf) and see on page 120 that the minimum high voltage for (Voh Min) for LVTTL is 2.4V. As the transistor's emitter is at 3.3V line this is low enough that up to 0.9V bias could be put over it, switching it on even when the anode pin is a logic H. (this is worst case of course!).

Can you please try switching from LVTTL to LVCMOS33, where Voh min is Vcco-0.4, or 0.5V higher. This might ensure that the transistor is clamped shut, as only 0.4V of the approx 0.6V is needed to start it switching on is present...

If this is the case, I'm picking that the issue is your board has a transistor with a very low bias voltage - the datasheet has a typical device allows 1ma though when 0.6v is present @ 25C, and down to 0.4V @ 125C. I might try touching a transistor with an iron, and see if I can bring the ghost to life :-)

[hamster]

Had a look at this tonight. The difference between LVCMOS33 and LVTTL is minimal. The most current sunk by the I/O pin into an LED seems to be about 60ma, so the design is slightly over spec if you drive only one segment at 100%, but driving a few segments on the same line will be fine.

I see a possible failure that could have caused your issue. If the Anode0 (WIng A, pin 0) shorts to the GND pin next to it it will drag the transistor's base to 0V while the emitter is tied to the 3.3V rail. This could draw enough current through the transistor to damage it (although the FPGA won't be hurt by dragging a pin low).

Hopefully the 3.3V regulator would hit it's current limit first, but that seems to be around 200mA. Maybe 200mA is enough to cook it? I would expect it to die open circuit, rather than to stick slightly on.

This 'feature' can be avoided with a revision to the LogicStart, The best way would be to include a current limiting resistor on the base of the transistor - because of the transistor's current gain only a mA is required for switching on each of the LED segments, Something around 220 Ohm should be fine, limiting the fault current to less than (3.3V -0.6V)/(220 Ohm) = 12mA,

Assuming the transistor's current gain is at worst 30 that will allow 360mA to flow through the transistor (45mA for each segment). This would also drop the power draw through the pin in normal operation, which is currently metering at about 60mA per active anode (once again on my crappy meter).

The addition of a 47 Ohm resistor on each of the segment lines might also be a good idea, as it limits the current through each segment to about 50mA, but it looks like the FPGA almost does that anyway. In normal operation this might be overkill, given that the anode should only be driven for 25% of the time anyway.

I haven't done any work with SMD resistors - are they speced for about 0,155mW ((3.3V-0.6V)^2 / 47) of heat?

[Cactus]

Hi guys,

I haven't had time to even plug my Papilio in for a month now (combination of illness and day-job deadlines), and today when I turned it on, the issue seems to be... gone. As if the fix was to just let the board lay around for about a month...

Is this a significant new clue?

[Jack Gassett]

Hmmm, it is pretty strange... I just got a new batch of LogicStart boards in so if you want to swap it out and have me look closer at that one then we can get the ball rolling on that now.

We are still working on the next revision of the LogicStart board, we are adding some other improvements. It will take a couple months before anything should be ready though.

Jack.

[alex]

Could it be that you had a solder ball shorting some pins and since then the solder ball must have dropped out through handling the board