Forum Discussion
Altera_Forum
Honored Contributor
Honored Contributorabout the CONF_DONE in the PS configuration
Dear all, I am trying to configure the Cyclone III device using the Passive Serial mode. In the very beginning, I draw the nCONFIG low, and subsequently the Cyclone III draw the nSTATUS low....the question is: why CONF_DONE is always low from the very beginning? As to the configuration handbook, there should be a high-to-low transition for the CONF_DONE... why?
In addition, there is said to be a low-to-high transition for the CONF_DONE in the end of the configuration, I just want to know, how does the Cyclone device know the configuration is done ? PS. MSEL is 0000, and the clock is 1M, and the file format is .hex. Thanks !37 Replies
Altera_Forum--- Quote Start --- I currently have the .rbf file stored in flash. I am reading it a byte at a time and sending the LSB-first. for example: one byte in the file is 6A i am reading 6A and sending it in this order 01010110 (left bit first). Is this correct? --- Quote End --- The order of the bytes is still dependent on the processor. Use u-boot on the board and read the contents of the flash location, eg., lets say the flash was located at F800_0000h, then you can read 32 bytes using
Now look at your .rbf file. Does the ordering of the bytes match? If the bytes are reversed in pairs or quads, then it just indicates that the flash programmer read data into a big-endian word before programming it. You can either fix the programmer code, or write a program to flip the bytes in your .rbf file before passing that modified file to the programmer. Cheers, Dave=> md.b f8000000 20 f8000000: 2f 0c 40 08 86 af 07 33 ff ff 7f 12 ff ff ff 02 /[email protected]........ f8000010: 22 07 05 19 24 ff ff ff ff ff ff ff ff ff ff ff "...$...........- Altera_Forum
I currently have the .rbf file stored in flash. I am reading it a byte at a time and sending the LSB-first. for example: one byte in the file is 6A i am reading 6A and sending it in this order 01010110 (left bit first). Is this correct?
- Altera_Forum--- Quote Start --- I am having the same issue where I am able to clock all of the data and NSTATUS stays high showing no errors but I never get the CONF_DONE going high at the end of the transfer. I am using an MPC8309 and programming a Cyclone III using PS. Does the file need to be built a certain way for passive serial? --- Quote End --- Are you serializing your bits correctly? The MPC8309 is a big-endian PowerPC, perhaps you are reading 32-bits and sending out the 4 bytes in the wrong order? Look at the bytes in the .rbf or .rpd file, and then knowing that they are shifted LSB-first, look at the serialized data on your DATA0 FPGA pin, or just look at your code. Cheers, Dave
- Altera_Forum
Was this resolved? I am having the same issue where I am able to clock all of the data and NSTATUS stays high showing no errors but I never get the CONF_DONE going high at the end of the transfer. I am using an MPC8309 and programming a Cyclone III using PS. Does the file need to be built a certain way for passive serial?
Thanks Jordan - Altera_Forum--- Quote Start --- JTAG can program well and when it's done, nCONF_DONE is high. --- Quote End --- So what change did you make to get things working? Cheers, Dave
- Altera_Forum--- Quote Start --- Dave, thanks for your quick reply !!! May I send the .hex file and the .rbf file to your email box? There seems no difference, except there is no CRCs in the .rbf file..... --- Quote End --- Yeah, thats fine. Send it to the email that is my forum name. Send the Quartus .qsf file too, since that'll have the device settings. Put the files in a zip file. Cheers, Dave
- Altera_Forum
Dave, thanks for your quick reply !!! May I send the .hex file and the .rbf file to your email box? There seems no difference, except there is no CRCs in the .rbf file.....
- Altera_Forum--- Quote Start --- Dave, thanks, JTAG can program well and the nSTATUＳ is high, there is no error at all. --- Quote End --- Ok, so its probably related to not sending enough DCLKs at the end of the configuration sequence. Try sending a few more DCLKS, eg., 8, 16, 32, or 64. --- Quote Start --- When I send the .hex configuration file to the FPGA, should I just send the "valid" data...or send the "valid" data as well as the length information and CRCs? --- Quote End --- I haven't used .hex files. Go and figure out the difference between a .hex file and .rbf. Is the .hex just an Intel .hex file? If so, then convert it to bytes and it should match the .rbf exactly. If the .hex file is missing some 0xFFs at the end, then there is your problem - the hex file is missing the extra DCLKs. The "valid" data and CRCs in the .hex file are related to the ASCII representation of the data in that file, they are not related to FPGA configuration data, so do not send them to the FPGA. --- Quote Start --- And how does the FPGA know the transmission is done and it's time to release the nCONF_DONE? --- Quote End --- The binary data likely has CRCs checks. Since nSTATUS is not going low, the FPGA is happy with the data. --- Quote Start --- Also, there are many different file formats can be used to configure the FPGA, how does the FPGA know which format I am using？ --- Quote End --- Bits are bits. The .hex file vs .rbf file should be merely a human readable format difference, not something the FPGA sees. Cheers, Dave
- Altera_Forum
JTAG can program well and when it's done, nCONF_DONE is high.
- Altera_Forum
Dave, thanks, JTAG can program well and the nSTATUＳ is high, there is no error at all.
The only problem is about the nCONF_DONE.... When I send the .hex configuration file to the FPGA, should I just send the "valid" data...or send the "valid" data as well as the length information and CRCs? And how does the FPGA know the transmission is done and it's time to release the nCONF_DONE? Also, there are many different file formats can be used to configure the FPGA, how does the FPGA know which format I am using？ Hope I can see the answers to such questions in your document soon !!!
