Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20641 Discussions

GERMS monitor for Altera HAL

Altera_Forum
Honored Contributor II
1,310 Views

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 &#39;E&#39; command is deprecated and &#39;R&#39; 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&#39;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 &#39;g<address>&#39; 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.
0 Kudos
0 Replies
Reply