Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

Cyclone III Remote Update registers

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.

63 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    >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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

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