Forum Discussion
Weak pull-up resistors
Hi everyone!
I enabled weak pull-ups for the input and output pin (cyclone II device). But when I measure the voltage on these pins, on the input pin is 3V and on the output pin is 0V. Shouldn't it be 3.3V for both? I haven't connected these pins to anything yet. I will use them for an external device. Thanks, Nikola15 Replies
- Altera_Forum
Honored Contributor
if you're driving the output low that would be the expected behavior
my initial thought was that weak pull up resistors only work on inputs, but i don't see anything in the documentation that actually says that what are you trying to do with pull ups on the outputs? - Altera_Forum
Honored Contributor
You have conflicting statements;
--- Quote Start --- I haven't connected these pins to anything yet. --- Quote End --- vs --- Quote Start --- I enabled weak pull-ups for the input and output pin (cyclone II device). --- Quote End --- If you haven't connected anything yet, then neither pin can be an output. If you have defined a top-level entity with your inputs and outputs listed, then the outputs will need to be driven. The low you see on the output can be due to you driving it, or, it can be due to a synthesis setting. Older generation devices had a default unused pin setting that would drive the unused signals as output to ground. Newer devices default to as inputs tri-state. To see what mode you are using, in Quartus, select Assignments->Device, Device and Pin Options, Unused Pins tab. Select as input tri-stated, and then place-and-route your design, and then re-measure your pins. Cheers, Dave - Altera_Forum
Honored Contributor
I'm am not driving the output pin low. I wanted just to check if it will be high after programming the device. The peripheral which I will connect the FPGA to requires the signal to be high. I use voltmeter to measure the voltage on the pins after programming the device. After compiling the project, there is one warning about the output pin that says: "Output pin is stuck at GND". I will follow your suggestion Dave and see if there are any changes.
Thanks, Nikola - Altera_Forum
Honored Contributor
--- Quote Start --- After compiling the project, there is one warning about the output pin that says: "Output pin is stuck at GND". --- Quote End --- Then it sounds like you have an output defined, but you have left it undriven, so Quartus has provided a default for you. Try this instead: unused_output <= 'Z'; Quartus will then warn you that it has used a permanently disabled tri-state. However, this will force your output to be tri-stated, and your weak pull-up will pull it high. Cheers, Dave - Altera_Forum
Honored Contributor
Hi Dave,
I defined the pin in the entity as GPIO: OUT STD_LOGIC := 'Z' and after programming the device, the output pin is pulled to 3V. I still wonder why it is not pulled to 3.3V, but anyway it is still better than pulling it to GND. Thanks! Nikola - Altera_Forum
Honored Contributor
Hi Nikola,
--- Quote Start --- I defined the pin in the entity as GPIO: OUT STD_LOGIC := 'Z' and after programming the device, the output pin is pulled to 3V. --- Quote End --- Great! --- Quote Start --- I still wonder why it is not pulled to 3.3V, but anyway it is still better than pulling it to GND. --- Quote End --- Try driving it high; is it still 3.0V or is it closer to 3.3V? Cheers, Dave - Altera_Forum
Honored Contributor
Hello Dave,
Thanks for the suggestion. When I drive it high, i.e. instead of 'Z' I write '1', the pin is initially 3.3V. What I also found out is that for SOPC builder components, I cannot define initial states like that. For instance, when I use SPI interface with Clock polarity = 1, Clock phase = 1, after programming the device, only SSn and SCLK are 3.3V. MISO is 3V and MOSI is 0V. MOSI becomes 3.3V in the idle state only after sending a byte via SPI. I have to figure out now how I can set all the lines to be 3.3V from the beginning. Nikola - Altera_Forum
Honored Contributor
--- Quote Start --- Thanks for the suggestion. When I drive it high, i.e. instead of 'Z' I write '1', the pin is initially 3.3V. --- Quote End --- Ok. This implies that the weak pull-up circuit just happens to generate a different logic high level. Its not worth worrying about. If you want a higher voltage, then you need to use an external pull-up, eg., 10K. --- Quote Start --- What I also found out is that for SOPC builder components, I cannot define initial states like that. For instance, when I use SPI interface with Clock polarity = 1, Clock phase = 1, after programming the device, only SSn and SCLK are 3.3V. MISO is 3V and MOSI is 0V. MOSI becomes 3.3V in the idle state only after sending a byte via SPI. I have to figure out now how I can set all the lines to be 3.3V from the beginning. --- Quote End --- Read the source code for the SPI controller. Somewhere in the reset logic will be the code that sets MOSI. Change it to output a logic high. Of course, now you have a non-standard install of the IP. Why do you care if the MOSI is low? SPI devices clock it in on the clock edges. Use SignalTap to trace an SPI transaction. You might find that MOSI does what you need when there are SPI clocks present. Or setup Modelsim and look at the signals. Cheers, Dave - Altera_Forum
Honored Contributor
According to the datasheet, the peripheral that I want to connect to my fpga should have all 4 SPI signals pulled high with internal pull-up. But when I power the peripheral up, only SDO (which should be connected to MISO) is high, the other signals are low. I wanted to make sure that pull-ups in the fpga are on initially, so that I do not cause any damage to the devices when I connect them because I don't know if the pull-ups are on initially in my peripheral.
- Altera_Forum
Honored Contributor
If that is true, you might have to use external pullups.
The fpga's internal pullups can't possibly be asserted until after the fpga itself is configured - which will be well after power is applied. I guess the pins are hi-Z until then. If the peripheral has a separate power supply, then the pulling the signals high from anywhere else will lead to the device being back-powered from its inputs.