Forum Discussion
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_ForumDave, 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 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--- 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
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 --- 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
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 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
Ok. I used the debug probe to read the flash two different ways.
Probe setup as little endian 0xfe50_0020 f7f7f76a f3f3f3f7 fbfaf3fb f9f9f1fa Probe setup for big endian 0xfe50_0020 6af7f7f7 f7f3f3f3 fbf3fafb faf1f9f9 the same bytes when looking at the .rbf file in image attached. so it looks fine big endian correct? https://www.alteraforum.com/forum/attachment.php?attachmentid=7202 - Altera_Forum--- Quote Start --- Probe setup as little endian 0xfe50_0020 f7f7f76a f3f3f3f7 fbfaf3fb f9f9f1fa Probe setup for big endian 0xfe50_0020 6af7f7f7 f7f3f3f3 fbf3fafb faf1f9f9 --- Quote End --- In both cases the bytes are; 6a f7 f7 f7 f7 f3 f3 f3 ... which matches your .rbf. This at least confirms your bytes in flash appear to be correct. How are you PS programming? Using an SPI controller? Check the bit-ordering with a scope. This document may give you some hints too ... http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf Check the different control signal pulses match their expected timing. Cheers, Dave
- Altera_Forum
i am just using I/O, setting the DATA0 bit then triggering DCLK to latch it. very similar to the source code provided in the Altera application note: AN423: Configuring the MicroBlaster
Passive Serial Software Driver. On my scope the data and clock pulses look good. The clock is latched longer then 7ns as the spec states. I check my NSTATUS line throughout the process and it stays high. In testing I was able to inject errors and see NSTATUS drop low to show an error. Is there a specific way Quartus should be setup to build a PS serial file for loading like this? if email is easier let me know. this is one of the remaining issues we are trying to solve so my client can finalize their next board design. Thanks, Jordan
