Remote Update with NIOS and EPCS

[Altera_Forum]

Hello, 

 Currenty I'm working on a Cyclone III to try Remote Update work. I've searched for a lot of information but couldn't find specifiek how to work. I'm trying to work with the altremote_update function and to access that block from NIOS with some PIO's defined in SOPC. With this method I can trigger the reconfiguration but now I want some data back from the data_out. But when I try that with an Input PIO to connect from the altremote_update function and read that from NIOS with this code: IORD_ALTERA_AVALON_PIO_DATA(REMOTE_DATA_BASE)  When I try this the application crashed, so I'm wondering what am I doing wrong and is the way that I'm working correct?   Another problem is that I can't read the EPCS, I've defined the controller in SOPC and did all the pins in Quartus. But when I try to access the EPCS with this code fd = alt_flash_open_dev(EPCS_FLASH_CONTROLLER_NAME);  Then fd is empty, so that will tell me that I can't access the EPCS, is that possible because I haven't yet got a licence? (The licence will arrive next week)   Thanks a lot!

[Altera_Forum]

Have you tried using the Remote Update Controller component instead of PIO and altremote_update? 

 I have never tried the PIO approach. Using the Remote Update Controller component, I have not had any problems reading or writing to the controller.  I have also never used the EPCS controller, so I probably can't be of much help there. My best guess would be an incorrect setting in your system library.  In the system where I got Remote Update working, I did not use the EPCS controller as it forces you to have a boot room in block RAM. As all my code was already stored in block RAM, this extra boot ROM was a waste. Instead, I made my own custom SPI component and wrote a few simple C functions to read and write the EPCS memory.

[Altera_Forum]

Thanks for the response! 

 I've tried working with the Remote Update Controller, but I don't get any response from it. I've defined it in SOPC and when I try to reconfigure to an empty space on the flash so it will jump back to the bit-counter. The Remote Update Controller doesn't do anything. In SOPC you can't do anything with settings and this is my code:    IOWR( REMOTE_UPDATE_CONTROLLER_BASE, 0x3, 0 ); usleep(1000); IOWR( REMOTE_UPDATE_CONTROLLER_BASE, 0x4, hw_flash_offset >> 3 ); addr = IORD( REMOTE_UPDATE_CONTROLLER_BASE, 0x4); usleep(1000); // Reconfigure IOWR( REMOTE_UPDATE_CONTROLLER_BASE, 0x20, 0x1 );    And then the application crashes.. when it try's to read the boot adress, if I comment that line nothing happens. I think I'm just missing something small but I just don't know what..

[Altera_Forum]

I think the following line: 

 IOWR( REMOTE_UPDATE_CONTROLLER_BASE, 0x4, hw_flash_offset >> 3)  Should be:  IOWR( REMOTE_UPDATE_CONTROLLER_BASE, 0x4, hw_flash_offset >> 2)  I seem to recall having the same problem as I think one of the Altera app notes uses shift by 3 for some reason. However, when I monitored the SPI lines on a scope I could see the address being read from the memory was off by 1 bit. When I changed it to shift by 2, it started to work.  According to the Cyclone III handbook, the address register is the most significant 22 bits of the 24 bit boot address, so a shift by 2 does make sense.

[Altera_Forum]

Thanks you're right, now it works.. Strange that the documentation says that it had to be 3. 

Now it's waiting for the licence so I can access the EPCS..

[Altera_Forum]

I could be wrong, but I think the difference of shift by 3 versus shift by 2 is because of AP versus AS mode. In AP mode, you need to specific the word (16 bit word) address where as for AS you need to specify the byte address. 

 The example code for AN429 was for AP and it uses shift by 3.  I have only ever tried AS mode, and I found I had to use shift by 2.

[Altera_Forum]

hello, I am using a cyclone III and an EPCS device for configuration. I have just starting investigating remote updates. I can see that there is a megawizard block as well as the remote update controller in sopc. can anyone point me to documentation of the remote update controller in sopc?  

thanks!

[Altera_Forum]

Perhaps you could have a look on a dedicated appnote about remote update : http://www.alse-fr.com/apnotes.php

[Altera_Forum]

thanks, I think I have a handle on setting up the remote_update HW and how to work it in nios.  

 what is not clear to me yet is what type of programming files will I need?  Currently I make builds then covert my .sof file to a .jic file which I use to program my EPCS device.  There are still a few things that are unclear at this point.  1.) how do you get a factory image loaded, using the .jic file and flash it using my jtag like I have been doing?  2.) I will be using a uart to send the remote file to the board. What is the file format that I need for the upgrade file? And will I need to use an EPCS controller to write that file to my EPCS device.   any help with these questions would be deeply appreciated.

[Altera_Forum]

Then if you use an UART to remotly update your EPCS, you could find some tips here : http://www.grigaitis.eu/?p=514 

Bye

[Altera_Forum]

1) You can and a factory (bootloader.sof) *and* an application.sof to your .jic file. You can even add extra .hex files to any base address you want. 

 2) Use .rbf files (bootloader.rbf and/or application.rbf) to send via the UART.

[Altera_Forum]

ok, I was able to flash my epcs using a .jic file and usb blaster.  

 then I was able to send a file from the PC through uart to nios and have nios buffer it in sdram and then write the file to flash at address 0. this is working! :D the file type I used was a .rbf and did byte reversal on all bytes of the file. I can power cycle and boot from the newly updated image written to address 0 of the epcs!!!  The next step is to move the file to another location in flash so that I can have 2 images and use the remote update circuit to do a reconfig to the app image from the factory image.   The question is, what effect does setting "Device and Pin options" > "Configuration mode" > "REMOTE"  have on the output .rbf file?  why do I need to tell quartus that the build is for remote configuration? Should both the factory default and the application configuration files use this option?  I am not sure why it is necessary if I have the remote update HW in my SOPC?