Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12690 Discussions

Terasic DE2 - GPIO-Headers won't work

Altera_Forum
Honored Contributor II
2,092 Views

Hello 

 

I'm using the DE2 board and just wanted to implement the GPIO-Headers to connect external components. 

 

Before I begin to build own logics in VHDL and/or implement access to the ports in Linux, I'm just trying the basics, accessing the GPIOs as PIO with tutorials like the hello_led. 

 

I took the DE2_NET Image, copied it to my harddrive, removed the write protection attribute from all files, opened the SOPC-Builder and added two PIOs with 32 bit I/O Width. The first as an output port (named GPIO_0) and the second as as an input port (named GPIO_1). Then I generated the system in the SOPC-Builder and started compiling it in Quartus II 6.0. After compiling it, I checked the pinout file in the compilation report and found that the output pins of the Cyclone II chip where mapped to the according pins for GPIO correctly (GPIO_0[0] to D25, GPIO_0[1] to J22, ...). When making a new hello_led, the system.h also contains the right addresses for the two GPIOs. So I think it should work. 

 

But it does not work. 

 

e.g. writing to the green LED PIO, like in the hello_led 

IOWR_ALTERA_AVALON_PIO_DATA(LED_GREEN_BASE, led); 

everything works fine. 

 

When reading from the switch PIO and writing this to the red LED PIO like: 

led2=IORD_ALTERA_AVALON_PIO_DATA(SWITCH_PIO_BASE); 

IOWR_ALTERA_AVALON_PIO_DATA(LED_RED_BASE, led2); 

everything works fine. 

 

But when I connect the one PIO to the other PIO using a 40-conductor IDE-cable (red conductor showing to the top of the board on both connectors, so it's not twisted 180 degrees but correctly connected) and writing to GPIO_0, then reading from GPIO_1 and then writing this to the LEDs, like: 

IOWR_ALTERA_AVALON_PIO_DATA(GPIO_0_BASE, led); 

led2=IORD_ALTERA_AVALON_PIO_DATA(GPIO_1_BASE); 

IOWR_ALTERA_AVALON_PIO_DATA(LED_RED_BASE, led2); 

nothing happens. 

 

I also tried to configure the GPIOs as bidirectional ports. Then, depending on which I write to and which port I read from, I ged all LEDs on or all LEDs off. 

 

Then I configured both ports as output only and connected a voltmeter to the output ports. 

 

When connecting the ground cable to the ground port of the IO header and the other cable to the +5V or +3.3V pin on the header, I correctly get +5V or +3.3V. But when connecting the cable to one of the data pins, the voltmeter is stuck at +0.7V. 

I took the variable which carries the left/right shifting bit from the hello_led Knight Rider Lightshow and wrote it to the two GPIO Ports which where both configured as output. To see where which bit is actually 1, I also wrote the variable to the green LEDs: 

IOWR_ALTERA_AVALON_PIO_DATA(GPIO_0_BASE, led); 

IOWR_ALTERA_AVALON_PIO_DATA(GPIO_1_BASE, led); 

IOWR_ALTERA_AVALON_PIO_DATA(LED_GREEN_BASE, led); 

I also made the delay longer, so the bit is shifted in a frequency of about 1-2 seconds only. 

 

When running this program, the green LEDs are blinking slowly left-right-left-right, but none of the output pins from the GPIO gives a sign. The voltmeter does not react, all data pins are stuck on 0.7V 

 

Any idea what's going wrong here?
0 Kudos
8 Replies
Altera_Forum
Honored Contributor II
956 Views

Hello Volker, in my dissertation project I am trying to use the GPIO Altera DE2 board, and also can not get any results. You could solve the problem? If yes, could you help me and explain how to realize such a procedure? I await answers. Thank you. A hug.

0 Kudos
Altera_Forum
Honored Contributor II
956 Views

 

--- Quote Start ---  

... and added two PIOs with 32 bit I/O Width. The first as an output port (named GPIO_0) and the second as as an input port (named GPIO_1). Then I generated the system in the SOPC-Builder and started compiling it in Quartus II 6.0. After compiling it, I checked the pinout file in the compilation report and found that the output pins of the Cyclone II chip where mapped to the according pins for GPIO correctly  

--- Quote End ---  

 

 

In your post, you state that you made the GPIOs as input/output, but it was not clear whether you connected them to input/output pins in Quartus. The different pin types function differently and will not work correctly unless you use the corresponding pins. 

 

If this is done correctly, it will also show up in the Pin Planner in the Direction column. 

 

If this is not the problem, I would suspect (since this is a development board, DE-2) that someone using it before you may have blown the IO by connecting it wrong. (I've actually seen users directly connect low-voltage IO to AC line voltage and wonder why it did not work anymore.) The boards have buffers to stop the damage from getting to the FPGA, but not without damaging the buffer.
0 Kudos
Altera_Forum
Honored Contributor II
956 Views

Dear donq first like to thank you for the reply and assistance. I did exactly what you mentioned. Using the SOPC builder prepending my hardware structure below the element, made the generation of project files HW (which was included in my file system.h) and run the compilation. 

 

 

//system.h 

---------------------------------------------------------------------- 

/* 

* gpio_0 configuration 

*/ 

# define GPIO_0_NAME "/dev/gpio_0"# define GPIO_0_TYPE "altera_avalon_pio"# define GPIO_0_BASE 0x00681110# define GPIO_0_SPAN 16# define GPIO_0_IRQ 6# define GPIO_0_DO_TEST_BENCH_WIRING 0# define GPIO_0_DRIVEN_SIM_VALUE 0# define GPIO_0_HAS_TRI 0# define GPIO_0_HAS_OUT 0# define GPIO_0_HAS_IN 1# define GPIO_0_CAPTURE 1# define GPIO_0_DATA_WIDTH 32# define GPIO_0_EDGE_TYPE "ANY"# define GPIO_0_IRQ_TYPE "EDGE"# define GPIO_0_BIT_CLEARING_EDGE_REGISTER 0# define GPIO_0_FREQ 100000000# define ALT_MODULE_CLASS_gpio_0 altera_avalon_pio 

 

---------------------------------------------------------------------- 

 

After the process of compiling the file checked Pin-Out was in line with the Pin Planner, and once again everything was ok.  

 

In the Nios, I created a basic design to test where I inserted the following C code:  

 

----------------------------------------------------------------------# include "system.h"# include "altera_avalon_pio_regs.h"# include "alt_types.h"# include <stdio.h> 

 

int main (void) __attribute__ ((weak, alias ("alt_main"))); 

 

int alt_main (void) { 

alt_u8 led = 0x2; 

volatile int i; 

 

while (1) { 

 

led = IORD_ALTERA_AVALON_PIO_DATA(GPIO_0_BASE); 

printf("GPIO = %d\n", led); 

IOWR_ALTERA_AVALON_PIO_DATA(LED_GREEN_BASE, led); 

 

i = 0; 

while (i<200000) 

i++; 

 

return 0; 

 

---------------------------------------------------------------------- 

 

When running the application do the above test with the sensor to verify presence by detecting the presence the GPIO can get the correct answer, but the only result is:  

 

GPIO = 0  

GPIO = 0  

GPIO = 0  

...  

 

Remember, the sensor is powered by a 9v battery and the yellow wire (GND) of the same is connected to pin 12 of GPIO_0 (JP1) and green wire (Data) is connected to pin 1 of the same GPIO.  

 

Want to know what is wrong in my application NIOS and how do I do it?  

 

Again, thank you all.
0 Kudos
Altera_Forum
Honored Contributor II
956 Views

 

--- Quote Start ---  

Dear donq first like to thank you for the reply and assistance. I did exactly what you mentioned. Using the SOPC builder prepending my hardware structure below the element, made the generation of project files HW (which was included in my file system.h) and run the compilation. 

 

 

//system.h 

---------------------------------------------------------------------- 

/* 

* gpio_0 configuration 

*/ 

# define GPIO_0_NAME "/dev/gpio_0"# define GPIO_0_TYPE "altera_avalon_pio"# define GPIO_0_BASE 0x00681110# define GPIO_0_SPAN 16# define GPIO_0_IRQ 6# define GPIO_0_DO_TEST_BENCH_WIRING 0# define GPIO_0_DRIVEN_SIM_VALUE 0# define GPIO_0_HAS_TRI 0# define GPIO_0_HAS_OUT 0# define GPIO_0_HAS_IN 1# define GPIO_0_CAPTURE 1# define GPIO_0_DATA_WIDTH 32# define GPIO_0_EDGE_TYPE "ANY"# define GPIO_0_IRQ_TYPE "EDGE"# define GPIO_0_BIT_CLEARING_EDGE_REGISTER 0# define GPIO_0_FREQ 100000000# define ALT_MODULE_CLASS_gpio_0 altera_avalon_pio 

 

---------------------------------------------------------------------- 

 

After the process of compiling the file checked Pin-Out was in line with the Pin Planner, and once again everything was ok.  

 

In the Nios, I created a basic design to test where I inserted the following C code:  

 

----------------------------------------------------------------------# include "system.h"# include "altera_avalon_pio_regs.h"# include "alt_types.h"# include <stdio.h> 

 

int main (void) __attribute__ ((weak, alias ("alt_main"))); 

 

int alt_main (void) { 

alt_u8 led = 0x2; 

volatile int i; 

 

while (1) { 

 

led = IORD_ALTERA_AVALON_PIO_DATA(GPIO_0_BASE); 

printf("GPIO = %d\n", led); 

IOWR_ALTERA_AVALON_PIO_DATA(LED_GREEN_BASE, led); 

 

i = 0; 

while (i<200000) 

i++; 

 

return 0; 

 

---------------------------------------------------------------------- 

 

When running the application do the above test with the sensor to verify presence by detecting the presence the GPIO can get the correct answer, but the only result is:  

 

GPIO = 0  

GPIO = 0  

GPIO = 0  

...  

 

Remember, the sensor is powered by a 9v battery and the yellow wire (GND) of the same is connected to pin 12 of GPIO_0 (JP1) and green wire (Data) is connected to pin 1 of the same GPIO.  

 

Want to know what is wrong in my application NIOS and how do I do it?  

 

Again, thank you all. 

--- Quote End ---  

 

It is noteworthy that in my file Pin-Out all GPIO_0 [n] holds the same values for the fields "Dir.:", I/O Standard:, Voltage:, I/O Bank:, User Assignment" 

 

--------------------------------------------------------------------------------- 

-- Pin directions (input, output or bidir) are based on device operating in user mode. 

--------------------------------------------------------------------------------- 

 

Quartus II Version 7.2 Build 151 09/26/2007 SJ Web Edition 

CHIP "DE2_NIOS" ASSIGNED TO AN: EP2C35F672C6 

 

Pin Name: Location: Dir.: I/O Standard: Voltage: I/O Bank: User Assignment 

------------------------------------------------------------------------------------------------------------- 

... 

GPIO_0[0]: D25 : bidir: 3.3-V LVTTL : : 5 : Y  

... 

 

Thank you.
0 Kudos
Altera_Forum
Honored Contributor II
956 Views

 

--- Quote Start ---  

 

... 

GPIO_0[0]: D25 : bidir: 3.3-V LVTTL : : 5 : Y  

... 

 

--- Quote End ---  

 

 

Not quite able to follow all of that, but the quoted line above seems to show that your pins are bidir. This will not work unless connected to devices (like a GPIO) with bidir pins. You earlier stated that you have separate input and output GPIOs. These should have been separately created with inputs and outputs. If you have created a bidir GPIO, go back and undo it. For bidir, there are extra steps you must do to control the direction and it will only cause problems for you now. 

 

With separate input and output GPIOs, you must connect the output pins from the output GPIO to output pin symbols on the Quartus page, and input GPIO pins to input pin symbols. These look different from each other (and different from bidir pins). If the pins on the Quartus page do not look different, you must fix it there. 

 

Then, after you run the Quartus compiler, you will get something in the pin-planner that looks like this (these are different pins because it is an excerpt from one of my projects, different purpose, different FPGA, etc., but the concept is the same). 

 

NodeName Direction Location I/O Standard FLASH_RW_N Output PIN_W32 3.3-V LVTTL FLASH_WP_N Output PIN_Y30 3.3-V LVTTL i_PhyInt Input PIN_Y27 3.3-V LVCMOS i_PhyLinkOn Input PIN_V29 3.3-V LVCMOS io_PhyCTL Bidir PIN_W24 3.3-V LVCMOS io_PhyCTL Bidir PIN_W25 3.3-V LVCMOS If you do not see input, output and bidir, each where they need to be, it will not work.
0 Kudos
Altera_Forum
Honored Contributor II
956 Views

donq posting below is how my settings on GPIO SOPC Builder, ie, input port only. The problem is when compiling the file and check Pin-Out everything related to GPIO_0 is bidirectional. How can I solve this problem. Thank you.

0 Kudos
Altera_Forum
Honored Contributor II
956 Views

 

--- Quote Start ---  

donq posting below is how my settings on GPIO SOPC Builder, ie, input port only. The problem is when compiling the file and check Pin-Out everything related to GPIO_0 is bidirectional. How can I solve this problem. Thank you. 

--- Quote End ---  

 

 

By carefully reading all the way to paragraph 2 of my previous reply. 

 

 

--- Quote Start ---  

...you must connect the output pins from the output GPIO to output pin symbols on the Quartus page... 

--- Quote End ---  

This is the main block diagram / symbolic design page, where you edit the BDF file.  

 

If you continue to have problems at this level, I might suggest that you do one of the tutorials...
0 Kudos
Altera_Forum
Honored Contributor II
956 Views

Dear donq, let me report to you and all who argued that access this topic that could solve my problem, as you mentioned, the solution is to embed the inputs and outputs corresponding to each element of hardware inserted into the design in SOPC Builder file project_name.bdf (schematic) of the Quartus II project. Remembering where we have the file project_name.bdf not need the general configuration file project_name.v. I want to thank in particular the donq for their patience and availability. Thanks buddy.

0 Kudos
Reply