How to create a simple program that behave like a Nios IDE?

Altera_Forum · ‎07-13-2009

Good Morning

I have NIOS development board and I created a simple NIOS setup with memory and JTAG UART & LED. I already purchased the NIOS license so I have unlimited test time. I also use the Nios II IDE to create a simple hello world and LED blinking function. I can use the IDE to run the program on the physical hardware. This all works.

I want to write a simple program that behave like the IDE where it loads the program to the FPGA and direct the stdout to the JTAG_UART so I can read it back on my laptop.

Can anyone point me to an example or app notes? I think I need to access the USB-blaster but how and what library is out there?

Thank You for your help.

Victor

Altera_Forum · ‎07-13-2009

Victor,

I have some experience in this area as of late. You will need to do these things:

1. Build a SOPC project with an Avalon MM Tri-State bridge and a CFI (common flash interface) component. You will need this to store the NIOS program and to boot it up after hardware config. There is a tool for this in the NIOS IDE.

2. Compile hardware and place in serial configuration device (if you have one on the board). If not, I have included an app note for using the PFL (parallel flash loader) to store your hardware bitstream and the NIOS program both in flash.

3. You will need to write some sort of GUI or console application in your choice of Windows (I assume) development system. I created such an application using sample code posted on the NIOS forum website. I had to recompile the DLL for use with MS Visual Studio because it was created with the dlltool.exe in Cygwin. You don't have to use MS Visual Studio, you can use Cygwin and hack the attached code if you like, but most people are familiar with MSVC. I have also attached a cheat-sheet on how to convert the Cygwin created DLL and convert it to a MSVC dll for implicit calling. There are three (3) software projects that I have included using the jtag_atlantic.dll. One of these downloads images to the board, the other two are useful for learning how to create applications that talk to the jtag uart such as what you are suggesting.

All of this assumes that you know the functionality of your board such as type of fpga configuration devices, memory, and switch settings, and most importantly, using SOPC Builder to build a NIOS system with peripherals.

Unfortunately, I know of no one document that can explicitly tell you how to do what you are asking for. You will need to 'kluge' it together yourself using as much of the code that I have included as examples. The image download demo also includes the hardware configuration code. It was compiled recently in v9.1 of Quartus. This should give you a good idea on how a SOPC system is put together as well with the CFI and tri-state bridge components.

I hope the SW helps.

Rick

Altera_Forum · ‎07-13-2009

Thank you for your help.

Victor

Altera_Forum · ‎07-31-2009

Hi,

I am trying to convert the Image-download-application from Cygwin env to MSVC env. But IT FAILED!

I had create the jtag_atlantic.lib & jtag_atlantic.exp file using the guide "Cygwin2MSVC_dll.txt". I manage to follow till the last part and get stucks while compiling the source code under MSVC.

The error message we get is

jtag_atlantic.exp : warning LNK4070: /OUT:jtag_atlantic.dll directive in .EXP differs from output filename 'D:\TESTUSBFINALDES1\test\Debug\test.exe'; ignoring directive

jtag_atlantic.exp : fatal error LNK1310: Exports not supported for pure MSIL image

I NEED BIG HELP to understanding what wrong with my code.

Attached is the MSVC code done by me.

Also, I am a programming NOOB. Please help.

This is an interesting project. Thanks you for your guide.

Altera_Forum · ‎07-31-2009

Hi, I am trying to convert the Image-download-application from Cygwin env to MSVC env.

If we are choosing Windows-console mode in MSVC, the source code manage to compile successful

However, if we are choosing Windows 32 Application (with GUI), the source code could not compile.

Altera_Forum · ‎07-31-2009

--- Quote Start ---

Hi,

I am trying to convert the Image-download-application from Cygwin env to MSVC env. But IT FAILED!

I had create the jtag_atlantic.lib & jtag_atlantic.exp file using the guide "Cygwin2MSVC_dll.txt". I manage to follow till the last part and get stucks while compiling the source code under MSVC.

The error message we get is

jtag_atlantic.exp : warning LNK4070: /OUT:jtag_atlantic.dll directive in .EXP differs from output filename 'D:\TESTUSBFINALDES1\test\Debug\test.exe'; ignoring directive

jtag_atlantic.exp : fatal error LNK1310: Exports not supported for pure MSIL image

I NEED BIG HELP to understanding what wrong with my code.

Attached is the MSVC code done by me.

Also, I am a programming NOOB. Please help.

This is an interesting project. Thanks you for your guide.

--- Quote End ---

cooi23,

I really cannot help you with a linker problem without sitting next to you to determine the issue. However, if you followed the instructions given in Cygwin2MSVC_dll.txt properly, you would have noted that these instructions are for console use only. You cannot execute them inside MSVC environment. IOW, you need to open a command window with a path to the files to execute the conversion properly. You should have no problems converting the Cygwin version of the jtag_atlantic.dll into a MSVC version if you follow these instructions exactly. The Cygwin project code will compile directly under the MSVC environment with the corrrect dll conversion without any modifications. I have verified this. I would start with a simpler project such as the test application to define the problem.

Regarding using the converted dll in a GUI...

dlls created with the MSVC lib.exe utility should be called exactly the same whether being called from a GUI application or a console application.

If you continue to have problems in this area, my suggestion is to look up the specific linker error codes that you are having on www.msdn.com (http://www.msdn.com) to determine what they are telling you.

However, my bet is that you did not follow the instructions in Cygwin2MSVC_dll.txt exactly, or you started with a corrupted dll. You should be able to find a clean Cygwin version of jtag_atlantic.dll at: C:\altera\90(or whatever version you are using)\quartus\bin... I would copy this into a new folder by itself and using the command line, do the conversion as outlined in the instructions.

This needs to work first. BTW, do not rename the *.lib or *.exp file anything other than jtag_atlantic.lib or jtag_atlantic.exp. This is imperative. Also, when compiling your code, make the project a Win32 console application to start with. You should be able to directly import the Cygwin code (again, I would start with either the terminal app or the test app, small steps before we take big ones...) into the MSVC project. Also, make sure that the converted dll, exp, and lib files are in your project folder. Again, the instructions make this clear. You also need to tell MSVC that the lib file is a dependent. To do this, place the lib and header file under the "Resource Files" category. The only thing that I have under my "Header File" category is StdAfx.h...

Another tip that I just thought of...when you open a new Win32 console project, DO NOT SELECT BLANK PROJECT! This will not insert the required MS dependency files that you need to compile and link properly. Start out with a "Hello World" project and modify it by importing the project files into it and adding the lib and header files as prescribed. This should take care of your problem. This is a more of a MS issue than it is a dll issue.

rmatsick

Altera_Forum · ‎10-19-2009

rmatsick (or anyone else),

I was able to use this dll under cygwin without issue. I've been trying to get this work under windows as well, and have run into a few problems. The code compiles except for calls to jtagatlantic_get error(). I get a link error:

1>LINK : C:\Documents and Settings\ayresj\My Documents\Visual Studio 2005\Projects\jtagTest\Debug\jtagTest.exe not found or not built by the last incremental link; performing full link

1>jtagTest.obj : error LNK2019: unresolved external symbol "int __cdecl jtagatlantic_get_error(char const * *)" (?jtagatlantic_get_error@@YAHPAPBD@Z) referenced in function _wmain

1>C:\Documents and Settings\ayresj\My Documents\Visual Studio 2005\Projects\jtagTest\Debug\jtagTest.exe : fatal error LNK1120: 1 unresolved externals

If I comment out all references to jtagatlantic_get_error() and compile, the link goes fine, but then I try to run the program and I get the following windows error: application failed to initialize correctly. click ok to terminate program.

so, I guess I have two questions:

1.) why does everything link except for jtagatlantic_get_error()?

2.) why does the application fail to initialize?

I'm new to windows programming. I usually work in vxWorks or small embedded systems, so I think it might be something silly, I just don't know what that could be. Any help would be appreciated....

Altera_Forum · ‎10-20-2009

jeffa,

First off, I am not a Windows programmer either, but I manage to hack my way along when I need to. Let's see if I can help you. I note that in the linker error message that a __cdecl call is being initiated. This is interesting, because I recompiled my test code a few minutes ago and did not get that error. I also note that the jtag_atlantic.h header is located in the resource files folder of the project along with jtag_atlantic.lib. My main code is nothing more than a hacked up version of the original Cygwin test app.

I looked at some of my project settings next. They are:

1. General Tab: Not Using MFC

2. Debug Tab: Category: Additional DLLs: check box checked for "try to locate other DLLs"

3. C/C++ Tab: Category: Precompiled Headers: radio button checked for "Use precompiled header file (pch)" Through header: stdafx.h

4. C/C++ Tab: Category: Code Generation: Calling convention: __cdecl*, Processor: blend*, Use run-time library: Debug single-threaded, Struct member alignment: 8 bytes*

5. Link Tab: Category: General: "Link Incrementally" check box checked along with "Generate debug info".

6. Link Tab: Category: Customize: "link incrementally" and "use program database" are both checked. There should be a *.pdb file name listed under Program database name.

7. Link Tab: Category: Debug: Debug Info: "Debug Info" check box checked, "Microsoft format" radio button depressed, "Separate bytes" check box checked.

There are other settings which should be the same since they are default settings which I did not go into. In fact, most of the settings I gave you were set by default.

Locate the *.lib, *.dll, *.h, and *.exp files in the local project folder.

Add the *.lib and *.h files to the MSVC project under "Resource Files" before compiling and linking. Also, make sure that you start out with a "Hello World" Win32 console application first and then bring in your own main.cpp or test.cpp, or whatever else you called it. If you do not do this, you will not have the necessary stdafx.h file included in your project and you will get linker errors.

Another thing you might want to look at is the contents of your jtag_atlantic.h file. There should be an enumerated JATL_ERROR type return for jtagatlantic_get_error function prototype. This enumerated type is located in the library. So, if your library was not created properly, you might have this problem. Along those lines, check the def file that you used. Make sure that it conforms with MSVS requirements, and that you have all of the functions listed.

I kind of remember getting this same error early on when I was working at solving the DLL inconsistency problem, but I was moving so fast that it seemed arbitrary to me at the time and I was able to solve it with either a project setting, file relocation, or starting a new project using the "Hello World" Win32 console application wizard. I can't remember which one it was right now. However, if you continue to have problems, my suggestion is to move the code, DLL, lib, and exp files to a safe place after rebuilding the library and checking the def file as mentioned earlier, delete the project folder, create a new project folder and start out fresh with a "Hello World" Win32 console application. Then, add your files where prescribed and rebuild the project.

BTW, I hate Windows. But, we use Windows PCs at work. This type of work is better done under Unix or Linux. Cygwin is just a bandaid IMHO.

Altera_Forum · ‎10-20-2009

rmatsick,

First, thanks so much for the help. Today I've had some success and some failure. This doesn't totally make sense, but I switched computers today and had MSVS 2008 freshly installed on my PC. I imported the projects that I was using before (the ones that used to crash), and they work fine. That is great, but it doesn't make any sense at all. I didn't have to change anything. I just recompiled and tried it.

so that's the good news. The bad news is that I still get the link error if I try to use the jtagatlantic_get_error() function.

I went through the project settings that you mentioned. I think we are using different versions of MSVS becasue some of those options weren't listed in the same place, and some I couldn't find all. I don't have any radio buttons or anything like that in my settings...just boxes with text in them.

I also can't find the option to start a "hello world" project. I can choose console app, and either empty or precompiled. I've been doing precompiled and that seems to be working thus far. that provides the stdafx.h file and a main that I can paste into.

So, here is one thing I noticed that might be a problem. You mentioned that jtagatlantic_get_err() should return a JATL_ERROR? my header file has it returning an int. It seems that this is the only function that won't link, so I'm wondering if it could be some kind of definition missmatch between header file and DLL or something like that. Does that make any sense at all? All this DLL stuff is new to me. I'm going to go back and look at your original posting to see if that gives me any information.

Any other ideas?

Altera_Forum · ‎10-20-2009

jeffa,

Glad to here things are improving. Yes, the function prototype that I have in my header file is: enum JATL_ERROR jtagatlantic_get_error(const char * * other_info);

That is definitely your error. I found another version of my_jtag_atlantic.h on my computer which returned an int and placed it my project with a different name and set the preprocessor directive in the main program to include this file and received this error;

Compiling...

test.cpp

C:\altera\jtag_uart\code\test\test.cpp(28) : warning C4101: 'read_array' : unreferenced local variable

Linking...

test.obj : error LNK2001: unresolved external symbol "int __cdecl jtagatlantic_get_error(char const * *)" (?jtagatlantic_get_error@@YAHPAPBD@Z)

Debug/test.exe : fatal error LNK1120: 1 unresolved externals

Error executing link.exe.

Which is exactly the same as your error. I then swapped this file name with the old one which has the enum JATL_ERROR return value and build window showed this:

--------------------Configuration: test - Win32 Debug--------------------

test.exe - 0 error(s), 0 warning(s)

That is your answer. Change the return value to enum JATL_ERROR and it should solve the linker issue.

Altera_Forum · ‎10-20-2009

rmatsick,

Bingo!! That does it. Thanks for the help. Hopefully I can return the favor some time.

Altera_Forum · ‎10-23-2009

rmatsick and cooi23,

I'm experiancing similar problems to what cooi23 alluded to with console vs. windows applications.

cooi23, did you ever solve that? It looks there is a difference in the full function names. If I do a dumpbin on the obj file for the console application, the full names of the functions begin with with __cdecl. those are the ones that work. dumping the obj file for the windows application show the function names starting with __clrcall. I believe that's why it won't link. It's looking for a different name than the dll/lib provides.

I haven't found a way to make it work yet. the project that works is set up for "No Common Language Runtime support". The windows application is set for "Pure MSIL Common Language Runtime Support (/clr:pure)". I think this is the driving factor, but I haven't figured out how to force the windows app to use the __cdecl naming.

any input?

Altera_Forum · ‎10-26-2009

jeffa and cooi23,

You are using a completely different version of MSVC++ than what I have. You are probably using the newest with .net would be my guess. I do not know what the inclusion of .net really ever brought to the table, but that is not a topic of discussion which is applicable to an Altera knowledge blog.

As I have said before, I am not a Windows programmer. In fact, I despise the Windows OS. It is nothing more than hacked-up layer upon layer of fixed mistakes over the years which needs to support as many flavors of hardware as there is electromagnetic spectrum. Each time a 'new' version is released, it inevitably consumes more and more resources. This is not efficient, nor is it a wise business model.

With that rant out of the way, I did a search on the __clrcall directive and found this:

**Microsoft Specific**

"Specifies that a function can only be called from managed code. Use __clrcall for all virtual functions that will only be called from managed code. However this calling convention cannot be used for functions that will be called from native code."

This implies that this is to be used with virtual functions. Virtual functions (methods) are only used with C++ in derived classes when you want to over-ride the base class method functionality. It also says that it is to be used "with managed code". This also implies that a some sort of code repository system is in place such as CVS or MS SourceSafe would be my guess.

Finally, it says, "cannot be used for functions what will be called from native code". Obviously, this is precisely what we are doing! Furthermore, the code is written in C, and not C++, so that blows the virtual function issue out of the water as well.

I think that as jeffa has eluded, it comes down to preference or project setting that is using __clrcall instead of __cdecl when linking. You should be looking for first before attempting other fixes.

It has been my experience that problems with the linker are inevitably always a setting problem.

Altera_Forum · ‎10-26-2009

In case anyone else runs into this problem, I thought I'd share what I've figured out so far. This is probably stuff that an experianced windows programmer would know...but I'm not one of those :D

It appears that when you are making a windows application in MS visual studio you need to compile with "Pure MSIL Common Language Runtime Support (/clrpure)". However, you can force the compiler to use the decorated name you want. In this case, the DLL contains decorated names using __cdecl. The solution is go into the header file (my_jtag_atlanitic.h) and place __cdecl in from of all the function names. This will force the comiler to use the name that you want. so the original header file looked like this:

typedef struct JTAGATLANTIC JTAGATLANTIC;

JTAGATLANTIC * jtagatlantic_open(const char * chain, int device_index, int link_instance, const char * app_name);

enum JATL_ERROR jtagatlantic_get_error(const char * * other_info);

void jtagatlantic_close(JTAGATLANTIC * link);

int jtagatlantic_write(JTAGATLANTIC * link, const char * data, unsigned int count);

int jtagatlantic_flush(JTAGATLANTIC * link);

int jtagatlantic_read(JTAGATLANTIC * link, char * buffer, unsigned int buffsize);

this will result in lots of linker errors as specifided in a previous post. we can add the __cdecl modifier in front of the function names as follows:

typedef struct JTAGATLANTIC JTAGATLANTIC;

JTAGATLANTIC * __cdecl jtagatlantic_open(const char * chain, int device_index, int link_instance, const char * app_name);

enum JATL_ERROR __cdecl jtagatlantic_get_error(const char * * other_info);

void __cdecl jtagatlantic_close(JTAGATLANTIC * link);

int __cdecl jtagatlantic_write(JTAGATLANTIC * link, const char * data, unsigned int count);

int __cdecl jtagatlantic_flush(JTAGATLANTIC * link);

int __cdecl jtagatlantic_read(JTAGATLANTIC * link, char * buffer, unsigned int buffsize);

this modification makes the compiler use the names that match with what's in the DLL.

I still get the following compiler warnings:

warning LNK4248: unresolved typeref token (01000014) for 'JATL_ERROR'; image may not run

warning LNK4248: unresolved typeref token (01000015) for 'JTAGATLANTIC'; image may not run

these sound a little scary, but the application seems to run fine. The Jtag link is established when I bring it up. I've hit another problem that is crashing my program before I can actually send or receive data, but I don't think it's related to this. I'll update the forum when I get that far.

I had to search around on MSDN for figure this out. I think this link had most of the explanation:

http://msdn.microsoft.com/en-us/library/ms173253.aspx

Altera_Forum · ‎10-26-2009

jeffa,

That's really not a solution if you continue to have warnings. I would try to find an older version of MSVC++. I am using v6.0. I did not need to do any of the things that you had described and it compiled and linked just fine without any errors or warnings, and I am using the get_error function without issue. I still suspect that there are system settings not properly addressed in your version of MSVC++. But then again, this is an Altera knowledge blog and not a MSVC++ knowledge blog.

Good luck with it.

Altera_Forum · ‎06-06-2013

I am using Visual Studio 2013. I had a name-mangling issue with the functions in jtag_atlantic.dll. C and C++ mangle the names in DLLs in different ways. To get this to work, I had to open my project settings and on the C/C++ Advanced tab, set the Compile As option to "Compile as C++ Code (/TP)".

I expect that's the same as adding the /TP compiler option to the command line for the compiler.

Once I did that, and made sure that the return type of jtagatlantic_get_error in my header file was enum JATL_ERROR, everything compiled and linked correctly.