Cyclone III Remote Update registers

[Altera_Forum]

I'm trying to understand the Remote Update on the Cyclone III. Per the code example in Quartus II Handbook Chapter 28 example 28-1: 

 // Perform the reconfiguration by setting bit 0 in the // control/status register IOWR( remote_update_base, 0x20, 0x1 );  Where does the 0x20 come from? The documentation above this example says 00-1F maps to the param and read_source bits of the hardware.  I want to read back the boot address so the factory NIOS II application running after a reconfiguration can find the NIOS II update application which follows the configuration data in the EPCS. It will then copy the update application over the factory application and restart the software (so it is now using the application reconfiguration data loaded on the reconfig).  I am having trouble reading any of the Remote Update registers at runtime, and reading registers in the debugger does not show what I expect (if I write 0x12345 to the boot address I don't see any update in the window that corresponds to this value (<< 2 of course).  I have everything working except detecting a reconfiguration. I want to know if I should be running the update application, not the factory one. I know the common solution is to modify the boot loader, but I don't want to rebuild the SOF and it's really not necessary. On a boot (without reconfiguration because I cannot yet tell that I have reconfigured), if I detect a software image in the 2nd half of EPCS, the copy to over the factory image (in SDRAM) and do a software restart it does work. Now, if I can only detect at runtime that I reconfigured so I can do the copy if reconfigured.  Thank you for any information,  Bill A.

[Altera_Forum]

Well It seems that Altera couldn't find that example code anywhere... 

So back where we started.

[Altera_Forum]

An-548 states 

   --- Quote Start ---  This system has a 50-MHz input clock fed to a Phase-Locked Loop (PLL). The PLL  generates two output clocks—60 MHz and 40 MHz. The 60 MHz clock is used by all  the components in the system, except the remote update controller that requires the 40  MHz clock as its supported frequency  --- Quote End ---    Does that mean it is OK to run the NIOS at 60MHz and the Remote Update Controller at 40MHz?   Does the SOPC builder take care of the fact that the Avalon Bus on the NIOS is running at 60MHz and presumably on the Remote Update Controller at 40MHz?  Or do I have to run my NIOS processor at 40Mhz as well?  I currently have my NIOS system clock at 100MHz and was using the same clock as input to the remote update core. I have been having "issues" with this and would like to reduce the clock tp 40MHz to be safe

[Altera_Forum]

Yes, when you do that SOPC will warn you that you need to insert a "clock domain crossing FIFO" between the avalon bus and the RSU. 

This "clock crossing" component is part of the standard SOPC library. SOPC will also advise you on how big the FIFOs need to be in order to avoid overflows.

[Altera_Forum]

Many thanks for the quick response. I'll give it a try

[Altera_Forum]

I have a NIOS running at 60MHz and the remote update core and epcs flash controller running at 40MHz. SOPC builder takes care of crossing clock domains. I don't remember anything about it inserting a FIFO, if it did it doesn't show up in SOPC builder.

[Altera_Forum]

IIRC SOPC builder will automatically add some clock domain crossing logic when you connect a master and a slave that use different clocks. But if you want something with a better performance, or adjust some parameters on the clock crossing logic, then you need to add yourself the clock domain crossing bridge.

[Altera_Forum]

did anyone ever get a definitive register map for the remote update controller sopc block? 

 I have the remote update working, and now need to write the logic so that the board can tell if it is in factory mode because it failed to reconfig to an app image or because of a power cycle to the board.   anyone know which register gives us this information?:confused:  Looks like register 15 might hold the answers, if only I knew what the bit fields of this register meant.  Based on trial and error I will assume that in factory mode,  reg15 = 0x0 = power cycled board reg15 = 0x8 = failed to reconfig to app image, app image is corrupt. reg15 = 0x1 = failed to reconfig because reconfig was called from app code. reg15 = 0x10 = happens when I configure from the .SOF file via JTAG  Does this look correct?  I would like my code to load factory from power cycle and then do a reconfig. But if it fails and comes back to facotory, I need to know that so I don't have a scenario where I keep looping forever trying to reconfig.  after power cycle  remote_update_controller_p[0] 0x0  remote_update_controller_p[1] 0x0  remote_update_controller_p[2] 0x0  remote_update_controller_p[3] 0x0  remote_update_controller_p[4] 0x0  remote_update_controller_p[5] 0x0  remote_update_controller_p[6] 0x0  remote_update_controller_p[7] 0x0  remote_update_controller_p[8] 0x0  remote_update_controller_p[9] 0x0  remote_update_controller_p[10] 0x3  remote_update_controller_p[11] 0x0  remote_update_controller_p[12] 0x3  remote_update_controller_p[13] 0x0  remote_update_controller_p[14] 0x0  remote_update_controller_p[15] 0x0  remote_update_controller_p[16] 0x0  remote_update_controller_p[17] 0x0  remote_update_controller_p[18] 0x0  remote_update_controller_p[19] 0x0  remote_update_controller_p[20] 0x3  remote_update_controller_p[21] 0x0  remote_update_controller_p[22] 0x0  remote_update_controller_p[23] 0x0  remote_update_controller_p[24] 0x0  remote_update_controller_p[25] 0x1  remote_update_controller_p[26] 0x0  remote_update_controller_p[27] 0x1  remote_update_controller_p[28] 0x0  remote_update_controller_p[29] 0x0  remote_update_controller_p[30] 0x1  remote_update_controller_p[31] 0x0  remote_update_controller_p[32] 0x0   after failed reconfig from factory image using an intentionally corrupted application image.  remote_update_controller_p[0] 0x0  remote_update_controller_p[1] 0x0  remote_update_controller_p[2] 0x0  remote_update_controller_p[3] 0x0  remote_update_controller_p[4] 0x0  remote_update_controller_p[5] 0x0  remote_update_controller_p[6] 0x0  remote_update_controller_p[7] 0x0  remote_update_controller_p[8] 0x0  remote_update_controller_p[9] 0x0  remote_update_controller_p[10] 0x1400000  remote_update_controller_p[11] 0x1  remote_update_controller_p[12] 0x400000  remote_update_controller_p[13] 0x0  remote_update_controller_p[14] 0x0  remote_update_controller_p[15] 0x8  remote_update_controller_p[16] 0x0  remote_update_controller_p[17] 0x0  remote_update_controller_p[18] 0x0  remote_update_controller_p[19] 0x0  remote_update_controller_p[20] 0x3  remote_update_controller_p[21] 0x0  remote_update_controller_p[22] 0x0  remote_update_controller_p[23] 0x0  remote_update_controller_p[24] 0x0  remote_update_controller_p[25] 0x1  remote_update_controller_p[26] 0x0  remote_update_controller_p[27] 0x1  remote_update_controller_p[28] 0x0  remote_update_controller_p[29] 0x0  remote_update_controller_p[30] 0x1  remote_update_controller_p[31] 0x0  remote_update_controller_p[32] 0x0    after successful reconfig to app image from factory image  remote_update_controller_p[0] 0x1  remote_update_controller_p[1] 0x0  remote_update_controller_p[2] 0x0  remote_update_controller_p[3] 0x0  remote_update_controller_p[4] 0x8  remote_update_controller_p[5] 0x0  remote_update_controller_p[6] 0x0  remote_update_controller_p[7] 0x0  remote_update_controller_p[8] 0x1  remote_update_controller_p[9] 0x0  remote_update_controller_p[10] 0x8  remote_update_controller_p[11] 0x0  remote_update_controller_p[12] 0x8  remote_update_controller_p[13] 0x0  remote_update_controller_p[14] 0x0  remote_update_controller_p[15] 0x10  remote_update_controller_p[16] 0x1  remote_update_controller_p[17] 0x0  remote_update_controller_p[18] 0x0  remote_update_controller_p[19] 0x0  remote_update_controller_p[20] 0x400000  remote_update_controller_p[21] 0x0  remote_update_controller_p[22] 0x0  remote_update_controller_p[23] 0x10  remote_update_controller_p[24] 0x0  remote_update_controller_p[25] 0x0  remote_update_controller_p[26] 0x0  remote_update_controller_p[27] 0x0  remote_update_controller_p[28] 0x40400  remote_update_controller_p[29] 0x0  remote_update_controller_p[30] 0x0  remote_update_controller_p[31] 0x0  remote_update_controller_p[32] 0x0  after triggering a reconfig from the app image, it fails and goes back to factory image as this is not allowed. remote_update_controller_p[0] 0x0  remote_update_controller_p[1] 0x0  remote_update_controller_p[2] 0x0  remote_update_controller_p[3] 0x0  remote_update_controller_p[4] 0x0  remote_update_controller_p[5] 0x0  remote_update_controller_p[6] 0x0  remote_update_controller_p[7] 0x0  remote_update_controller_p[8] 0x0  remote_update_controller_p[9] 0x0  remote_update_controller_p[10] 0x5400000  remote_update_controller_p[11] 0x0  remote_update_controller_p[12] 0x400000  remote_update_controller_p[13] 0x0  remote_update_controller_p[14] 0x0  remote_update_controller_p[15] 0x1  remote_update_controller_p[16] 0x0  remote_update_controller_p[17] 0x0  remote_update_controller_p[18] 0x0  remote_update_controller_p[19] 0x0  remote_update_controller_p[20] 0x3  remote_update_controller_p[21] 0x0  remote_update_controller_p[22] 0x0  remote_update_controller_p[23] 0x0  remote_update_controller_p[24] 0x0  remote_update_controller_p[25] 0x1  remote_update_controller_p[26] 0x0  remote_update_controller_p[27] 0x1  remote_update_controller_p[28] 0x0  remote_update_controller_p[29] 0x0  remote_update_controller_p[30] 0x1  remote_update_controller_p[31] 0x0  remote_update_controller_p[32] 0x0

[Altera_Forum]

Hi - I have a quick question on this topic. The UG states: 

 "All parameters can be written in Factory configuration mode only."    Have you guys that have used RSU found this to be true?    I ask becuase what I am seeing is that I can upgrade from factory mode to Application mode with no problem. However, if I try to re-upgrade from app mode to app mode it fails and goes back to factory... where I can then re-re-upgrade without any trouble.   Thanks Kevin.   

[Altera_Forum]

yes, you can only reconfig to app mode from factory mode.  

 Here is a function call and header defines to go with it. I had this working a while back and haven't looked at it lately. I was calling this function in my startup routine. And have another function somewhere that will overwrite the contents of the app image while running on the old app image.   Comments were for my own understanding.  Use it at your own risk.  C file:  # include "remote_update.h"  volatile alt_u32 * const remote_update_controller_p =   (volatile alt_u32 *)( REMOTE_UPDATE_CYCLONEIII_0_BASE);   void remote_update_reconfig() { static alt_u32 remote_update_mode; static alt_u32 remote_update_state;   remote_update_mode = remote_update_controller_p[REMOTE_UPDATE_CURRENT_MODE];    if(remote_update_mode == REMOTE_UPDATE_FACTORY_MODE)  {  remote_update_state = remote_update_controller_p[REMOTE_UPDATE_RECONFIG_REASON];    if((remote_update_state == REMOTE_UPDATE_RECONFIG_REASON_POWER_CYCLED)||   (remote_update_state == REMOTE_UPDATE_RECONFIG_REASON_JTAG_SOF_PROG)||   (remote_update_state == REMOTE_UPDATE_RECONFIG_REASON_RECONFIG_FROM_APP))  {  /* load the base address of the application image into the   remote update controller use a 32 bit boundry */  remote_update_controller_p[REMOTE_UPDATE_APP_IMAGE_BOOT_ADDR] =   (REMOTE_UPDATE_APP_IMAGE_BASE_ADDRESS >> 2);    /* disable the remote update controller watchdog timer */  remote_update_controller_p[REMOTE_UPDATE_WATCHDOG_ENABLE] = 0x0;    /* trigger the reconfiguration to the application image */  remote_update_controller_p[REMOTE_UPDATE_TRIGGER_RECONFIG] = 0x1;  }  else if(remote_update_state == REMOTE_UPDATE_RECONFIG_REASON_APP_CORRUPT)  {    }   }  else /* must be in application mode and don't need to do anything. */  {    } }    H file:  # ifndef REMOTE_UPDATE_H_# define REMOTE_UPDATE_H_  /**************************************************************  * Includes  * ************************************************************/  /* register definitions of the remote update controller SOPC   block. These are not defined anywhere so take it with   a grain of salt. */ typedef enum  {  REMOTE_UPDATE_CURRENT_MODE=0,  REMOTE_UPDATE_EARLY_CONF_DONE,  REMOTE_UPDATE_WATCHDOG_TIMEOUT_VAL,  REMOTE_UPDATE_WATCHDOG_ENABLE,  REMOTE_UPDATE_APP_IMAGE_BOOT_ADDR,  REMOTE_UPDATE_RECONFIG_REASON=15,  REMOTE_UPDATE_TRIGGER_RECONFIG=32,  }remote_update_enum_t;  /* the image loaded in the FPGA can either be a factory image loaded  from page 0 offset 0 of the configuration device or it can  be in application mode loaded from the base address of another   page in the configuration device. */ # define REMOTE_UPDATE_FACTORY_MODE 0# define REMOTE_UPDATE_APPLICATION_MODE 1  /* this is not exactly clear what the different states mean. From what I can gatherregister 15 gives the reason that a reconfig is in the state that it is this is the best meanings of reg15 I could gather from trial and error these are only valid in facotry mode */# define REMOTE_UPDATE_RECONFIG_REASON_POWER_CYCLED 0# define REMOTE_UPDATE_RECONFIG_REASON_APP_CORRUPT 0x8# define REMOTE_UPDATE_RECONFIG_REASON_RECONFIG_FROM_APP 0x1# define REMOTE_UPDATE_RECONFIG_REASON_JTAG_SOF_PROG 0x10  /* this is the address in the EPCS device that we want to store the  application image at. This address has to be the base address  of a page in flash. Since we use EPCS64, I will put this at the   64th page. There are 128 pages of 65536 bytes each. So the  address is 64*64436 = 0x400000. This address needs to be   shifted right 2 bits when loading it to address 0x4 of the   remote update controller. The remote update controller uses a  32 bit boundry address for whatever reason. */# define REMOTE_UPDATE_APP_IMAGE_BASE_ADDRESS 0x400000  /* function prototypes */ void remote_update_reconfig(); # endif /*REMOTE_UPDATE_H_*/

[Altera_Forum]

Thanks Spaugh! I appreciate it. 

Kevin.

[Altera_Forum]

I have written state machines for factory and application images -cyclone3-AS mode-EPCS16. 

Do I need ALTASMI mega function to connect serial device(I2C)? I read that there is no need of ALTASMI.But,how the data transfer takes place between I2C and EPCS?  How do I build SOPC?Greatly appreciate if anyone can guide me!

[Altera_Forum]

test 1 .

[Altera_Forum]

brunda: 

You will need to add: - a NIOS to controll the transfers. - a I2C<->avalon interface - e EPCS <-> avalon interface.  And write the C code for the NIOS.

[Altera_Forum]

Thanks for your reply! 

  I am using EPCS controller built using SOPC builder(Q9.0), FPGA device is Cyclone III and configuration device is EPCS16. I am using external processor to communicate with EPCS16 via Avalon Master, SOPC Fabric and EPCS controller (NIOS is NOT used).  I have user logic state machines written for factory and application image configurations. I have simulated/verified Data transfer from my remote update logic to ASMI megafunction & EPCSmemory model u.  i have one question: I have included remote update controller & epcs in the sopc builder while generating the system. do i have to include asmi in the sopc builder while generating the system?  Greatly appreciate your time!

[Altera_Forum]

No, all you need is the EPCS core in the SOPC builder.

[Altera_Forum]

Thanks very much for your reply!

[Altera_Forum]

There are EPCS ports avalable in the sopc file generated.Do I have to manually connect these to ASMI? 

 I have data_out signals from remote system upgrade mega function and ASMI megafunction available.Where do they connect to?

[Altera_Forum]

I am not 100% sure that I understand your question. But if you are asking if you need to manual pin map the remote update and epcs flash controller cores to your pins off of the fpga to the serial flash device, the answer is no.  

 Those pins are on dedicated pins. The tools know this and you don't need to worry about it.  The exception is when you use an EPCS controller on a flash that is not connected to the 4 dedicated pins. For this, you can not use the remote update block. In this case, the AS device would be used for storage and not configuration.   There is even an option in EPCS controller for something like "use dedicated interface"

[Altera_Forum]

In SOPC builder,now,I have Remote System Upgrade(RSU) and EPCS. 

Both connected to NIOS. But,how do I connect RSU and EPCS in SOPC builder?  When I use the RSU megafunction-cycloneIII ,it doesn't have ASMI ports to connect to ASMI. So,how does rsu communicate with epcs (to load factory configuration from epcs)?  I am using EPCS controller built using SOPC builder (Q10.0), FPGA device is Cyclone III and configuration device is EPCS16.  I have user logic state machines written for factory and application image configurations.And,an image update logic to load new image through ASMI. 

[Altera_Forum]

>But,how do I connect RSU and EPCS in SOPC builder? 

 You don't. RSU is an add-on that is more or less independent. When the system fires up, RSU loads the factory configuration and factory application (your NIOS II code). When your factory app decides there is a configuration in the update area of your EPCS (which you have to define and keep fixed forever), it uses RSU to load the update configuration using its offset in EPCS. Without a custom bootloader, it now loads the *factory application*! Which has to decide (using RSU) that the update config is loaded and then has to (somehow) copy and restart the update app.  IMO RSU should have never been released without a transparent way to use it (or not use it) and to be able to run factory or update configurations *and* application without user intervention (besides triggering an RSU update load).  Many of us have complained about this. Some have posted bootloader changes so that an update trigger will load the update application directly. But since you can't change the bootloader without a SOPC change, I didn't have this option since the hardware was done and proven and we didn't want to make changes in SOPC. I did a RAM copy in my factory app which was good enough. The double load is unnoticeable.  Bill

[Altera_Forum]

Thanks very much for such a detailed answer.This information greatly helps!