Cyclone III Remote Update registers

Actually I have this as a support request through Altera at the moment..

and well they don't have the file on record..

So comxw someone might be contacting you from Altera shortly to try and see what the file is.

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

So back where we started.

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

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.

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

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.

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_*/