Stratix IV 530 Dev. PCB factory_recovery mismatch

1) Yes, I can program my custom HW using JTAG

2) Now, this is where it gets interesting, the restore.sh programs 2 factory restore files, previously created, restore_0 and restore_1. The two are different, one is HW the other is SW and a collection of other bits an pieces. You can't just program them anywhere you wish interchangeably. restore_0 has to go at base 0x0800_0000 (offset=0x20000) and restore_1 has to go at 0x0A00_0000. This is because restore_0 has the NIOS II which needs to boot SW from a specific location.

I can individually program restore_0 and restore_1 to the expected bases (0x0800_0000 and 0x0A00_0000) correctly but if I try to program the USER HW at any base (0x0800_0000 or 0x0A00_0000) with any offset, it does not configure the FPGA. Could it be that I am missing something in creating the user.sof ? I figured that if I can download it with JTAG and it works then it is good to use for programming into FLASH, no?

Thanks,

S.

--- Quote Start ---

1) Yes, I can program my custom HW using JTAG

--- Quote End ---

Great. That eliminates one potential issue :)

--- Quote Start ---

2) Now, this is where it gets interesting, the restore.sh programs 2 factory restore files, previously created, restore_0 and restore_1. The two are different, one is HW the other is SW and a collection of other bits an pieces. You can't just program them anywhere you wish interchangeably. restore_0 has to go at base 0x0800_0000 (offset=0x20000) and restore_1 has to go at 0x0A00_0000. This is because restore_0 has the NIOS II which needs to boot SW from a specific location.

I can individually program restore_0 and restore_1 to the expected bases (0x0800_0000 and 0x0A00_0000) correctly but if I try to program the USER HW at any base (0x0800_0000 or 0x0A00_0000) with any offset, it does not configure the FPGA. Could it be that I am missing something in creating the user.sof ? I figured that if I can download it with JTAG and it works then it is good to use for programming into FLASH, no?

--- Quote End ---

It won't be the .sof that's missing something, it'll be in the conversion from .sof to SREC (.flash).

Look at the Flash memory map in the user guide (Appendix A):

http://www.altera.com/literature/ug/ug_sivgx_fpga_dev_kit.pdf

Add 800_0000h to all these addresses to get the flash memory map as viewed by the NIOS II processor (since it maps the flash to this address).

Now look at the offsets you are using when creating the .flash files. They should correspond to the offset to the factory hardware image, user hardware image, or software images respectively.

The fact that you are using both 800_0000h and A00_0000h implies that your board has the dual-die flash - is that correct? (Mine does).

There is a --dual-die option to one of the programs that creates the flash images. I suspect this is required to correctly issue flash programming sequences or sector erase sequences, since the dual-die version has to be treated as two separate flash devices.

If these comments don't result in an "Ah-ha!" moment for you, let me know, and I'll go back and look at how to do it on my boards.

Cheers,

Dave

Sorry but the saga continues. Yes, this looks like a dual-die. I tried it with and without the --dual-die and no help. I tried:

sof2flash --input=yourfile_hw.sof --output=yourfile_hw.flash --offset=0xC20000 followed by:

nios2-flash-programmer --base=0x08000000 yourfile_hw.flash and I get the message:

"the input is too large to fit (device size = 0x2000000)"

---

I also tried:

sof2flash --input=<yourfile>_hw.sof --output=<yourfile>_hw.flash --offset=0x00C20000 --pfl --optionbit=0x00018000 --programmingmode=PS (with/without --dual-die)

and I get the same message.

S.

I'll try to figure out how to get it to work on my 230K kit this afternoon and then post an update :)

Cheers,

Dave

FYI: I can confirm that I get the same "input file is too large error" for Quartus v11.1sp1 and v12.1. Which version are you using?

If you try and verify the image in flash, the programmer crashes (Quartus 12.1 generates an Abort under Windows 7). I don't find that particularly encouraging :(

I'll continue looking at the Stratix IV GX kit tomorrow, but tonight I'll have a play with a Cyclone IV GX Starter Kit - I'm pretty sure I've used the nios2-flash-programmer successfully with that kit.

Cheers,

Dave

Because this is an older board (2009) it is has a dual-die CFI so one of the user guides suggests programming at base 0x0A00_0000. Tried programming with:

1)offset 0xC20000, I get a message that it is too large to fit,

2)offset 0x0, it programs but does not boot.

Tried every permutation of offset and base address. There seems to be a disconnect between the instructions and the CPLD (MAX2).

I am running out of options. I don't know what CFI memory map the CPLD is configured with, the user guide has changed several time over the years and so has the memory map and programming commands. The only thing that works is to run ./restore.sh with the factory .flash files. I hope Dave has the answer for me.

Thanks,

S.

As I commented above, I confirmed that nios2-flash-programmer would fail with the same error message for the 230K board. I systematically went through the sequence of tests in the attached .txt file (it was too large post inline), and wouldn't you know it, it works fine now!

I have a second 230K board that I will try this on tomorrow. I wonder if the issue was not in the programmer, but in the NIOS processor. In the systematic tests, I configured the board with an .sof from the v11.1 zip - perhaps that design corrected the error that causes the programmer to fail ...

My suggestion to you:

1) Configure your board with the factory_recovery/s4gx530_fpga_bup.sof

2) Then in a NIOS II IDE shell, change to the factory_recovery folder, and issue the command

nios2-flash-programmer --base 0x8000000 --debug --dualdie restore_s4gx530_fpga_bup.flash

and let me know if that works. Otherwise try the systematic steps in the .txt file and see where you differ.

Cheers,

Dave

Thanks Dave, very useful info. I'm off for two weeks but when I get back I'm sure to follow you advice!

Cheers,

S.

I just re-flashed the image on my second 230K board. Without the --dualdie option I would get the "input file to big" error, but the flash was updated fine using --dualdie.

Try the sequence above and it should work for you. If it does not, program the MAX II with its factory recovery image, then the FPGA with the BUP .sof, and then try again.

Chat with you in two weeks.

Cheers,

Dave

I just came across this "list of known issues" with the Stratix IV kit:

http://www.altera.com/support/kdb/solutions/rd06242009_293.html

I suspect the "BUP loading user software image" section describes the issue you were seeing.

Cheers,

Dave