Weak pull-up resistors

[Altera_Forum]

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, Nikola

[Altera_Forum]

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]

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]

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]

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

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]

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]

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]

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

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]

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.

[Altera_Forum]

Hi dsl, thanks for joining in to help me. That is the thing that I found strange when I started using the peripheral. When I connected it first to fpga without applying the power to it, I saw it was back-powered from the input lines. Can that cause a damage to the device? If the output of the peripheral is high and the input of the fpga is tri-stated, can that make a problem too?

[Altera_Forum]

I'm only a software engineer ! 

But at a previous job we had a board with quite a few separate power supplies, this caused quite a few 'back-powering' issues, especially why trying to get the main cpu into 'sleep' mode. We had to drive IO pins low (sometimes an 'active' state') before removing the power from the target.  Presumably you don't power the peripheral when the fpga in unpowered.

[Altera_Forum]

Hi Nikola, 

   --- Quote Start ---  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.  --- Quote End ---    What is the SPI device (post a link).  What is your circuit for connecting the SPI device to the FPGA, eg., do you have a separate power supply, or are you using a power pin on the FPGA kit?  You should really simulate your design. That is the only way you can really understand what logic levels are to be expected on the I/Os. Since you did not write the SPI controller, you either need to read the code, or simulate. Simulation is faster, and it will be more useful in the long run.  Cheers, Dave

[Altera_Forum]

Initially (before configuration), all FPGA pins are driven high (at least near to Vccio when considering leakage currents). When you say, they are not high initially, the pins are either pulled low externally, or you pull them low after configuration, which just means an unsuitable way to drive the pins in your code. 

 The only cases, where an external pull-up would be required is to override other external loads or for clock inputs, that don't have a pull-up.

[Altera_Forum]

Hello everyone, I think I finally found a solution to the problem. I used an external power supply to power my peripheral and that apparently caused the problem. Now I am using the power supply from the fpga board. I think I powered my peripheral after powering fpga, but since they were connected, the peripheral was back powered from I/O lines before applying the power to it. Thanks very much! Now I am going to test it properly to see if it works flawlessly.