Is CONF_DONE read by the FPGA?

--- Quote Start ---

Once upon a time I think there was an option to get the FPGA to ignore CONF_DONE but it doesn't seem to be there anymore in 12.1SP1.

--- Quote End ---

Its still there.

File->Convert Programming File, Click on the Advanced options. There's a check-button there that says "Disable AS mode CONF_DONE error check".

Though I suspect that applies to AS programming with a JTAG cable, rather than with an EPCS device, since the EPCS device cannot check CONF_DONE ... but then again, perhaps the FPGA does an internal check of CONF_DONE.

Report back on whether it made a difference.

Cheers,

Dave

Hi Dave,

Thanks for the reply.

--- Quote Start ---

perhaps the FPGA does an internal check of CONF_DONE.

--- Quote End ---

This would seem to be the case. I took a similar board (Cyclone III, EPCS64) and removed the pull-up from the CONF_DONE line. The behaviour became the same: downloads all the configuration data from the EPCS64, toggles the nStatus line, and starts over. Repeat. I put the resistor back and it configured fine. So it looks like the CONF_DONE line is bidirectional and the FPGA itself checks the status and restarts configuration if there's no pull-up and the line doesn't go high.

I haven't had any luck with the option you pointed out but I'll persevere with it some more. It's my only hope...

Thanks,

Mark.

Okay, it would appear that the option works as expected. I created a JIC file from the SOF and checked the "Disable AS mode CONF_DONE error check" box. Programmed the EPCS64 with the JIC and the FPGA configured correctly at power up. Hurrah.

Here's where I'm stuck now. I normally create the EPCS image with sof2flash followed by elf2flash with the --after option. The programming file converter will generate lots of useful files, but not a srec flash file. Looking at what sof2flash does with the --verbose flag, it generates a POF from the SOF with quartus_cpf and then generates a RPD from the POF with quartus_cpf. Then the info spewed out by --verbose stops.

What is the step to create a flash SREC file from the RPD?

Thanks,

Mark.

Hi Mark,

--- Quote Start ---

This would seem to be the case. I took a similar board (Cyclone III, EPCS64) and removed the pull-up from the CONF_DONE line. The behaviour became the same: downloads all the configuration data from the EPCS64, toggles the nStatus line, and starts over. Repeat. I put the resistor back and it configured fine. So it looks like the CONF_DONE line is bidirectional and the FPGA itself checks the status and restarts configuration if there's no pull-up and the line doesn't go high.

--- Quote End ---

Ok, nice detective work!

As another confirmation that the FPGA can read CONF_DONE, I was recently looking at the JRunner source, and in that code, via the JTAG port, you can issue the CHECK_STATUS JTAG instruction and read a CONF_DONE signal ... whether its the internal version of CONF_DONE or the state of the CONF_DONE pin, I'm not sure, I'll have to run a similar test to you where I change the external pull-up.

Cheers,

Dave

--- Quote Start ---

What is the step to create a flash SREC file from the RPD?

--- Quote End ---

Isn't that the .hexout option under the convert programming files GUI? I'm not sure what the command-line equivalent is, but perhaps searching on hexout rather than SREC might yield more info.

Cheers,

Dave

--- Quote Start ---

Isn't that the .hexout option under the convert programming files GUI?

--- Quote End ---

That generates an Intel hex format file - not quite the same thing.

I feel like I'm almost there now, though.

1) Create an Intel HEX file from the compressed SOF.

2) Convert that to an SREC with nios2-elf-objcopy.

3) Use elf2flash --after <srec file from step 2> to create an srec file of the software with the correct offset.

4) Convert software srec to hex with nios2-elf-objcopy

5) Stick it all together into a JIC file with Quartus, beign careful to turn on the "Disable AS mode CONF_DONE error check" box which is not persistent and doesn't get saved in the COF file. The first two steps are just to get the software to the correct offset. I use the original SOF in the JIC.

It now configures and the software seems to start. It looks like there's some problem with the software, though, in that it doesn't send anything out the JTAG UART. The software is meant to write to a bunch of LCD screens but instead of writing the expected data writes garbage. If the same elf file from step 3 is downloaded with nios2-download then it operates correctly.

Mark.

--- Quote Start ---

That generates an Intel hex format file - not quite the same thing.

--- Quote End ---

Ah, that's right. I typically deal with binary files directly, and don't bother with the ASCII reformatted styles.

--- Quote Start ---

... beign careful to turn on the "Disable AS mode CONF_DONE error check" box which is not persistent and doesn't get saved in the COF file.

--- Quote End ---

That is annoying ...

--- Quote Start ---

It now configures and the software seems to start. It looks like there's some problem with the software, though, in that it doesn't send anything out the JTAG UART. The software is meant to write to a bunch of LCD screens but instead of writing the expected data writes garbage. If the same elf file from step 3 is downloaded with nios2-download then it operates correctly.

--- Quote End ---

I would connect the debugger and step through the code to see where it dies.

Perhaps there is some initialization phase that gets incorrectly skipped, eg., check the .bss area is cleared, etc.

Cheers,

Dave

--- Quote Start ---

I would connect the debugger and step through the code to see where it dies.

Perhaps there is some initialization phase that gets incorrectly skipped, eg., check the .bss area is cleared, etc.

--- Quote End ---

I think what's happening is that the boot loader from the EPCS block in Qsys doesn't know when to stop and keeps copying the contents of FLASH to RAM. It's all shared memory between my LCD displays and my NIOS code and eventually the boot loader starts copying FLASH contents into the block of memory used for the LCD frame buffer. So to me it looked like my program was doing something since the LCD displays were updating with garbage but it's actually just the boot loader going off the rails.

Now to figure out why the boot loader gets the size wrong...

Mark.

--- Quote Start ---

Now to figure out why the boot loader gets the size wrong...

--- Quote End ---

I've never used the NIOS tools, but they're gcc based, so they should work something like the ones in this doc:

http://www.ovro.caltech.edu/~dwh/ucos/project_ar1803.pdf

I'd recommend starting with the linker scripts. Find out the variable names for the starts and ends of sections, then using the debugger, go find those sections. You can 'seed' the linker script with dummy sections and fill those dummy sections with a fixed value. That'll help confirm that the bootloader is working correctly.

I assume you're using a bootloader written by someone else (Altera perhaps), so there's no telling whether you're the first to use a particular feature, and find a particular bug.

Cheers,

Dave

Hi,

Thanks, Dave, for the replies. I got there in the end by abandoning the JIC method, generating a RPD binary file with CONF_DONE checking off, reversing all the bits in every byte, making an SREC, and concatenating my software to the end. Then it all came right. Maybe the JIC is generated with an extra byte between the firmware and HEX file for the software or something. FYI, the boot loader is the EPCS one provided by Altera. Very simple and the source is provided with the tools.

For those who might be interested, there is of course very little difference between the firmware with CONF_DONE checking enabled (the default behaviour) and with CONF_DONE checking disabled. In my case the differences are:

Address 0x29: CONF_DONE check: 0xDF, no CONF_DONE check: 0xCF

Address 0x45: CONF_DONE check: 0xBF, no CONF_DONE check: 0xFF

Address 0x46: CONF_DONE check: 0x9F, no CONF_DONE check: 0xDF

Address 0x49: CONF_DONE check: 0x81, no CONF_DONE check: 0xA4

Address 0x4A: CONF_DONE check: 0x59, no CONF_DONE check: 0x41

Mark.