AN2026c. Application Note Abstract. Introduction

Transcription

1 In-System Serial Programming (ISSP) Protocol for CY8C20x36, CY8C20x46, CY8C20x66, CY8C20x96, CY8C20x36A, CY8C20x46A, CY8C20x66A, CY8C20x96A, CY8CTMG2xx, and CY8CTST2xx Application Note Abstract AN2026c Author: Derek Valleroy Associated Project: No Associated Part Family: CY8C20x36, CY8C20x46, CY8C20x66, CY8C20x96 CY8C20x36A, CY8C20x 46A, CY8C20x 66A, CY8C20x 96A CY8CTMG2xx, CY8CTST2xx Software Version: PSoC Designer 5.0 Associated Application Notes: AN2014, AN2026a, AN2026b This application note describes how to program a PSoC 1 device using the In System Serial Programming (ISSP) protocol. There are other ISSP protocol application notes for various PSoC families. Refer to those application notes for the family of interest. Introduction In-circuit programming is convenient for prototyping, manufacturing, and in-system field updates. The PSoC emulator pod and individual chips are programmed in-system using the Cypress ICE-Cube, MiniProg, CY3207 ISSP Programmer, or a third-party programmer. PSoC Designer or PSoC Programmer software can be used with the ICE-Cube or MiniProg. This application note provides programming timing and vectors so that developers and programmer vendors can create their own in-system programming solutions for a PSoC device. There are two participants in the programming procedure: the programmer and the target device. The programmer communicates serially with the target, supplies the clocking, and sends commands to the target. The target receives data from the programmer and supplies data upon a read request. The target drives the data line only upon request from the programmer. The programmer programs the target with the program image contained in the <PROJECT NAME>.hex file, which is generated by PSoC Designer. Refer to Appendix B on page 14 for more information regarding the Intel.hex file format. The electrical pin connections between the programmer and the target are listed in Table 1. This includes two signal pins, a reset pin, a power pin, and a ground pin. Leave the other pins floating. The pin naming conventions and drive strength requirements are also listed in Table 1. For more information about the physical requirements of the connections between the programmer and target, refer to application note AN2014, Design for In-System Serial Programming (ISSP). Differences from Previous PSoC Devices There are several differences in programming the CY8C20xx6, CY8C20xx6A, CY8CTMG2xx, and CY8CTST2xx devices compared with previous devices. Other application notes such as AN2026a and AN2026b describe the ISSP protocol for earlier PSoC devices. The distinctive aspects of ISSP programming for CY8C20xx6, CY8C20xx6A, CY8CTMG2xx, and CY8CTST2xx are: The minimum XRES pulse length to program the device is increased to 263 µs. The Wait-and-Poll timeout period is increased to 200 ms. The READ-CHECKSUM, READ-STATUS, and READ- BYTE vectors require two Z states between address and data. The time between a power up event and the assertion of XRES to enter test mode is increased to 2.47 ms. While waiting for a High-to-Low transition during the Wait-and-Poll period, the host must not toggle SCLK. The CY8C20xx6, CY8C20xx6A, CY8CTMG2xx, and CY8CTST2xx devices may use a 1.8V programming supply voltage. The program flow and most vectors used are different. February 24, 2010 Document No Rev. *A 1

2 Table 1. Pin Names and Drive Strengths Pin Name Function Programmer HW Pin Requirements P1[0]P SDATA Serial Data In/Out Drive TTL Levels, Read TTL, High Z P1[1] SCLK Serial Clock Drive TTL Levels XRES Reset Drive TTL Levels. Active High V ss Power Supply Ground Connection Low Resistance Ground Connection V DD Positive Power Supply Voltage 0V, 1.8V, 3.3V, 5V. 20 ma Current Capability Programming Flow Successful target programming depends on adherence to the programming flow shown in Figure 1. Each procedure is explained in the following sections. Failure to complete these steps can result in incorrectly programmed Flash. Figure 1. Target Programming Flow START Insertion Check Verify Silicon ID (Includes Power-Up) Re-run Check (Optional) Erase Program and Verify Set Security Verify Security (Optional) Device Checksum Power Down Vectors Vectors are the binary representation of the commands necessary to perform various operations involved in the programming flow. Each procedure in the programming flow includes multiple vectors (see Appendix A on page 11) referred to as mnemonics. Each vector is either 22 or 23 bits long and any number of zeros can be sent between sequential vectors. The target ignores the zero padding and any subsequent 0 on the SDATA line. This continues until the target receives a 1, which is the first bit in the next vector in the vector-set. Clocking During the programming flow, the programmer supplies a clock on SCLK to transfer data. This data transfer mode is used while the programmer communicates with the target, either by sending or receiving data. During this time, the programmer can drive the SCLK signal at any frequency that enables reliable data transfer with a maximum transmit frequency of 8 MHz (see F SCLK in Table 3 on page 9). The frequency of SCLK does not need to be accurate or consistent, as long as it is less than the 8 MHz limit. Clocks are not allowed during the Wait and Poll steps described in the procedure flowcharts. Command Format During programming, only the programmer drives the SCLK line. The programmer and target can drive the SDATA line, although the target drives SDATA only upon a read request from the programmer. The programmer always writes and reads SDATA on the rising edge of SCLK, while the target writes and reads on the falling edge. After the programmer requests a read from the target (see READ-BYTE in Appendix A and Appendix C), it releases the SDATA to a High Z state and resumes driving the line only after the byte is sent by the target. The programmer supplies clocks even when it has released (High Z) the SDATA line when reading data from the target. During the Wait and Poll procedure, the programmer releases (High Z) the SDATA line and must wait for a High to Low transition on SDATA. Additionally, the programmer must not supply clocks on SCLK during the Wait and Poll procedure. End February 24, 2010 Document No Rev. *A 2

3 Wait and Poll After a mnemonic bit stream is sent, the SDATA line typically takes 1 µs to drift low (the SDATA line drifts low to V ILP by the device s internal pull down resistor). Clocking is needed before SDATA transitions from low to high. At least one SCLK should be sent, but more may be needed before SDATA transitions from low to high. The target device pulls SDATA high when the mnemonic begins executing. A minimum delay of 416 ns (or ten 12 MHz CPU clock cycles) is needed before the target pulls SDATA high. Programming mode is entered by reset mode or power-on mode. If there is no XRES pin on the device, power-on mode must be used. Note that because power on mode involves cycling power to the target, in-circuit field programming may involve PCB layout considerations in the design phase. Furthermore, if the XRES method is used, special attention must be given to any external circuitry connected to XRES on the target board. External circuitry must not interfere with the timing on XRES. Figure 2. Verify Silicon ID Procedure The device outputs a logic high on the SDATA pin while the mnemonic is executing and then switches to a logic low when the mnemonic finishes. The programmer must wait and poll the SDATA pin for the high to low transition. The maximum SDATA high time is 200 ms (see T POLL in Table 3 on page 9). Assert V DD Reset mode Verify Silicon ID Power on or Reset mode? Power on mode Assert V DD When the transition to low is observed, the programmer must apply a bit stream of 40 zero bits to the SDATA pin of the device and then continue to the next mnemonic. Refer to Appendix C for the Wait and Poll timing diagram. Programming Pin Drive Modes Is XRES Applied with V DD? Assert XRES for at least T VDDXRES (2.47ms) Wait for at least T VDDXRES (2.47ms) Assert XRES for at least 263µs Wait for T VDDWAIT The pin drive modes vary during the programming operation. When the PSoC drives the SDATA line to indicate it has started up completely or to send data back to the host, SDATA is in a strong drive configuration. When it waits for or receives data, SDATA is in a pull down configuration. Design the external pin drive mode circuitry so that a strong high to resistive low transition can be detected and the pin is driven both high and low when it is in pull down mode. Wait 0.5µs following the de-assertion of XRES Wait 0.5µs following the de-assertion of XRES ID-SETUP-1 Insertion Check The programmer should test the physical orientation of the device before fully applying V DD. The insertion check ensures that V DD and GND of the device are correctly oriented in the socket or on the board. The programmer should execute a pin continuity test to verify electrical connection to all of the required port pins listed in Table 1. The port pins have an industry standard reverse bias diode that can be used for the continuity test. ID-SETUP-2 READ-ID-WORD Verify Silicon ID The Verify Silicon ID procedure places the chip in programming mode and reads the silicon ID of that chip. If the silicon ID does not match the expected value, the programmer must abort the programming process and send an error message to the device programmer s operator. The Verify Silicon ID procedure must be the first procedure in the flow, following insertion check, and cannot be bypassed. Programming Failed SYNC-DISABLE Is Silicon ID Correct? End Verify Silicon ID February 24, 2010 Document No Rev. *A 3

4 Reset Mode The timing to enter programming mode with Reset is shown in Appendix C. To initialize the part using the XRES line, first wait until V DD is stable, then wait for 2.47 ms (T VDDXRES) and assert the XRES line for the time specified by T XRES (see Table 3 on page 9). The XRES line may also be brought up with the power supply line, in which case, XRES must be held high for at least 2.47 ms (T VDDXRES). After XRES is driven low, there is a window of time specified by T XRESACQ, as shown in Table 3 on page 9, in which the first nine bits of the ID-SETUP-1 vector-set must be transmitted. While the target executes the ID-SETUP-1 mnemonic, it drives the SDATA line high. The programmer must wait and poll the SDATA line for a high to low transition, which is the signal from the target that the ID-SETUP-1 mnemonic is complete. Following the ID-SETUP-1 mnemonic, send the ID-SETUP- 2 mnemonic, and then wait and poll. Next, send the SYNC- ENABLE, READ-ID-WORD, and SYNC-DISABLE mnemonics (See Appendix A for mnemonic bit streams). Power-On Mode To initiate communication with the target using power-on mode, apply VDD to the target as shown in Appendix C on page 17. The target drives the SDATA line high. The programmer then waits and polls for a high to low transition on the SDATA line, which is the signal from the target that VDD has stabilized. Note that until VDD stabilizes, the SDATA signal is noisy and a false edge could be detected. As a result, the programmer must wait for the time specified by TVDDWAIT (Table 3 on page 9) before beginning to wait and poll. The programmer must also not drive the SCLK signal until the TVDDWAIT time period has passed. After the SDATA transition is detected, the programmer must transmit the ID-SETUP-1 vectors in T ACQ seconds (see Table 3) and wait and poll for a high to low transition on SDATA. Following the ID-SETUP-1 mnemonic, send the ID-SETUP- 2 mnemonic and then wait and poll. Next, send the SYNC- ENABLE, READ-ID-WORD, and SYNC-DISABLE mnemonics (See Appendix A on page 11 for mnemonic bit streams). During the power cycle phase of the Initialize Target Procedure, VDD must be the only pin asserted. XRES must be low. The PSoC's internal pull down resistor on XRES achieves this if the pin is left floating externally. Power-On Mode with External Supply Acquiring the device through power on mode is possible even if the device uses an external power supply. Special care must be taken with the timing and voltage levels of the device and power supply. This is because the programmer does not have control over the power supply in this scenario. The programmer must be able to detect the supply voltage to determine when the supply has reached the minimum programming level and nominal supply voltage (for example, 1.8V, 3.3V, 5V). As shown in Appendix C on page 17, the programming sequence timing is initiated when the supply voltage reaches 1.66V (±3%). At this point, the programmer must wait a certain amount of time before starting the Wait and Poll procedure. As shown in Table 2, the high and low signal thresholds (V ILP, V IHP) are dictated by the power supply level of the target. Note that it is possible to use 3.3V signal levels even if the target is powered by a 5V supply. However, it is not possible to use 3.3V signal levels if the target is powered by a 1.8V supply. A particular area of concern is the power supply ramp rate of the target. For an extremely slow ramp rate (< 0.5 V/ms), it is possible that the supply voltage may not reach the nominal voltage before the programming mode acquisition window closes. In this case, the programmer should specify a minimum supply ramp rate or develop an intelligent way to track the supply voltage and dynamically change the signal levels to match the supply voltage. Read-ID-Word The silicon ID value is read back using the READ-ID-WORD vector-set. The first two byes read back from the device for a READ-ID-WORD vector contain the silicon ID. The vectors in Appendix A on page 11 under READ-ID-WORD show the device-specific values read from the target. For example, a LLLLLLLL, HLLHHLHL denotes a 0x009A hex read back from a CY8C The programmer must compare the value in the READ-ID-VECTOR and the value returned by the target. If these values do not match, the programmer must terminate the programming flow. February 24, 2010 Document No Rev. *A 4

5 Re-run Check (Optional) The Re-run Check procedure compares the device flash checksum with the hex file to see if the chip has been previously programmed. When this feature is enabled, the chip inside a socket fails when it is programmed a second time. The Re-run Check is an optional feature for production programmers connected to a handler. The Re-run Check is accomplished by the sequence shown in Figure 3. The CHECKSUM-SETUP,, READ-CHECKSUM, and SYNC-DISABLE bit streams are shown in Appendix A on page 11. Refer to the Wait and Poll section on page 3 for detailed timing information on the procedure. Figure 3. Re-Run Check Procedure Re-run Check CHECKSUM-SETUP Program and Verify The Program and Verify procedure programs the flash with the contents of the user s programming file. The READ- STATUS vector is used to determine the pass/fail success of the PROGRAM-AND-VERIFY vector. A programming failure results in a 0x04 value and a pass results in a 0x00 value. The Program and Verify procedure is accomplished by the sequence shown in Figure 5. Figure 5. Program and Verify Procedure Program and Verify num_block = 0 READ-WRITE-SETUP Address = 0 Increment Address WRITE-BYTE (Address, data) READ-CHECKSUM Address > 127? SYNC-DISABLE Increment num_block SET-BLOCK-NUM (num_block) Is the Checksum the Same? SYNC-DISABLE PROGRAM-AND- VERIFY Programming Failed End Re-run Check Erase The Erase Procedure erases the entire Flash memory and the security data (all set to zero). Erase is accomplished by sending the ERASE vector followed by the WAIT-AND- POLL procedure (see Figure 4). Figure 4. Erase Procedure READ-STATUS SYNC-DISABLE Program Error? Erase ERASE num_block > max_data_block? End Program and Verify Programming Failed End Erase February 24, 2010 Document No Rev. *A 5

6 Set Security The Set Security procedure is performed after the device is successfully programmed. The SECURE mnemonic protects certain flash blocks from being read or changed. The security data for each block is located at the end of the hex file; see Appendix B on page 14 for format details. The Set Security procedure is shown in Figure 6. Figure 6. Set Security Procedure Set Security Figure 7. Verify Security Procedure Verify Security (Optional) READ-SECURITY -SETUP Address = 0 Address = 0 READ-SECURITY-1 (address) READ-WRITE-SETUP Increment Address SYNC-DISABLE Increment Address WRITE- BYTE READ-SECURITY-2 Address > 63? SECURE READ-SECURITY-3 (Address) End Set Security Verify Security (Optional) In the optional Verify Security procedure, the programmer reads the security data from the chip and stores it in memory. This data is compared with the user s programming file or the security data used in the Set Security step. The Verify Security procedure is shown in Figure 7. Address > 63? Address = 0 Increment Address READ-BYTE (Address, data) Address > 63? SYNC-DISABLE End Verify Security February 24, 2010 Document No Rev. *A 6

7 Device Checksum In the Device Checksum procedure, the checksum is retrieved from the device and compared to the device checksum set in the user s file. Note that the device checksum is not the same as the record checksum. The Device Checksum procedure is shown in Figure 8. Figure 8. Device Checksum Procedure Device Checksum CHECKSUM-SETUP Note that the Program and Verify procedure already performs a verify check between the Flash and programming file. Therefore, it is not necessary to perform the optional Verify procedure. The max_data_block value for each device is listed in Table 4 on page 10. The Verify procedure is shown in Figure 10. Figure 10. Verify Procedure Verify (Optional) num_block = 0 READ-WRITE-SETUP READ-CHECKSUM SET-BLOCK-NUM (num_block) SYNC-DISABLE Increment num_block SYNC-DISABLE End Device Checksum VERIFY-SETUP Power Down The last step in the programming data flow is to power down the device. Power down is accomplished by the sequence shown in Figure 9. Figure 9. Power Down Procedure READ-STATUS Power Down READ-WRITE -SETUP Set SDATA = HighZ * Float P1[0] Set SCLK = 0V * Vin on pin P1[1] = V ILP Increment Address READ-BYTE (Address, data) Set V DD = 0V Address > 127? End Power Down Verify (Optional) The Verify procedure reads data from the device s Flash so that it can be compared to the programming file. The READ- STATUS vector is used to determine if the block is protected or not. The READ-STATUS vector returns a 0x01 for a secured block, and the actual data read from that block will be invalid. In the case of a secured block, the programmer should display XX for the data in the block. num_block > max_data_block? SYNC-DISABLE End Verify February 24, 2010 Document No Rev. *A 7

8 Specifications and Definitions DC Programming Specifications Note These specifications are from the CY8C20xx6 and CY8C20xx6A data sheets. To view the complete data sheet visit the Cypress web site. Table 2. DC Programming Specifications DC Programming Specifications Minimum Typical Maximum V DDP (V DD for Programming and Erase) 1.71V 3.3V 5.25V [1] I DDP (Supply Current During Programming or Verify) 5 ma 25 ma V ILP (Input Low Voltage During Programming or Verify) Vddp >=2.6V 0V 0.8V V IHP (Input High Voltage During Programming or Verify) 2.00V V DDP Vddp + 0.3V I ILP (Input Current when Applying V ILP to P1[0] or P1[1] during Programming or Verify) I IHP (Input Current when Applying V IHP to P1[0] or P1[1] during Programming or Verify) V OLV (Output Low Voltage During Programming or Verify, I OL=0.1 ma) 0.20 ma 1.5 ma V ss+0.75v V OHV (Output High Voltage During Programming or Verify I OH=5 ma) V DDP-0.9V V DDP Note 1. Specification is for CY8C20xx6A devices. Maximum V DD for CY8C20xx6 devices is 5.5V. February 24, 2010 Document No Rev. *A 8

9 AC Programming Specifications Table 3. AC Programming Specifications AC Programming Specifications Minimum Maximum T XRES (XRES Pulse Width [1] ) 263 µs T XRESACQ (XRES Programming Mode Acquisition Window) 98 µs 615 µs T ACQ (V DD Power-On Programming Mode Acquistion Window [2] ) 3.2 ms 19.6 ms T VDDWAIT (V DD Stable to Wait-and-Poll Hold Off [3] ) 0.1 ms 1 ms T VDDXRES (V DD Stable to XRES assertion delay) 2.47 ms T POLL (SDATA High Pulse Time [4] ) 10 µs 200 ms T RSCLK (Rise Time of SCLK) 1 ns 20 ns T FSCLK (Fall Time of SCLK) 1 ns 20 ns T SSCLK (Data Set Up Time to Falling Edge of SCLK) T HSCLK (Data Hold Time From Falling Edge of SCLK) 40 ns 40 ns F SCLK (Frequency of SCLK) 0 MHz 8 MHz T DSCLK (Data-Out Delay from Falling Edge of SCLK. 3.6V < V DD) 60 ns T DSCLK (Data-Out Delay from Falling Edge of SCLK. (3.0V V DD 3.6V) 85 ns T DSCLK (Data-Out Delay from Falling Edge of SCLK. (1.71V V DD 3.0V) 130 ns Notes 1. See Acquire Sequence Timing using XRES External Reset Acquire in Appendix C on page 17. Times longer than T XRES may be used without consequence. 2. The ID-SETUP-1 bit stream data must not be delayed more than T ACQ from the end of the (measured from SDATA s falling edge). 3. Until V DD stabilizes, SDATA is noisy and the falling edge should not be searched for. A delay of T VDDWAIT is needed after V DD is applied and before 4. T POLL applies to the procedure. SDATA remains high for the T POLL time. February 24, 2010 Document No Rev. *A 9

10 Device Address and Block Definitions Table 4. Device Address and Block Definitions Device Address Numbers for Bytes within a Block Block Numbers for Program Data Max_data_block CY8C20066, CY8C20066A CY8C20236, CY8C20236A CY8C20246, CY8C20246A CY8C20266, CY8C20266A CY8C20296, CY8C20296A CY8C20336, CY8C20336A CY8C20346, CY8C20346A CY8C20366, CY8C20366A CY8C20396, CY8C20396A CY8C20436, CY8C20436A CY8C20446, CY8C20446A CY8C20466, CY8C20466A CY8C20496, CY8C20496A CY8C20536, CY8C20536A CY8C20546, CY8C20546A CY8C20566, CY8C20566A CY8C20636, CY8C20636A CY8C20646, CY8C20646A CY8C20666, CY8C20666A CY8CTMG CY8CTMG CY8CTST Summary This application note describes the distinctive characteristics of In-System Serial Protocol programming for the CY8C20xx6, CY8C20xx6A, CY8CTMG2xx, and CY8CTST2xx PSoC devices. The correct programming flow procedures that help to create ISSP solutions, are explained in detail. February 24, 2010 Document No Rev. *A 10

11 Appendix A Programming Vectors for CY8C20x36, CY8C20x46, CY8C20x66, CY8C20x96, CY8C20x36A, CY8C20x46A, CY8C20x66A, CY8C20x96A, CY8CTMG2xx, CY8CTST2xx Table 5. Programming Vectors Name Data Vector ID-SETUP-1 ID-SETUP-2 SET-BLOCK- NUM CHECKSUM- SETUP READ- CHECKSUM PROGRAM- AND-VERIFY Bit Stream (Executed From Left Bit to Right) dddddddd111 Where dddddddd is the block number ZZDDDDDDDDZ ZZddddddddZ1 Where DDDDDDDD is the Device Checksum upper byte (MSB) dddddddd is the Device Checksum lower byte (LSB) ERASE SECURE READ- SECURITY- SETUP READ- SECURITY-1 READ- SECURITY-2 READ- SECURITY-3 READ-WRITE- SETUP WRITE-BYTE VERIFY- SETUP READ-STATUS aaaaaaa Where aaaaaaa = address (7 bits) aaaaaaa Where aaaaaaa = address (7 bits) aaaaaaadddddddd111 Where aaaaaaa = address (7 bits), dddddddd = data in ZZDDDDDDDDZ1 Where DDDDDDDD = data out February 24, 2010 Document No Rev. *A 11

12 Name Data READ-BYTE SYNC- DISABLE 1011aaaaaaaZZDDDDDDDDZ1 Where aaaaaaa = address (7 bits), DDDDDDDD = data out READ-ID-WORD (CY8C20066, CY8C20066A) ZZLLLLLLLLZ ZZHLLHHLHLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20236, CY8C20236A) ZZLLLLLLLLZ ZZHLHHLLHHZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20246, CY8C20246A) ZZLLLLLLLLZ ZZHLHLHLHLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20266, CY8C20266A) ZZLLLLLLLLZ ZZHLLHLHHLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20296, CY8C20296A) ZZLLLLLLLLZ ZZHLHHHHLLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20336, CY8C20336A) ZZLLLLLLLLZ ZZHLHHLHLLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20346, CY8C20346A) ZZLLLLLLLLZ ZZHLHLHHLLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20366, CY8C20366A) ZZLLLLLLLLZ ZZHLLHLHHHZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20396, CY8C20396A) ZZLLLLLLLLZ ZZHLHLHHHHZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20436, CY8C20436A) ZZLLLLLLLLZ ZZHLHHLHLHZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20446, CY8C20446A) ZZLLLLLLLLZ ZZHLHLHHLHZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20466, CY8C20466A) ZZLLLLLLLLZ ZZHLLHHLLLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20496, CY8C20496A) ZZLLLLLLLLZ ZZHLHHHHLHZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20536, CY8C20536A) ZZLLLLLLLLZ ZZHLHHHLLHZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20546, CY8C20546A) ZZLLLLLLLLZ ZZHLHLHHHLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20566, CY8C20566A) ZZLLLLLLLLZ ZZHLLHHLLHZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20636, CY8C20636A) ZZLLLLLLLLZ ZZHLHHHLHLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20646, CY8C20646A) ZZLLLLLLLLZ ZZHLHHHLLLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8C20666, CY8C20666A) ZZLLLLLLLLZ ZZHLLHHHLLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8CTMG200-00LTXI) ZZLLLLLHHHZ ZZHLLHHLHLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8CTMG200-32LQXI) ZZLLLLLHHHZ ZZLHHLHHHLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8CTMG200-48LTXI) ZZLLLLLHHHZ ZZLHHLHHHHZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8CTMG201-32LQXI) ZZLLLLLHHLZ ZZLHHLLLHHZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 February 24, 2010 Document No Rev. *A 12

13 Name Data READ-ID-WORD (CY8CTMG201-48LTXI) ZZLLLLLHHLZ ZZLHHLLHLLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8CTST200-16LQXI) ZZLLLLLHHLZ ZZLHHLHHLLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8CTST200-24LQXI) ZZLLLLLHHLZ ZZLHHLHHLHZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8CTST200-32LQXI) ZZLLLLLHHLZ ZZLHHLHHHLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8CTST200-48LTXI) ZZLLLLLHHLZ ZZLHHLHHHHZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 READ-ID-WORD (CY8CTST200-48PVXI) ZZLLLLLHHLZ ZZLLLHHHLLZ ZZLHLHLLHLZ ZZLLHLLLLHZ1 Notes 1=Logic high=vihp 0=Logic low=vilp Z=High Z (floating) D=Data read from device (Most Significant Bit [MSb] of binary data comes out first) d=data applied to the device (MSb of the binary data goes in first) a=address applied to the device (MSb of the binary data goes in first) H=High data read from the device (Vout=VOHV) L=Low data read from the device (Vout=VOLV) If the Programmer has delays between executing the different mnemonics, SDATA must be High Z (floating) during these delays. February 24, 2010 Document No Rev. *A 13

14 Appendix B IntelHex File Format for CY8C20x36, CY8C20x46, CY8C20x66, CY8C20x96, CY8C20x36A, CY8C20x46A, CY8C20x66A, CY8C20x96A, CY8CTMG2xx, CY8CTST2xx IntelHex file records are a text representation of Hexadecimal coded binary data. Because only ASCII characters are used, the format is portable across all computer platforms. PSoC Designer generates this file and stores it under the <PROJECT_DIR>/OUTPUT directory. Each line in an IntelHex file is called a 'record'. The Flash program data and end data are made up of a single record. The security data and checksum data are made up of multiple records. These data each have an extended linear address record and one or more records. Records always begin with a colon (:), followed by the number of data bytes in each record. For the devices, Flash program data records always use 64 bytes of data so the Hexadecimal value in the file is always $40 for that type. For Flash programming data records, the next pair of numbers represents the 16-bit starting address of the data in the record. This is the absolute location in the Flash memory. This number must be a multiple of 64 ($00, $40, $80, $C0, and so on) for Flash program data records because each record contains 64 bytes. The starting address is followed by a byte representing the record type. If this is $00, the next bytes are the actual program data to be stored in Flash. A $01 indicates that this is the end of the file. A $04 indicates an Extended Linear Address Record and is used for security data and device checksum data storage (see the following examples). The security and checksum data use multiple records because they have longer addresses than the other data. The first record, the Extended Linear Address Record, gives the upper bytes of the address of the data in memory. The other records give the lower bytes of the address along with data. Following the record type are the Hexadecimal representations of the data to be stored. The last byte is a two's-complement checksum of all of the bytes in the record, not including the colon this is called the record checksum. Note that this value is derived from the binary values of the bytes rather than the ASCII representation. Typically, a standard CR/LF pair (carriage return/linefeed, $0D $0A) terminates the record. Other end-of-line conventions are also acceptable (like CR only). Example Flash Program Data Record :4000C A5B5C5D5E5F E8(CR/LF) Broken down, it is as follows: : - Colon, indicates that this is IntelHex 40 - Number of data bytes to follow = $40(40 hex) 00C0 - Starting address in the FLASH for record This is the record type -- $00 = Data A5B5C5D5E5F These are 64 bytes of data in hex as noted above. The first byte ($50) will be stored at $00C0, with the remaining bytes following in sequence. E8 - This is record checksum. If you add all of successive bytes (note that the address is treated as two individual bytes), and truncate it to the lowest eight bits, the result is $18. The two's complement of $18 is $E8. (This may be derived by subtracting $18 from $100, or by inverting the bits and adding one to the result.) (CR/LF) - End of this record. February 24, 2010 Document No Rev. *A 14

15 Example Security Data Records : ea(CR/LF) : (CR/LF) : - Colon, indicates IntelHex 02 - Number of data bytes 2 bytes of data Address - zero 04 - This is the record type -- $04 indicates Extended Linear Address record hex data bytes used here byte 1 has $00, byte 2 has $10 data. This indicates that the security data is offset in memory space ($0010 is used for security data). ea - The record checksum, calculated as above. (CR/LF) - End of this record. : - Colon, indicates that this is IntelHex 40 - Number of data bytes 64 bytes Address zero 00 - Record type - $00 indicates data record data bytes here bytes have $55 data 80 - The record checksum, calculated as above. (CR/LF) - End of this record. Additional Notes on Security Records The security data must be in the file after all FLASH program data records are specified. As seen in the previous example, security data use multiple records (one to access the extended memory space, and others for the data). There is one security data record for every 256 blocks of flash. For devices with under 256 blocks of flash, the record is still 64 bytes long. The most significant bytes are used, and the remainder are ignored. The extended linear address record that precedes the security data record always specifies the same data, and as a result, always has the same checksum. This record can be copied from a known good hex file. The data of the security data record indicates the flash security settings specified in PSoC Designer, in flashsecurity.txt. Each letter in flashsecurity.txt indicates the security settings for one block of flash space. Each letter is encoded into two bits of a hex digit in the security data record. Four blocks' settings are concatenated into two digits of data, in reverse order. The encoding may be further examined by changing flashsecurity.txt and generating hex files. February 24, 2010 Document No Rev. *A 15

16 Example Device Checksum Data Records : da(CR/LF) : a9f(CR/LF) : - Colon, indicates that this is IntelHex 02 - Number of data bytes 2 bytes of data Address - zero 04 - This is the record type -- $04 indicates Extended Linear Address record hex data bytes used here byte 1 has $00, byte 2 has $20 data. This indicates that indicates that the checksum data is offset in memory space ($0020 is use for checksum data). da - The record checksum, calculated as above. (CR/LF) - End of this record. : - Colon, indicates that this is IntelHex 02 - Number of data bytes 2 bytes of data Address - zero 00 - Record type -- $00 indicates data record 253a - 2 hex data bytes used here byte 1 has $25, byte 2 has $3a data. The data is a 2 byte checksum of all of the data stored in flash. 9f - The record checksum, calculated as above. (CR/LF) - End of this record. Additional Notes on Device Checksum Data Records The device checksum data must be in the file after all security data records are specified. As seen in the previous example, device checksum data use two records (one to access the extended memory space, and the other for the data). The extended linear address record that precedes the checksum data record always specify the same data, and as a result, always have the same checksum. This record can be copied from a known good hex file. End Record (End of File) : FF(CR/LF) : - Colon, indicates that this is IntelHex 00 - Number of data bytes - zero Address - zero 01 - Record type -- $01 indicates end record, - no data bytes used FF - The record checksum, calculated as above. (CR/LF) - End of this record. February 24, 2010 Document No Rev. *A 16

17 Appendix C Timing Waveforms Figure 11. Sequence Timing Figure 12. Timing Waveforms for AC Programming Specifications Figure 13. Acquire Sequence Timing using V DD Power-On Mode Acquire February 24, 2010 Document No Rev. *A 17

18 Figure 14. Acquire Sequence Timing using XRES External Reset Acquire Figure 15. Beginning of Silicon ID Sequence Timing tvddwait tpoll Device driving a 1 Device driving a 0 Programmer driving a 1 Programmer driving a 1 Programmer driving a 0 February 24, 2010 Document No Rev. *A 18

19 Figure 16. READ-BYTE Vector Waveform The programmer must change SDATA on the positive edge of SCLK to allow enough time for the device to clock in data on the negative edge of SCLK. The programmer must present resistive drive to ground and strong drive to V DD during Reads. The programmer clocks in two high-zs in between the address and data bits. The programmer clocks in one high-z in between the data bits and the final 1 bit. When the device is driving the SDATA line, the device changes SDATA on the negative edge of SCLK. The data must be read on SDATA greater than T DSCLK from the falling edge (see AC Specification Section) Summary About the Author Name: Title: Background: Contact: Derek Valleroy Applications Engineer Sr. Derek Valleroy has worked as an Applications Engineer with Cypress since 2007 and has been in the semiconductor industry since vzd@cypress.com February 24, 2010 Document No Rev. *A 19

20 Document History Document Title: In-System Serial Programming (ISSP) Protocol for the CY8C20x36, CY8C20x46, CY8C20x66, CY8C20x96, CY8C20x36A, CY8C20x46A, CY8C20x66A, CY8C20x96A, CY8CTMG2xx, CY8CTST2xx Document Number: Revision ECN Orig. of Change Submission Date ** VZD 11/18/09 New Application Note Description of Change *A DST 02/09/ Changed App Note number from to AN2026c 2. Updated diagram (Figure 11) and changed description changed to match Programming Spec 3. Added to Program and Verify Procedure Flowchart (Figure 5) to match Programming Spec 4. Updated DC Specs table to match Programming Spec 5. Added support for TMG2xx and TST2xx families 6. Removed values from Figure 13and Figure 14 PSoC is a registered trademark and PSoC Designer is a trademark of Cypress Semiconductor Corp. All other trademarks or registered trademarks referenced herein are the property of their respective owners. Cypress Semiconductor 198 Champion Court San Jose, CA Phone: Fax: Cypress Semiconductor Corporation, The information contained herein is subject to change without notice. Cypress Semiconductor Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source Code except as specified above is prohibited without the express written permission of Cypress. Disclaimer: CYPRESS MAKES WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT T LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress product in a life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. Use may be limited by and subject to the applicable Cypress software license agreement. February 24, 2010 Document No Rev. *A 20