Run and debug nios project

Altera_Forum · ‎10-05-2010

Hello,

I am running a c file on niosii to check if the LEDs are working or not using buttons.

This is my C file:

#include <stdio.h> // for uart# include <unistd.h> // for uart read(), open()# include <stddef.h> // for uart# include <fcntl.h> // for uart# include "altera_avalon_pio_regs.h" // pio access# include "system.h"

int main(void)

{

alt_u8 button_pio_value = 0;

alt_u32 led_counter = 0;

alt_u8 led_counter2 = 0;

alt_u8 led_on = 0;

printf("hello world\n");

while(1)

{

button_pio_value = iord_altera_avalon_pio_data(button_pio_base);

led_counter++;

if (led_counter == 500000)

{

led_counter = 0;

led_counter2++;

switch (button_pio_value)

{

case 0: led_on = led_counter2 % 16; break;

case 1: led_on = (led_counter2 % 16) + 16; printf("button 1 pressed\n"); break;

case 2: led_on = (led_counter2 % 16) + 32; printf("button 2 pressed\n"); break;

case 4: led_on = (led_counter2 % 16) + 64; printf("button 3 pressed\n"); break;

case 8: led_on = (led_counter2 % 16) + 128; printf("button 4 pressed\n"); break;

default: led_on = led_counter2 % 16; break;

}

iowr_altera_avalon_pio_data(led_pio_base, led_on);

} // if

} // while

return 0;

}

problems:

1) I am supposed to use the buttons after running the project and see the LEDs blinking, but they didnt and i see this message in the console

nios2-terminal: connected to hardware target using jtag uart on cable

nios2-terminal: "usb-blaster [usb-0]", device 1, instance 0

nios2-terminal: (use the ide stop button or ctrl-c to terminate)

2) I am trying to debug and i put two breakpoints one in front of the printf and another one in front of the switch. The problem is that i cannot go to each breakpoint to see what is happening. I see only two right mark beside the bullets and the program is still running.

I think: there is somthing wrong with the loops but this program is already tested by altera and i am just doing the steps to build and test.

please if anyone have an idea, please help,

thanks

Altera_Forum · ‎10-05-2010

I found one warning in the SOPC and maybe this warning cause the problem..

warning: button_pio: pio inputs are not hardwired in test bench. undefined values will be read from pio inputs during simulation.

But in some other forums it says that there is no problem to have this warning.

I used the generated PTF file generated from SOPC in NIOSII as target hardware.

Maybe now it is clearer than before.

You will find attached the sopc and the quartus files....

thanks

Altera_Forum · ‎10-05-2010

Hi,

the message in the sopc builder is surely not your problem.

For a short test go to the "Nios II C/C++ perspective" in your project. Riht click on your project (not the syslib) and chosse under "Debug As" the "Nios II Hardware". Your project should stop at the beginging of your code.

Altera_Forum · ‎10-05-2010

hi JacoL,

I removed the breakpoints and did like u said... you will find a picture of my debugging prespective in the attchements....

Altera_Forum · ‎10-05-2010

Ok,

I just thought about another problem I had similar to you. Right click on your Project,open "System Library Properties" and check stdout, stderr, stdin. "jtag_uart" should be entered here.

Altera_Forum · ‎10-05-2010

I did it also because it was in the tutorial that i am working on.

I am stucked in step 10 in lab2 in the attached PDF which I am supposed to see the LEDs blinking.

Then i thought maybe i will understand what is the problem if i debug.

So the main problem that when i run NIOS II hardware, the buttons are not working...

Altera_Forum · ‎10-05-2010

IMHO your program doesn't even start or it doesn't reach the main() function. You probably have a problem with hw configuration/initialization.

System initialization is performed by the alt_main() function which then calls your application main().

Try this:

- compile the syslib in debug mode

- search in Altera components for alt_main() function in alt_main.c file.

- place a breakpoint at the very beginning of alt_main and start debugging; the step into the code and you should see where it gets stuck.

Cris

Altera_Forum · ‎10-05-2010

An alternative to get this breakpoint is to got to Run->Debug... ->Debugger and place the check mark:

Altera_Forum · ‎10-05-2010

I did the debugging stuff with alt_main()... and i will explain the output as pictures...

1) after i run the debugging i have pic0

2) after one step into i have pic1

3) if i keep press step into till it stops, i have pic2

also i tried another thing without the a breakpoint in alt_main() and i tried to pause the debugging in the middle and i found pic3

Altera_Forum · ‎10-05-2010

You are definitely using a system timer (SYS_CLK_TIMER, I presume) with an abnormally small period, so it continuosly triggers the irq; in other words, the timer period is shorter than the time required for isr (alt_tick).

You should check this period in sopc builder. Alternatively you can select the other timer as system timer in syslib properties.

Altera_Forum · ‎10-05-2010

yes i am using i sys_clk_timer...

period: 1 us

counter size 32bits

but the lab tutorial said that i have to use this timer and i am not supposed to use the other timer wich is high_res_timer (we are going to use it later)

i tried also the other timer that i have but it didnt work...

so should i increase this 1 us or?

i have another question...what does it mean that soursce not found in pic1??

Altera_Forum · ‎10-05-2010

btw the other timer is also 1 us

Altera_Forum · ‎10-05-2010

You can't use 1us period! The processor can't operate with so a high rate of interrupt. At fclk=50MHz that would mean only 50 cycles!!!

You must modify timer in sopc builder, regenerate the system and recompile the fpga design.

You should use a period 100us or greater. Usually a 1ms period is pretty enough for most applications.

Cris

Altera_Forum · ‎10-05-2010

Cris: this is the second time to solve my problems...

thanks for your help, and be ready for tomorrow questions :D

Also, i would like to thank JacoL for your participation and help