Cyclone III + EPCS4 + UART remote upgrade

[Altera_Forum]

Hi ALL, I have a custom logic design in a Cyclone III FPGA (EP3C10). The configuration is stored in a EPCS4 configuration device and I am using AS scheme to configure the FPGA at factory. Also, there's a MCU that talks to the FPGA on an UART port (currently unused). I need to implement field upgrade function so that I can upgrade the FPGA firmware in the EPCS4 configuration device and trigger a re-configuration so the FPGA will run the new firmware.  

 I've been trying to find some documentation or examples on the Internet. I found this example (http://www.grigaitis.eu/?p=514) is similar to what I want to do. Following the example with my very limited understanding of Qsys (I am very new to the Qsys thing), I should have the following: 1). Nios II processor 2). On-chip Memory (for the Nios II processor) 3). Remote Update Controller (Cyclone III) 4). EPCS Flash Controller 5). JTAG UART  After generate from Qsys (see Qsys.jpg), I incorporate this into the FPGA design in Quartus II (see Quartus II.jpg). I then compile the design (see Quartus II Compilation.jpg) and follow my usual routine of convert the programming file into a .jic file and load the EPCS4 with this file.  Then the example is asking me to create the "NIOS software to handle second Image configuration stream and write it to required EPCS address". This is where I get stuck. I understand that NIOS needs its own software to run and its sole functionality is to handle the UART communication when there's a download of new FPGA image and write it to the EPCS4 device and trigger the FPGA to re-configure. So question# 1) where is the NIOS store its own little program? Is it on the same EPCS4 device? If so, is it gonna have conflict with the FPGA firmware that's already on there? Sorry, for asking dumb question, but I am very inexperience with this.  Also if anyone has other more detailed (step-by-step) guide to archive the remote update documentation or examples, please share with me as well.  Thanks a lot!

[Altera_Forum]

The nios software can be stored in different ways: 

- in the same epcs device which contains the fpga configuration bitstream - in a different flash device (i.e. parallel flash) - encapsulated in the fpga configuration bitstream in the form of onchip memory initialization data. The first two options require a proper bootloader, while in the third one you could run nios software directly, since the code is already there where it is supposed to be. Storing nios software in flash adds complexitiy but it is a more flexible option if you plan to update the nios code frequently without need of changing the 'hardware', namely the fpga configuration. On the other hand, if you have a well defined nios application, the third option could be more convenient one.  In general you want to avoid that your system gets stuck because the update process was interrupted, so the typical way to perform remote update is storing on epcs two copies of the fpga configuration (and possibly the nios program). You have a 'base' or 'factory' configuration and an 'application' configuration The base configuration is stored at epcs address 0 and it is never deleted or updated; it loads every time you power up the system, it reads the epcs device at a well known address and if it finds a valid application bitstream it triggers the fpga reconfiguration from that address. If no application is available, the base configuration still allows the minimal functionality required to store the application image into the epcs, for example receiving data from uart.

[Altera_Forum]

I'm unclear as to how you want to perform the "field upgrade". Over a UART? Over JTAG? If you can plug a JTAG cable into your board, then you already have everything you need.

[Altera_Forum]

What kind interface does your device use in the field to talk with the outside world?  

 1). Nios II processor with sufficient memory to run a command processor to accept commands from the outside world 2). Interface to take commands from outside world. 3). Remote Update Controller (Cyclone III) ==> Used to reconfigure the FPGA after the update 4). EPCS Flash Controller ==> This contains a SPI controller you can access directly using a 0x400 base offset and the epcs_commands.h and altera_avalon_spi.h, or via the HAL (altera_avalon_epcs_flash_controller.h)

[Altera_Forum]

After a year, I come back to my problem. So I still trying to get this to work.  

 To make it clear, I have a logic design in FPGA (no soft core etc, purely state machine and logic). Once compiled, we converted it to a .jic file and program the Cyclone III / EPCS4 at factory with JTAG interface. Once the product is shipped, we have no way to upgrade the FPGA in the field. We have an unused UART interface connected from a Freescale processor to the FPGA pins. The freescale is communicating with outside world. So my end goal is that via this UART interface, we can somehow upgrade the EPCS4 and trigger a reconfigure of the FPGA. I understand that it's better to have 2 imagines on the EPCS4 in case the upgraded one is no good, the FPGA can fallback to the factory shipped one.   So question# 1) how can I realize this design? Do I need a Nios II processor?

[Altera_Forum]

With a Nios II processor instantiated in the FPGA you can connect to UART port on one side and you simply have the HAL driver to interface EPCS on the other side. 

The other solution would be using the Freescale processor to drive the EPCS. Both are viable: the first one would consume FPGA resources but it's easy to implement. The second one requires minimal hw resources but you'll have to write the EPCS driver for the Freescale (IIRC Altera doesn't disclose the details to program the EPCS device, so you'll possibly have to find out the commands as well). If I had plenty of spare resources in my FPGA design and enough headroom for future upgrades, I'd definitely choose the first solution. One remark: using a Nios processor would cause your image file to grow because it will also contain the Nios program; make sure your EPCS4 device is able to fit the 2 bigger images.

[Altera_Forum]

--- Quote Start ---  With a Nios II processor instantiated in the FPGA you can connect to UART port on one side and you simply have the HAL driver to interface EPCS on the other side. The other solution would be using the Freescale processor to drive the EPCS. Both are viable: the first one would consume FPGA resources but it's easy to implement. The second one requires minimal hw resources but you'll have to write the EPCS driver for the Freescale (IIRC Altera doesn't disclose the details to program the EPCS device, so you'll possibly have to find out the commands as well). If I had plenty of spare resources in my FPGA design and enough headroom for future upgrades, I'd definitely choose the first solution. One remark: using a Nios processor would cause your image file to grow because it will also contain the Nios program; make sure your EPCS4 device is able to fit the 2 bigger images.  --- Quote End ---    Thanks Cris72. The FPGA design itself is relatively small, utilizing less than 20% of the resources and less than 1% of the memory bits. So I am pursuing the 1st option as you suggested. I found an example at http://www.alterawiki.com/wiki/epcs_based_remote_system_update_(rsu)_example_on_bemicro_sdk talking about remote update EPCS using Nios II. I tried to follow it, but encountered an error when build the project "error: file project_sources/demo_images/factory_hw.flash is absent." As a matter of fact, the whole demo_imagines folder is empty. Any idea???

[Altera_Forum]

I found this sample online: http://www.alterawiki.com/wiki/epcs_based_remote_system_update_(rsu)_example_on_bemicro_sdk 

I tried to follow it. I download the file, extract the files. Then I issue ./top_build_everything_par.sh in the bash shall, but I got error message:"ERROR: File project_source/demo_images/factory_hw.flash is absent." I looked, there's no file in that folder. Any ideas?

[Altera_Forum]

I didn't use the BeMicro example, so I can only try to guess the reason of the problem.  

Usually Quartus generates a FPGA configuration image in the form of a .sof file, while the embedded sw tools build into a .elf file the Nios program image. What you probably need to do is to convert these files in the proper format required by the sample project, using the sof2flash utility:  sof2flash --epcs --input=factory_hw.sof --output=factory_hw.flash