I have managed to upload a very simple Verilog design which simply illuminates an LED when a button is pressed. I have the LED connected to G16 and this pin sources current into the LED. All is well except that the voltage high from this pin is only 2v5 and I was expecting 3v3. The schematic shows the VCCIO pins G14 and E14 (bank 6 supply pins) as connected to 3v3. The 3v3 voltage is within specification. Can anyone shed some light on this?
Few ideas to check - SAMD should not have its pin PA20 configured as output, and fpga design must have G16 configured in push-pull mode, and not as open collector with pullup.
PA20 is set as an input. I could not see the "push-pull" option in
Quartus. The pin is set to "3.3-V LVTTL". It is not set as open
collector as it is driving albeit at 2.5v.
The 2.5v could be explained by having the pullup on either FPGA or SAMD (like PA20 set to input with pullup enabled) sourcing some current into the LED that has 2.5v forward voltage, so the 2.5v is defined by the LED properties, and not by the real output voltage of FPGA. Which might suggest the G16 is not properly assigned in FPGA design.
Can you post the fitter report?
Do you have a current limiting resistor in series with LED?
There is a 360R resistor in series with the LED. The value was picked on
the basis of a 3v3 so it is dim but functional. The voltage goes from 0v
to 2.5v if I press the button (it is a very simple design). I have
controlled this LED via the SAMD and the LED is nice and bright then. To
disable the SAMD from interfering I execute this line in the firmware:
pinMode(USER_LED, INPUT);
I have to admit that this is my first attempt with an FPGA. I am
experienced with embedded processors.
I have attached the fitter report, I appreciate you help.
(Attachment MKRVIDOR4000.fit.rpt is missing)
Previous attachment rejected.
MKRVIDOR4000.txt (183 KB)
Looks ok to me. G16 is reported as output pin assigned by user and it's not open drain, so must source the current.
Can you show the toplevel file? Just to make sure you're not driving the LED directly with some clock signal, this also can make the voltage appear lower when measured with multimeter and not with oscilloscope.
Both RTL and tech-map views are looking absolutely straightforward, there's nothing wrong with the resulting design logic. The issue must be caused by external conditions.
You are quite right. I disconnected the pin from the load and the voltage rose to 3v3. The load is the LED followed by a 360R resistor to ground. I measured the current flowing and found it to be 0.02 mA (the voltage across the resistor was 0.007v). Given that the current capability for this pin is 4mA or 8mA (and was set to 8mA) I cannot see why the voltage is being pulled down. It is as though the current drive is not what it should be. As I was concerned that I had damaged the board I borrowed another and tried that. The result is the same. Even if the pin reaches 3v3 then the current drawn will be about 2mA. So I am still no further forward.
Can you relocate the LED port to other pin, just for the sake of test completeness?
Such tiny current could be explained if the led is powered via weak pullup, and not via pin driver.
This might happen if the design present in FPGA is not exactly the one you think it is. Sometimes I have issues when uploading the sketch I don't have the fpga image properly updated, like Arduino IDE did not found difference in image CRC and decided it was not changed.
Alternatively let the pin sink the source, put the led anode to 3.3v vccio and let FPGA pin pull the ballast resistor to the ground.
I used the pin planner to move this output from G16 to T3. I then connected the LED to pin 14 of J4. The resulting app.h file was different but the LED behaviour did not change state when I uploaded the project. So there is something amiss somewhere. The LED did glow as expected and T3 remained at 3v3. The output is mapped to T3 as this can be seen by opening the pin planner after compilation and looking at "Fitter Location". I have changed my very simple circuit to invert the behaviour of the LED and this did not change once uploaded so I do not think I am driving this output at all. I will have to do some more reading on the limitations of the pins and try and get this to work.
Btw, you can try USBBlaster library and USB_Blaster sketch to make your life simpler when testing FPGA designs. It will not program the configuration flash, but .sof files will be uploaded directly into FPGA, saving you time on recompiling/reflashing from Arduino IDE.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.