In Nios II 6.0, legacy SDK is no longer supported. This means that GERMS which is part of legacy SDK is no longer supported.I've attached a tar file which contains the assembly source code for GERMS ported to Altera HAL. It works best with the Nios II 6.0 release but will work with older releases with some work on your part (there will probably be some# defines missing from system.h that GERMS depends on). Here's the readme.txt file from the attached tar file. OVERVIEW -------- The GERMS monitor is a simple, compact program suitable for any Nios II system with the following minimal requirements: - A UART (JTAG or otherwise) - 1K of on-chip memory in M4K or M512 Blocks. - Reset address set to the memory containing GERMS. BUILDING GERMS -------------- GERMS is implemented in assembly code. It uses a HAL system library to obtain the system information (system.h) and linker script; it doesn't use any of the code from the library. In Nios II 6.0, there is now support for a GERMS template for Nios II IDE. To install it, create a directory called "germs" in the "examples/software" directory of your Nios II kit installation directory (defaults to c:/altera/kits/nios2 on Windows systems) and copy the nios2_germs_monitor.S and template.xml files into this new directory. To use GERMS, start a new C/C++ project in the Nios II IDE. Select the PTF file associated with your SOPC Builder system and select the "GERMS Monitor" template. For more info on starting a new project, consult the Nios II IDE documentation. After the project is created, check that the system library properties to verify that the .text section is mapped to the GERMS memory. This step is crucial since GERMS must begin running immediately after the processor comes out of reset. Next, build your project in the IDE. This creates a .hex file in the same directory as your PTF file (your Quartus project directory) with the name of your GERMS memory. The .hex file will be built into the .sof file for your system the next time you compile in Quartus II. Thus, if your design is ready, you may compile your system now. If you already have a .sof, you can use the following commands to just update the on-chip RAM: From the directory containing the .sof and .hex files: prompt% quartus_cdb --update_mif your.qpf This will setup the assembler to do the updating. Now run: prompt% quartus_asm your.qpf Note that this assumes you have an appropriate .sof to actually update. RUNNING ------- After downloading the newly compiled .sof to your device, run nios2-terminal (with the appropritate settings to connect to your board). You will see the following: germs + The '+' is your prompt and signals that the GERMS monitor is ready to accept commands. Below is a list of the supported commands: # -------------------------------# Commands:# G<address> Go at address# E<address> Erase flash at address <NO LONGER SUPPORTED HERE># R<address>-<address> Relocate S-Records from-to <UNTESTED IN THIS VERSION># M<address> Display at address# M<address>-<address> Display range# M<address>:val val... Write at address# M<address>-<address>:val Fill range with val# S... S-record, no error checking# :... Intel-Hex record, no error checking Note that the 'E' command is deprecated and 'R' is untested. When working with the flash, it is recommended that you use the stand-alone flash programmer. To load a complete S-record, redirect STDIN of nios2-terminal to your .srec: prompt% nios2-terminal < my.srec Control will not return to GERMS once the S-record completes downloading (and assumingly runs). To create an S-record, use: prompt% nios2-elf-objcopy -O srec <any.elf> <any.srec> If you don't want the S-record to launch itself automatically, remove the last line of the S-record. This final line gives information on where to jump to begin the program contained in the S-record. You may then examine memory using GERMS to verify the download completed correctly, change areas of memory if desired and then execute a 'g<address>' to launch your program. OTHER ----- It is not recommended that GERMS be targeted for the tightly-coupled memories in higher-performance systems. While GeRMS will run from that region of memory, problems may arise when other programs are downloaded. If using a terminal program other than one supplied by Altera, it must be configured properly. In particular, GERMS will send just a line feed (0xA) to serve as a newline. Your terminal program should interpret it as such. If you cannot configure the terminal program to operate in this manner, there is a NEWLINE macro in the GERMS assembly file that can be adjusted to suit your terminal. Most likely you would just need to comment out the two lines provided that send a carriage return (0xD) before the line feed. GERMS is very unforgiving of bad user input. If you would like something more robust, there is a section of code that contains a comment about improving user input handling. That would be the likely place to make improvements. There may be some useful documentation in the assembly file itself. The interested reader is directed there for any additional information.