AN 100: In-System Programmability Guidelines

Download PDF
ID 683546
Date 9/22/2014
Public
Document Table of Contents
Document Table of Contents x
1. In-System Programmability Guidelines
1. In-System Programmability Guidelines x
1.1. General ISP Guideline 1.2. IEEE Std. 1149.1 Signals 1.3. Sequential versus Concurrent Programming 1.4. ISP Troubleshooting Guidelines 1.5. ISP through Embedded Processors 1.6. ISP through In-Circuit Testers 1.7. Document Revision History
1.1. General ISP Guideline x
1.1.1. Operating Conditions 1.1.2. User Flash Memory Operations During In-System Programming 1.1.3. Interrupting In-System Programming 1.1.4. MultiVolt Devices and Power-Up Sequences 1.1.5. I/O Pins Tri-Stated During In-System Programming 1.1.6. Pull-Up and Pull-Down of JTAG Pins During In-System Programming
1.1.1. Operating Conditions x
1.1.1.1. ISP Voltage 1.1.1.2. Input Voltages
1.2. IEEE Std. 1149.1 Signals x
1.2.1. TCK Signal 1.2.2. Programming Through a Download Cable 1.2.3. Disabling IEEE Std. 1149.1 Circuitry 1.2.4. Working with Different Voltage Levels
1.3. Sequential versus Concurrent Programming x
1.3.1. Sequential Programming 1.3.2. Concurrent Programming 1.3.3. Selecting Sequential or Concurrent Programming 1.3.4. Devices in Different Modes
1.4. ISP Troubleshooting Guidelines x
1.4.1. Invalid ID and Unrecognized Device Messages 1.4.2. Verify the JTAG Chain Continuity 1.4.3. Check the Voltage Levels of the Board During In-System Programming 1.4.4. Random Signals on JTAG Pins 1.4.5. Software Issues
1.5. ISP through Embedded Processors x
1.5.1. Processor and Memory Requirements 1.5.2. Porting the Jam Player
1. In-System Programmability Guidelines

1.1.2. User Flash Memory Operations During In-System Programming

If your design allows you to erase or write the MAX II, MAX V or MAX 10 device’s user flash memory (UFM), you must ensure that all the erase or write operations of the UFM are completed before starting any ISP session (including stand-alone verify, examine, setting security bit, and reading the contents of the UFM). If the UFM is performing any erase or write operation, you must not start an ISP session as this may put the device in an unrecoverable state. However, this restriction does not apply to the read operation of the UFM.

If you cannot ensure that any erase or write operation of the UFM is complete before attempting an ISP operation to the MAX II, MAX V or MAX 10 device, you must enable the real-time ISP feature. If used properly, this feature can help guard against any UFM or ISP operation contention. If you enable real-time ISP feature, the programming algorithm from the Quartus® II software, or Jam™ Standard Test and Programming Language (STAPL) Format (.jam) file/Jam Byte-Code (.jbc) file waits for 500 ms before it begins any operation, the same amount of time it takes to erase one UFM sector (that is, the real-time ISP programming algorithm waits for a previously started UFM erase operation to complete).

However, if you are using a real-time ISP feature, no other UFM operations are allowed after that time (no address shifting, no data shifting, and no read, write, or erase operations). You can control the UFM operations by monitoring the RTP_BUSY signal on the ALTUFM_NONE megafunction. If you are performing a real-time ISP operation, the RTP_BUSY output signal on the UFM block goes high. You can monitor the RTP_BUSY signal and ensure that all UFM operations from the logic array cease until real-time ISP is complete. This user-generated control logic is only necessary for the ALTUFM_NONE megafunction, which provides no auto-generated logic. The other parameter editors for the ALTUFM megafunction (ALTUFM_PARALLEL, ALTUFM_SPI, and ALTUFM_I2C) contain control logic that automatically monitors the RTP_BUSY signal and ceases UFM operations if you are performing the real-time ISP operation.

Related Information
Level Two Title