Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

About In-System Programming Using XCF32P Platform Flash PROM

Status
Not open for further replies.

twanlay123

Newbie level 1
Joined
Mar 11, 2010
Messages
1
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,292
Has anyone looked at xapp975 from xilinx? It is at
https://www.xilinx.com/support/documentation/application_notes/xapp975.pdf
It is a solution for In-system programming, has anyone used it to program the XCF32P successfully? I try to use it, but not successfully, always failed in the verify operation.
I want to ask some questons.
1. Is the CRC value in the .hex file, which the PFP module uses to verify the programmed PROM contents during the verification operation, is stored in little endian order like other programming data?
2. In the pdf, we can know that , after pfp module has received 256 bits of data, the PROM has to program the data into the actual Flash memory.
Is the 8-bit CRC value in the 256 bits of data, or we should send the CRC value first, and send the 256 bits of actual programming data secondly, and then wait the 256 bits of data shifted to the flash.

Thanks for help.
 

Re: About In-System Programming Using XCF32P Platform Flash

The HEX file format is a standardize format created by Intel. It has well defined format, refer to this PDF for this format:



Wiki Intel HEX Format

There is a CRC at the end of each line and a combine file CRC at end of the file.

How are you generating the HEX file? XBINUTIL utility they mention is no where to be found although ISE appears to have generate the correct file and program a XCF32P.

I found these examples in ISE 10.1:

Command Sequence Example 10: Generating a Two Device XCF00P Platform Flash PROM Design Revision Set of Files (.mcs and .cfi) with Two Revisions
1 setMode -pff
2 setSubmode -pffversion
3 addPromDevice -position 1 -name xcf32p
4 addPromDevice -position 2 -name xcf32p
5 addCollection -name test
6 addDesign -version 0 -name 0000
7 addDeviceChain -index 0
8 setCurrentDesign -version 0
9 addDevice -position 1 -file bitstream1a.bit
10 addDevice -position 2 -file bitstream2a.bit
11 addDesign -version 1 -name 1000
12 addDeviceChain -index 0
13 setCurrentDesign -version 1
14 addDevice -position 1 -file bitstream1b.bit
15 addDevice -position 2 -file bitstream2b.bit
16 generate -format mcs -fillvalue FF
17 quit
Description:
Sets the operating mode for PROM file generation.
Switches to the XCF00P Platform Flash PROM Design Revisioning Support sub-mode of the PROM file generation mode.
Adds a single XCF32P PROM to position 1.
Adds a single XCF32P PROM to position 2.
Sets design revision name to "test"
Adds design revision 0.
Adds a single chain to design revision 0.
The index needs to be set to zero for the PROM file generation sequence.
Sets the current design revision to 0.
Subsequent addDevice commands are directed to this design revision.
Adds bitstream1a.bit to the first position in the current design revision (set in step 8).
Adds bitstream2a.bit to the second position in the current design revision (set in step 8).
Adds design revision 1.
Adds a single chain to design revision 1.
The index needs to be set to zero for the PROM file generation sequence.
Sets the current design revision to 1.
Subsequent addDevice commands are directed to this design revision.
Adds bitstream1b.bit to the first position in the current design revision (set in step 13).
Adds bitstream2b.bit to the second position in the current design revision (set in step 13).
Generate test_0.mcs and test_0.cfi, using the "test" name specified in addCollection (line 5). The PROM checksum is calculated based on the devices expected fill value. The default fill value for checksum calculations is FF, which corresponds to the erased state of the PROM. The -path switch can be used to specify where to store the created PROM files.
Exits iMPACT.

Command Sequence Example 11: Programming a Two Device XCF00P Platform Flash PROM Design Revision Set with Two Revisions Using the PC IV Cable
1 setMode -bscan
2 setCable -port lpt1
3 setCableSpeed -speed 5000000
4 addDevice -p 1 -sprom xcf32p -file test_0.mcs
5 addDevice -p 2 -sprom xcf32p -file test_1.mcs
6 Program -p 1 2 -defaultVersion 0 -ver 0 erase verify -ver 1 erase
verify
7 quit
Description:
Sets the operating mode for Boundary-Scan (JTAG).
Tells iMPACT that the programming cable is connected to LPT1. iMPACT automatically polls the cable to determine whether it is a PCIII or PCIV cable.
Sets the cable TCK frequency for 5 MHz (5,000,000 Hz). This command is only valid for the PCIV cable and the MultiPRO Desktop Programmer.
Adds a Xilinx XCF32P ISP PROM to the first position in the JTAG chain, and assigns the test_0.mcs PROM file to it. The test_0.cfi file residing in the corresponding file location is automatically associated with test_0.mcs.
Adds a Xilinx XCF32P ISP PROM to the second position in the JTAG chain, and assigns the test_1.mcs PROM file to it. The test_1.cfi file residing in the corresponding file location is automatically associated with test_1.mcs.
Erases, programs and verifies both XCF32P devices in the JTAG chain with the default design revision set to zero. (See the "program" batch command definition for additional programming options available for the XCF00P Platform Flash PROM.)
Exits iMPACT.


If you are converting a BIT to HEX file manually, it may not be padded to a 256 bit boundary as stated in the PDF. An eight bit HEX file should be little endian, so I don't think endianess is an issue.

You may have to generate a BIT file, pad it to the next 256 bit boundary and then convert it to HEX.

Binary Conversion Utilities
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top