Visible to Intel only — GUID: zht1664522690296
Ixiasoft
1. About the Nios® V Embedded Processor
2. Nios® V Processor Hardware System Design with Quartus® Prime Software and Platform Designer
3. Nios® V Processor Software System Design
4. Nios® V Processor Configuration and Booting Solutions
5. Nios® V Processor - Using the MicroC/TCP-IP Stack
6. Nios® V Processor Debugging, Verifying, and Simulating
7. Nios® V Processor — Remote System Update
8. Nios® V Processor — Using Custom Instruction
9. Nios® V Embedded Processor Design Handbook Archives
10. Document Revision History for the Nios® V Embedded Processor Design Handbook
2.1. Creating Nios® V Processor System Design with Platform Designer
2.2. Integrating Platform Designer System into the Quartus® Prime Project
2.3. Designing a Nios® V Processor Memory System
2.4. Clocks and Resets Best Practices
2.5. Assigning a Default Agent
2.6. Assigning a UART Agent for Printing
2.7. JTAG Signals
4.1. Introduction
4.2. Linking Applications
4.3. Nios® V Processor Booting Methods
4.4. Introduction to Nios® V Processor Booting Methods
4.5. Nios® V Processor Booting from Configuration QSPI Flash
4.6. Nios® V Processor Booting from On-Chip Memory (OCRAM)
4.7. Nios® V Processor Booting from Tightly Coupled Memory (TCM)
4.8. Summary of Nios® V Processor Vector Configuration and BSP Settings
6.2.3.2.1. Enabling Signal Tap Logic Analyzer
6.2.3.2.2. Adding Signals for Monitoring and Debugging
6.2.3.2.3. Specifying Trigger Conditions
6.2.3.2.4. Assigning the Acquisition Clock, Sample Depth, and Memory Type, and Buffer Acquisition Mode
6.2.3.2.5. Compiling the Design and Programming the Target Device
6.6.1. Prerequisites
6.6.2. Setting Up and Generating Your Simulation Environment in Platform Designer
6.6.3. Creating Nios V Processor Software
6.6.4. Generating Memory Initialization File
6.6.5. Generating System Simulation Files
6.6.6. Running Simulation in the QuestaSim Simulator Using Command Line
Visible to Intel only — GUID: zht1664522690296
Ixiasoft
7.2.1.1. Setting Max Retry Parameter
The max retry parameter specifies how many times the application and factory images are tried when configuration failures occur.
- The default value is one, which means each image is tried only once.
- The maximum possible value is three, which means each image can be tried up to three times.
The max retry parameter is stored in the decision firmware data area. The decision firmware data can also be updated by a decision firmware update image, or by a combined application image.
The max retry parameter is specified for the hardware project used to create the factory image, from the Quartus® Prime GUI by navigating to Assignments > Device > Device and Pin Options > Configuration and selecting the value for the Remote System Update MAX_RETRY count field.
Figure 116. Configuration Window
You can also specify the parameter directly by editing the project Quartus® Prime settings file (.qsf) and adding the following line or changing the value if it is already there:
set_global_assignment -name RSU_MAX_RETRY_COUNT 3