Nios II 5.0 Errata - Software

• Nios II Integrated Development Environment (IDE)
  • Building Projects
    
  • Debugging Projects 
    
  • Navigating Projects
• Toolchain (GNU C Compiler, GNU Debugger, etc.)
• Target Software
• Legacy SDK
• Flash Programmer

Nios II IDE

This section lists any issues relating to the Nios^® II IDE.

Building Projects

Building Nios II Advanced Projects using 'Build Project' invokes 'make clean all' by default

Nios II IDE Advanced Projects created with earlier (pre-5.0) versions of Nios II IDE will call 'make clean all' by default when the project is built, rather than calling 'make all.'  Also running Project -> Clean... on these projects has no effect.

Workaround: For Nios II Advanced Projects created with earlier (pre-5.0) versions of Nios II IDE, right click on the project and select Properties. The select C/C++ Make Project. In the Workbench Build Behavior section, change the value for "Rebuild (Full Build)" to "all". Also check the tick box for "Clean" and enter "clean" in the corresponding textbox. This will ensure the project invokes 'make all' by default for a build and 'make clean' by default for a clean build.

Build errors after changing component names in SOPC Builder

If you rename components in the SOPC Builder system and then regenerate the SOPC Builder system, Nios II IDE system library projects based on that system will have build errors.

Workaround: After regenerating the SOPC Builder system, create a new system library project for the SOPC Builder system. Alternately, you can delete the system library project from the workspace without deleting the contents from the file system, and then re-import the project, selecting the appropriate SOPC Builder system.

Debugging Projects

Debug As -> ISS Error: "Error starting gdbserver" 

When launching a debug session with the Nios II ISS target, you may get the following message : "Launch failed. Error starting gdbserver - see console for details" with no other details on the console. If you are running an antivirus program with an inbuilt firewall, this may be blocking the listening tcp port opened by the nios2-iss executable.

Workaround: You must unblock the nios2-iss.exe program to enable it to operate through the firewall. Please consult the Help section of your antivirus program, for instructions on how to do this.

Missing traced load/store instruction and data trace view or IndexOutofBoundsException

If the "Include Load Addresses", "Include Store Addresses" and/or "Include Data Values..." trace options is enabled during debug, the load and store address and data will not appear at the first breakpoint when starting debugging. They will appear at successive breakpoints. To see load or store addresses and data in the instruction trace prior to main, turn on “Break at alt_main()” (in the Debugger tab of your debug configuration).

Cannot use watchpoints in the Nios II IDE when the FS2 console is open

Watchpoints do not work in the Nios II IDE when the Use FS2 Console Window for Trace and Watchpoint Support setting is turned on in the Debugger tab of the Debug configuration. You will see an error message: "The execution of program is suspended because of error" with details indicating that hardware watchpoints could not be inserted and deleted.

Workaround: If the FS2 console is open, you must use it to control watchpoints. For details, see the FS2 documentation.

Breakpoints on adjacent lines of assembly fail to halt the processor

Setting breakpoints on adjacent lines of assembly code might cause the Nios II processor to stop responding to the debugger. 

Workaround: When debugging in mixed mode or assembly mode view, separate breakpoints by at least one assembly instruction. This issue does not affect Nios II cores that do not have hardware breakpoints enabled in the JTAG debug module.

Navigating Projects

Resource(s) out of sync with the file system when searching for files in the workspace

When searching through files in the IDE workspace, you may get an error message saying that one or more resources are out of sync with the file system.

Workaround: Right click in the Navigator view and choose Refresh, and then perform the search again.

C/C++ scanner does not understand certain C/C++ constructs

The C/C++ scanner is used for C/C++ search, navigation, open declaration and parts of content assist. As the scanner doesn’t recognize them, the following code constructs will fail to work with these utilities:

• K&R style C
• Functions that take a function-pointer as an argument

Workaround: If the C/C++ search fails, use the File Search facility.

Toolchain (GNU C Compiler, GNU Debugger, etc.)

This section lists any issues related to the Nios II compiler toolchain.

Breakpoints in C++ constructors fail to halt the processor

Breakpoints set in a C++ constructor might not halt the processor due to a widespread GNU C compiler (GCC), GNU debugger (GDB) issue. This is not a Nios II IDE specific issue.

Workaround: You can workaround this issue by moving all of your constructor source code into another class method, called init. Then invoke this method from within the constructor.

Target Software

This section lists any issues related specifically to the target software.

DMA HAL routine results in illegal bus condition

The Nios II DMA Hardware Abstraction Layer (HAL) routine results in illegal bus condition if:

• the bursting DMA is connected to slaves wider than 32-bits, or
• the "word" checkbox on the Advanced tab in the GUI is unchecked, or
• the DMA master is connected only to slaves of data width less than or equal to 16 bits.

Workaround:  Use a "freestanding" Nios II application to avoid using the HAL, and don't call the DMA init routine for the DMA in question.

Creating new custom HAL components

When you first create a component's inc directory, or HAL component header file, you may need to perform a clean build, (i.e. rebuild) of existing system library projects for the new files to be detected.

Workaround: No workaround is available at this time.

Legacy SDK

This section lists issues related to legacy SDK support for the Nios II processor.  For additional known issues with the legacy SDK, refer to the Nios II Embedded Processor Support page. Please note that the legacy SDK will be depreciated in a future release of Nios II processors.

Legacy SDK does not support multiple clock domains

As stated previously, the Nios II legacy SDK will not support new Nios II/SOPC features. As such, systems with multiple clock domains may not function correctly when the legacy SDK is used, when peripherals that the Nios II CPU communicates with rely on a timing relationship established with the legacy SDK's "nasys_clock_freq" definition, found in excalibur.h and excalibur.s. For example, the nr_timer_milliseconds() routine in the legacy SDK uses nasys_clock_freq to start a timer to run for one millisecond. If the timer and Nios II CPU are on separate clock domains in SOPC Builder, an incorrect value will be written to the timer.

The Legacy SDK flow does not support the SPI peripheral

The Nios II legacy SDK flow does not currently include support for the serial peripheral interface (SPI) peripheral. Legacy SDK drivers for the SPI peripheral are available on the Nios II Embedded Processor Support page.

The Legacy SDK flow does not support the JTAG UART

The JTAG UART did not exist before the release of the Nios II processor, and therefore the pre-Nios II legacy SDK flow provides no driver for the JTAG UART. The legacy SDK is not being actively developed, and peripherals developed in the future are unlikely to provide support for the legacy SDK.

Flash Programmer

This section lists any issues related specifically to the flash programmer.

Flash programmer fails using older download cables

There have been occasional noise issues with older download cables that have long, gray ribbon cables. This has caused some flash programming issues. The USB-Blaster^TM Rev B cables have shorter, shielded, yellowish ribbon cables that eliminate this problem. Be sure you are using a USB-Blaster Rev B download cable to program flash.

Stratix II boot from EPCS not supported

Booting from an EPCS device is not supported with Stratix II devices.

Workaround: Contact Altera Applications for potential workarounds.

Flash programmer fails to program an .elf file

If your Nios II processor system does not contain a common flash interface (CFI) or EPCS flash memory component (e.g., the "fast" example design), the flash programmer cannot program an .elf file to flash memory, even if the target board contains a CFI or EPCS flash memory component. The flash programmer will fail without an obvious reason. The flash programmer can still program FPGA configuration data and arbitrary files. 

Workaround: Make sure the designer’s actual Nios II system has a flash memory component before attempting to program an .elf file to flash.

Flash programmer failures on custom boards

The flash programmer may fail when used with a custom target board. The failure mechanisms may include:

• The flash programmer may fail if the custom target board does not contain a CFI flash component. Even if the board contains only an EPCS configuration device and no CFI flash, the target board system must contain a CFI flash component.

Workaround: Add a CFI flash component to your target board in SOPC Builder.  You do not need to connect the flash signals to pins at the top level--you can leave them unconnected.

• Your flash programmer target board may not be running at least 50 MHz. The flash programmer requires that the target board input clock be at least 50 MHz.

Workaround: Make sure the target board design has an input clock of at least 50 MHz. If a 50-MHz clock is not available on the board, you can use a phase-locked loop (PLL) in the FPGA to create a 50-MHz clock.

• The flash programmer target board may have been compiled in Quartus^® II software without the proper firmware. In some cases, the firmware file for the Nios II processor contained in the target board can be overwritten inadvertently.

Workaround: Copy the file <Nios-II-Install-Directory>\
components\altera_user_board_setup\system\
firmware_ROM.hex> to your target board project directory and recompile in Quartus II software. This will ensure that the target board contains the proper firmware.