5.1 Errata - Software
This section lists any issues relating to the Nios II IDE.
The workspace does not exist
Nios II IDE may not prompt for workspace at startup.
Workaround: Specify the workspace at the command line using the -data argument. For example: nios2-ide -data <path to workspace> If the workspace does not exist, it will be created.
Nios II IDE stops responding after you double-click a .o file
Double-clicking a .o file in the Nios II IDE on Windows might cause the IDE to stop responding. This issue occurs only on systems with a separate installation of Cygwin in addition to Cygwin installed with the Nios II development tools.
Workaround: Ensure that only the cygwin1.dll for the Nios II tools is in the path when launching Nios II IDE.
Error importing a software project created in Nios II IDE version 5.0.1 to Nios II IDE version 5.1
If you create a software project in Nios II IDE version 5.0.1 and then install Nios II version 5.1 and try to import that same project into your workspace, you might get a "Problem deleting folder Debug" error message .
Workaround: If you get this error message, close the Nios II IDE and any other application which has files open from the project in question, then manually delete the project Debug and/or Release directories from the file system. Re-import the project in the Nios II IDE version 5.1.
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 the Nios II IDE call 'make clean all' when the project is built, rather than 'make all'. Also, on the Project menu, clicking Clean for these projects has no effect.
Workaround: To change the behavior of the IDE so that the project invokes make all by default for a build and make clean by default for a clean build, do the following:
- Right click on the project and select Properties
- Select the C/C++ Make Project page
- In the Workbench Build Behavior section, change the value for Rebuild (Full Build) to All
- Turn on Clean and type clean in the corresponding text box
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. Alternatively, 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.
Memory inspection during multiprocessor debug—Updated November 27, 2005
A problem was discovered with inspecting memory during multiprocessor debug sessions in the Nios II IDE version 5.1. If you launch a multiprocessor debug session and select any logical memory address in the Memory tab, the debug session will terminate.
Workaround: Apply the Nios II 5.1 Patch 1 to correct the problem.
Incorrect breakpoint filtering on threads
If you enable breakpoint filtering for a thread and later turn off filtering for the thread, the debugger might incorrectly continue to filter the thread.
Workaround: There is no workaround.
RAM Test failure when running Memory Test software template on the ISS
An issue in the instruction set simulator (ISS) model of the JTAG UART can cause a console communication error during the RAM Test when running the Memory Test software template on the ISS.
Workaround: There is no workaround.
Uninitialized Memory Error when executing from ISS
Under some cases the ISS does not ignore uninitialized memory reads, even when Uninitialized memory reads is set to Ignore on the ISS Settings tab of the Run configuration.
Workaround: There is no workaround.
Use Step Filters button is permanently grayed out in Nios II IDE debug perspective
The Use Step Filters button, just to the right of the Step Return button, is not implemented in Nios II IDE version 5.1.
Workaround: There is no workaround.
'Nios2-gdb-server' fails to terminate after setting a watch point
You might be unable to terminate nios2-gdb-server after setting a watch point in the Nios II IDE debugger and resuming execution past the end of main. You will see an error message, "Terminate failed." You will not be able to start the debugger again; you will see a message reading "Another application is using the target processor..." in the Console view.
Workaround: Terminate the nios2-gdb-server.exe process using the Windows Task Manager.
Watchpoints only work when set on variables whose size is 32-bits
Watchpoints do not work when set on variables whose size are not 32-bits
Workaround: Change the type of global and static local variables to int, long, or unsigned long before setting watchpoints on them.
Debugger cannot step into __sflags, and continues execution instead
The Nios II IDE debugger is unable to step into some low-level C library functions, such as __sflags() which is called from _fopen_r(). (_fopen_r() is called from fopen().) If you try to step into such a function, execution will proceed as if you had indicated the debugger should resume execution.
Workaround: Step over such functions. Or, if execution continues after trying to step in, click Suspend on the Run menu.
Missing traced load/store instruction and data in the Trace view
If the trace options 'Include load addresses,' 'Include store addresses' and/or 'Include data values' are enabled during debug, the load and store address and data will not appear at the first breakpoint after starting debugging. They will appear at successive breakpoints.
Workaround: To see load or store addresses and data in the instruction trace prior to main, turn on Break at alt_main() located on the Debugger tab for 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.
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. Due to limitations of the C/C++ scanner, these features will not work with the following code constructs:
- Kernighan & Ritchie-style C
- Functions that take a function-pointer as an argument
Workaround: If the C/C++ Search fails, use the File Search facility.
This section lists any issues related to the Nios II compiler toolchain.
Incorrect gprof call hierarchy information
gprof sometimes reports incorrect call hierarchy information in the call graph output.
Workaround: There is no workaround.
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 GCC, 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.
This section lists any issues related to target software.
Flash erase failure—Updated November 27, 2005
On some Nios development boards, both the Nios II version 5.1 flash programmer and HAL flash routines may fail to erase certain sectors of flash. It will time out and report an error while attempting to erase flash. The root cause for this is still under investigation. The patch below contains a modified flash programmer and modified HAL code that reduces the chance of this problem occurring. This problem has currently only been encountered on the Nios Development Board, Stratix®, Stratix Professional, and CycloneTM Editions which use the AMD AM29LV065D flash device.
Workaround: Apply the Nios II 5.1 Patch 1 which contains modified HAL code that reduces the probability of this failure occurring. Root cause analysis is currently underway and a complete fix will be posted as soon as it is available.
cout from MicroC-OS/II task will not send data to stdout
If neither printf() nor cout is used from main() before tasks are started, cout will not work from a task.
Workaround: Add the following C++ code to the beginning of main():
std::ios_base::sync_with_stdio(false);
Problems using HAL drivers with Toshiba Flash
The HAL CFI Flash driver might not work for Toshiba flash memory that claims to be CFI compliant.
Workaround: In the altera_avalon_cfi_flash_table.c file, change the #define READ_ARRAY_MODE from (alt_u8)0xFF to (alt_u8)0xF0 and rebuild the project.
Creating new custom HAL components
When a component's inc directory or HAL header file is first created, existing system library projects may not be detected.
Workaround: When you first create a component's inc directory or HAL header file, you might first need to perform a clean build (rebuild) of existing system library projects for the new files to be detected.
This section lists issues related to legacy software development kit (SDK) support for the Nios II processor. For additional known issues with the legacy SDK, refer to the Nios II Embedded Processor Support page. Note that legacy SDK support will be removed in a future release of the Nios II development tools.
Legacy SDK does not support multiple clock domains
The Nios II legacy SDK does not support new features of the Nios II processor and/or SOPC Builder. As a result, systems with multiple clock domains might not function correctly when the legacy SDK is used. For example, peripherals that the CPU communicates with rely on a timing relationship established by the legacy SDK's nasys_clock_freq definition, found in excalibur.h and excalibur.s. 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 CPU are on separate clock domains, the timer period will be incorrect.
Workaround: There is no workaround
Legacy SDK flow does not support the SPI peripheral
The Nios II legacy SDK flow does not include support for the serial peripheral interface (SPI) peripheral.
Workaround: Legacy SDK drivers for the SPI peripheral are available on the Nios II Embedded Processor Support page.
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.
Workaround: There is no workaround. The legacy SDK is not being actively developed, and peripherals developed in the future are unlikely to provide support for the legacy SDK.
Legacy SDK flow might not properly place code at the reset address
If program memory and the Nios II reset address both reside at the bottom of a memory, a reset of the processor might not properly boot from the program memory when using the legacy SDK flow. This results from a slightly different boot procedure between Legacy mode and Nios II IDE mode.
Workaround: Place program memory and the reset address at the base of the RAM in question. Place the exception address near the top of the RAM (at least 0x80 bytes from the end).
Flash only flow failure in IDE—Updated December 19, 2005
The Flash only flow of the Board Description Editor is used to run the Nios II Flash Programmer on a custom board in IDE mode. When the Board Description Editor is run in the Flash Flow only, wherein no board netlist (wirelist) is provided, the resulting PTF file is missing some entries which are required for successful system generation in SOPC Builder. A subsequent attempt to generate in SOPC Builder will issue the following error:
C:/altera/quartus51/sopc_builder/bin/europa/e_project.pm 310 CALLED (e_project::device_family) WHERE <=== 'expected exactly one argument' OCCURRED on C:/altera/quartus51/sopc_builder/bin/europa/e_project.pm 1313
Workaround: The workaround is to use the Flash Programmer via command line or hand-edit the board description PTF file as described below after running the Board Description Editor.
- Run through the Flash Flow of the Board Description Editor as instructed in the Board Description Editor (PDF) chapter of the SOPC Builder Handbook.
- Close SOPC Builder
- In a text editor, open the .ptf file created by the Board Description Editor.
- In the CLASS/BOARD_DEFAULTS section of the .ptf file, add the following entries.
- device_family = "<device family>"; suitable values for <device family> are CYCLONE, CYCLONEII, STRATIX, STRATIXII, etc.
- For each CFI or EPCS flash entered in the board description, create a REFDES section with an arbitrary base address, such as just "0".
- Workaround_example.txt shows an example of the edits.
- Save and close the .ptf file after making the edits.
- Re-open the system in SOPC Builder, select the newly created board description in the "Target" section, and then click Generate.
The edits to the .ptf file are only required after the first time you run the Board Description Editor to create the board description. Once the entries have been added to the .ptf file, future editing of the board description with the Board Description Editor will not remove those entries.
Flash programming failure—Updated November 27, 2005
An issue has been discovered in the Nios II version 5.1 flash programmer that can cause it to fail during programming. Depending on the initial contents of flash, the flash programmer sometimes fails to erase correctly when programming files of a certain length into flash. This is usually seen on flash files created from EP2S60 SOF files which are of the length that can trigger this failure. During programming, there will be a long pause (>20 seconds), followed by the error:
'Program failed. Leaving target processor paused'
Workaround: If the flash programmer pauses for more than 20 seconds before reporting this error, apply the Nios II 5.1 Patch 1 to correct the problem.
Flash erase failure—Updated November 27, 2005
On some Nios development boards, both the Nios II version 5.1 flash programmer and HAL flash routines may fail to erase certain sectors of flash. It will time out and report an error while attempting to erase flash. The root cause for this is still under investigation. The patch below contains a modified flash programmer and modified HAL code that reduces the chance of this problem occurring. This problem has currently only been encountered on the Nios Development Board, Stratix, Stratix Professional, and Cyclone Editions which use the AMD AM29LV065D flash device.
Workaround: Apply the Nios II 5.1 Patch 1 which contains modified HAL code that reduces the probability of this failure occurring. Root cause analysis is currently underway and a complete fix will be posted as soon as it is available.
elf2flash elf size limit
The elf2flash utility supports .elf files up to approximately 24 Mbytes in size. The elf2flash utility might fail with a "java.lang.OutOfMemoryError" on files larger than 24 Mbytes.
Workaround: You can either lower the number of symbols in your .elf file by turning off debug symbols, or specify less initialized data in the application.
Boot from EPCS not supported for Stratix II devices
Booting the Nios II processor from code stored in an Altera® EPCS serial configuration device is not supported with Stratix II devices.
Workaround: For further assistance contact Altera Technical Services at mySupport.
|
文档资料
> 
