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_ForumWith the modifications, MSEL0 - pulled up to VCCA, MSEL1 & MSEL2 pulled down. The documentation I have says MSEL 0 to VCC and mSEL1 to GND. doesn't mention MSEL2.
- Altera_Forum--- Quote Start --- Regardless of that fact, there should be no reason you cannot PS program the part. Check your MSEL settings, eg., check any logic high levels are pulled up to the correct voltage (I think its VCCA). --- Quote End --- I think I may have solved your problem ... you're not going to believe this (or that I remembered seeing this line of code) ... Download the Altera JRunner software, unzip it, open jrunner.c and you'll find this at line 878
Subtle, eh! Cheers, Dave/*Ignore first 44 bytes in the rbf file for Cyclone device*/ - Altera_Forum--- Quote Start --- The board currently is being used by the team with the EPCS4 prom loading the FPGA at startup. --- Quote End --- Ok, that is good to know. --- Quote Start --- My board has been modified to move to loading it with the MPC8309. So we have been able to program it, but to reduce board cost we are moving the the micro loading it and removing the EPCS4. I am seeing if we still have JTAG access to try this method. --- Quote End --- You could also replace the EPCS4 with a lower-cost part. These parts are rebranded Numonyx (Micron) devices. Spansion devices also work. Regardless of that fact, there should be no reason you cannot PS program the part. Check your MSEL settings, eg., check any logic high levels are pulled up to the correct voltage (I think its VCCA). Cheers, Dave
- Altera_Forum
The board currently is being used by the team with the EPCS4 prom loading the FPGA at startup. My board has been modified to move to loading it with the MPC8309. So we have been able to program it, but to reduce board cost we are moving the the micro loading it and removing the EPCS4. I am seeing if we still have JTAG access to try this method.
- Altera_Forum--- Quote Start --- Is there a specific way Quartus should be setup to build a PS serial file for loading like this? --- Quote End --- I don't think so. The doc I linked to has the methods I used to generate the images I needed in Appendix A. There was no special step required. Cheers, Dave
- Altera_Forum
Do you have JTAG connected on the board? If so, try configuring the FPGA with JTAG to confirm it is possible.
This will eliminate an issue with say nCE not being asserted low, or the MSEL pins being incorrect. Cheers, Dave - Altera_Forum
I have even tried padding the end of the transmission with extra clock cycles 8,16,32,64... and still never see CONF_DONE go high.
I did look at this document yesterday... All of my timing looks within spec on the scope output. I just never get CONF_DONE... - 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 - 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
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
