[SOLVED] Altera FPGA LED stops blinking after loading the sof file

[sreevenkjan]

Hi all,

I am trying to load my Altera Arria - II FPGA with the .sof file generated. The loading is successful but the FPGA LEDs do not turn ON/blink. When I program the FPGA with an old .sof file it works. My question is can u tell me as to why does this happen??

Before programming the .sof file, I opened the .qpf project file, compiled it and tried loading the .sof file. However when my colleague did the same on this machine, it worked. Infact when I loaded the fpga with the .sof file generated by his machine it works. Could you guys tell me what should I do to correct it??..Does it have to do with Operating system??
We both use the same Quartus II 64-bit version 14.0.0 Build 200 software from Altera.

 

[mrflibble]

The way I translate your post:

"I did something, or maybe I did not do something. This process results in a .sof file. When I program that .sof file to the fpga the programming in itself is succesful, but the design does not do what I want. When I program an older .sof from somewhere this also programs succesfully, and as a bonus the led goes blinkie. A coworker also does something that creates a .sof file, and that also makes things blink."

That leads me to conclude that the "program fpga with .sof file" part works, which is good.

You also have an old .sof somewhere that does what you want. So at some point in time your design was okay, and the synth + PAR tools were able to create a working .sof file.

Only now for whatever reason the latest .sof doesn't work. This could be because your current design is incorrect. It could also be that the design is correct (because of course it is, and you did not make any changes. noone ever does ) but there are some intermediate files that mess things up.

Possible solution:
- clean project ==> all intermediate files so be removed.
- rerun everything from synthesis to place & route and generate .sof file
- check date stamps of files to make damn sure you have the right one
- retry the new .sof file
- profit?

If that does NOT work, give your latest FULL project to your coworker and let him run the above on his machine. If that suddenly results in things working then you have a problem. But I suspect the results will be the same for both machines.

Anyways, far too long, but I hope it helps.

 

[sreevenkjan]

Well I did try all possible solutions, well I have tried cleaning the project. Since the project is in a repository, it can be accessed by the colleagues at work. So basically I just did a subversion checkout into my system. Opened the project file .qpf, compiled it and tried loading the .sof file into the FPGA. It works for my colleague but does not work for me on my PC. Since I can access his machine .sof files. I tried loading his .sof file into the FPGA and it works perfectly. I hope I have made myself clear now.

thats why I am asking if it has got anything to do with system specifications??

 

[mrflibble]

It could very well be different settings and whatnot. I would say run a clean + full rerun on both machines, and then compare the logs. If there is something stupid such as you coworker has a local copy of whatever file it is which is not under version control then you can also have a situation like that. All I can say is do a really really clean run in a new location on both sides and then compare. And hopefully you have already checked installed versions of software on both sides.

To be sure, your colleague should make an entire new project + do a checkout there, and then recompile. And then you do the same on your machine. If you get different results then it is log reading time.

 

[sreevenkjan]

It could very well be different settings and whatnot. I would say run a clean + full rerun on both machines, and then compare the logs. If there is something stupid such as you coworker has a local copy of whatever file it is which is not under version control then you can also have a situation like that. All I can say is do a really really clean run in a new location on both sides and then compare. And hopefully you have already checked installed versions of software on both sides.

To be sure, your colleague should make an entire new project + do a checkout there, and then recompile. And then you do the same on your machine. If you get different results then it is log reading time.

Hi,

Well I was able to make the LED blink by loading the NIOS II with the firmware through eclipse compiler. However I was getting error with cygwin because I have a Windows 8.1 OS installed and after searching for solutions online, I installed an updated version of cygwin and loaded the quartus/cygwin/bin with the new updated bin files. So the current status is I solved this cygwin error but I have another error which is "make: ** Error : 127" and my .elf file is deleted from the project folder. Could you tell me what do I need to do with it?? I found that by adding the path of the quartus/cygwin/bin folder in the system variables would help. Unfortunately it does not work for me. Can you guys tell me what should I do??

 

[sreevenkjan]

well the problem is solved. The solution was to install next version of quartus 14.1. I had an older 14.0 version and was not compatible with the windows 8.1 OS. I had problems linking the BIN files of the quartus.