NIOS II and Cyclone III Remote Update

[Altera_Forum]

Have spent several days now searching and reading and think I am nearly there... but not quite. I am using the NIOS II core with SOPC builder. I use Quartus II for the FPGA image. This is a project I have inherited which kept the FPGA image in a ECPS64 and the software image in CFI. I have combined the two and keep them in the EPCS64. Works OK. I have been trying to get the remote update controller to work. I have put it into the core via SOPC and can read and write its registers via NIOS. I can also make it do a reconfig but it always seems to use the factory image. Has any one got a working example using the Cyclone III and NIOS II? 

 I use the following to read 2 of the registers... ParamValue = IORD( REMOTE_UPDATE_CYCLONEIII_0_BASE, 0x4); ParamValue = IORD( REMOTE_UPDATE_CYCLONEIII_0_BASE, 0x0);  After power on both registers read 0. After reconfig command, register 0 = 1 and register 4 = 8  Any ideas please? Brain is starting to hurt! 

[Altera_Forum]

Still not sure you got it; please excuse me if I'm wrong, but I'll try to explain better. 

You CAN definitely select a different image for FPGA configuration with remote update core. What you can't do is selecting a Nios boot image independently from FPGA configuration, since Nios bootloader is embedded in the specific configurated logic. Example: In epcs you have a base FPGA configuration at address 0, another one at address 0x20000 and a third one at address 0x40000 and possibly others at higher addresses. Upon power up the default base configuration at address 0 is loaded: this may or may not have a Nios system configurated inside it; if it does, the bootloader should also be implemented and will take care of loading Nios firmware. Let's now assume you need to reconfigure with the image at address 0x40000; you set the remote update address to point there and trigger the reconfiguration. At this point the FPGA is configured from the image stored at 0x40000; but this is only the hardware part: whether a Nios firmware is bootloaded and WHERE it has to be loaded from it's a specific information hardcoded into the newly loaded image. If you want the configuration at 0x40000 to be able to boot different Nios programs upon user request, or even select the Nios boot image position, you must provide a far more complex bootloader which test other system variables (for example input pins coming from dip switches) and proceed according to the user selection; remote update core is not involved in this part.

[Altera_Forum]

I had difficulties to understand but I think I get it, you've the remote update core that enables to select the FPGA image, this FPGA image can includes the Nios firmware position defined by the Nios bootloader code (EPCS_boot_rom.hex) that will load this Nios firmware itself, remote update core can't change this one because it's integrated in EPCS controller core itself, in EPCS you have a base FPGA configuration at address 0 and others address, the default one is 0 if the Nios bootloader isn't changed. So for example, if I have two FPGA Images each included a Nios system, one at address 0 and the other one at address 0x400000, if I select the second FPGA image with the remote update core upon power up the default base configuration at address 0 is loaded, so my second FPGA image is selected but runs Nios firmware in the first FPGA image and not the Nios firmware in my second FPGA image. 

Hope I'm right, really sorry if I take time to understand that...

[Altera_Forum]

Ok. I think you got it. 

Regarding Nios firmware I forgot to mention that the default bootloader will automatically go to address 0; it will hence scan up to the end of the FPGA image and then start loading the Nios firmware, which is supposed to reside just after the FPGA image. When you build a FPGA image that is supposed to be loaded at a non-null epcs address, you need to include a custom bootloader which performs a similar positioning operation from a different address offset. Or simply, like in the example I posted, define a conventional fixed address for firmware position: this somehow wastes some flash memory spaces between fpga and nios image, but makes bootloader much simpler. Moreover you maybe want to be able to update nios firmware while fpga is seldom changed: thus, if you align nios firmware image with one of epcs blocks, you can virtually erase and replace only the nios firmware image.

[Altera_Forum]

Ok, thanks a lot for your help cris72.

[Altera_Forum]

Cris72, when I try to select my first FPGA image at 0 or my second one at 0x400000 with Remote Update core, 

I still have this value 8 for the register 0x4 of the remote update core, IORD(REMOTE_UPDATE_CYCLONEIII_BASE, 0x4). Don't you any idea where can be the problem ?

[Altera_Forum]

I'm not sure, but you probably need to put read_source=01 in order to read the boot register content. 

Try IORD(REMOTE_UPDATE_CYCLONEIII_BASE, 0xC) If this doesn't work either, I believe you have some error in remote update connection to your Nios system.  Please note that Fmax for remote update core on CycloneIII devices is 40MHz which is lower than the common range of system frequency (50 to 100MHz). So you normally need a lower frequency clock and a clock bridge in your Nios system.

[Altera_Forum]

Ok cris72 for Frequency of the remote update core on Cyclone III it was already set under 40 Mhz in the SOPC builder ;  

where do I put read_source=01 and what does it correspond to ? Is it in my Nios C code or somewehere else ? There is something strange that happens when I read register 0xC, at first it's still 0x8 even when I try to reconfigure to address 0x400000,  but when I erase the byte at 0x400000 and do a reconfig then I have the value 0x400000 in my 0xC register ?

[Altera_Forum]

Frequency for remote update core is 25 MHz, at first register 0xC = 3, 0x4 = 0, after reconfig register 0xC = 8 and 0x4 = 8,  

when I erase byte at address 0x400000, register 0xC = 0x400000, 0x4 = 0. In reality to read boot register which register do I  have to read 0xC or 0x4 ?

[Altera_Forum]

read_source isn't it in the VHDL code source ?

[Altera_Forum]

The remote update register addressing is a bit tricky; it maps to 2 ports of remote update megafunction: param and read_source. 

param is mapped to address bits 0-2 , while read_source is mapped to bits 3-4. Then address 0x04 refers to param 100 (boot address) and read_source 00 (current status) Address 0x0C refers again to param 100 (boot address) but read_source 01 (past status, before reconfiguration) Moreover, the boot address format is different between writes and reads: 22bits for writes and 24bits for reads.  The values you read are correct up to the last 4 bits, which instead seem somehow random. Are you sure everything is properly connected?  If your Nios runs at a frequency different from 25MHz you should have a clock crossing bridge between data master and remote update MM slave.  If everything looks ok, try reading the register twice and check if you get the same value. If not, you definitely have a problem with connection or timing.

[Altera_Forum]

Indeed my Nios processor runs at a frequency of 80 MHz cpu_clk, I have a clock bridge with a frequency of 9,1 MHz and a frequency of 25 MHz for 

the remote update MM slave, do I have to change the clock frequency of the remote update MM slave to correspond with the frequency of the clock bridge ? otherwise everything is well connected !

[Altera_Forum]

Apparently I've a problem of CRC error when I try 

to reconfig trig !

[Altera_Forum]

IOWR(RU_BASE_B, 0x20, 0X1) does it work really ?

[Altera_Forum]

OK for read the boot address I've got my first FPGA image now, so this point is Ok !

[Altera_Forum]

--- Quote Start ---  Indeed my Nios processor runs at a frequency of 80 MHz cpu_clk, I have a clock bridge with a frequency of 9,1 MHz and a frequency of 25 MHz for the remote update MM slave, do I have to change the clock frequency of the remote update MM slave to correspond with the frequency of the clock bridge ? otherwise everything is well connected !  --- Quote End ---   The purpose of the clock bridge is to interface two buses running at different clock rates, say clk1 for port s1 and clk2 for port s2. Then all devices on slave port side should have the same clk1 clock; similarly all devices on master port should use clk2.  In your case, what's the point of using the clock bridge if you are still using a mismatched clock frequency after the bridge? The problems you have in reading/writing remote update core can be definitely due to this mismatch. Don't you have any warning from sopc builder?

[Altera_Forum]

Warning: cpu: Custom Instruction components can be edited through the Component Editor. 

Warning: cpu: Disabling the assign CPUID control register value manually will no longer auto-assigns unique control register value. This option will always be turned on with default value set to 0.  That's the warnings I have.

[Altera_Forum]

What you're saying is that my two slaves ls_hdlc and remote_update_cycloneiii should have the same value of clock example ls_hdlc_clk, but the 

master ls_hdlc_clock_bridge, I don't understand what you mean like value of clock ?

[Altera_Forum]

In reality I've the error Nconfig actived, don't if you know how to solve it cris72 ?

[Altera_Forum]

--- Quote Start ---  What you're saying is that my two slaves ls_hdlc and remote_update_cycloneiii should have the same value of clock example ls_hdlc_clk, but the master ls_hdlc_clock_bridge, I don't understand what you mean like value of clock ?  --- Quote End ---   You should use ls_hdlc_clk for remote_update component, too. If you want to use slow_clock connect remote_update to the slow_clock_bridge master port.  What's the problem? This is straightforward!  You already have bridges to separate clock domains. What's the point in connecting remote_update slow_clock to different clock domain???     --- Quote Start ---  In reality I've the error Nconfig actived  --- Quote End ---   nConfig is a FPGA input which is used to reset and trigger a reconfiguration! It's indeed controlled by an external component, then it CAN NOT signal any error.

[Altera_Forum]

Ok, get it cris72 :D

[Altera_Forum]

When I erase my software_app.hex of my app code (second fpga image) I should boot on the software_factory.hex of my factory code (first fpga) by default,  

but instead of it I stay in my second fpga image and nothing runs because I erased voluntarily software_app.hex, do you know how to solve this problem ?