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]

Hmm... 

 You are correct, my table is wrong. MSM mode should be "factory" for that register.  Here is what I get when I dump the registers in application mode (you can see register 0x0 is '1'). For register 0xC I am getting a value of 0x8, which doesn't make sense. It must only be valid for factory mode.  ReadData[0] 0x1  ReadData[1] 0x0  ReadData[2] 0x0  ReadData[3] 0x0  ReadData[4] 0x8  ReadData[5] 0x0  ReadData[6] 0x0  ReadData[7] 0x0  ReadData[8] 0x1  ReadData[9] 0x0  ReadData[10] 0x8  ReadData[11] 0x0  readdata[12] 0x8  ReadData[13] 0x0  ReadData[14] 0x0  ReadData[15] 0x10  ReadData[16] 0x1  ReadData[17] 0x0  ReadData[18] 0x0  ReadData[19] 0x0  ReadData[20] 0x80000  ReadData[21] 0x0  ReadData[22] 0x0  ReadData[23] 0x10  ReadData[24] 0x0  ReadData[25] 0x0  ReadData[26] 0x0  ReadData[27] 0x0  ReadData[28] 0x40080  ReadData[29] 0x0  ReadData[30] 0x0  ReadData[31] 0x0

[Altera_Forum]

--- Quote Start ---  And to be painfully clear - you're using IORD and IOWR with these register numbers as arguments to these macros?  --- Quote End ---    I like clarity. Yes, I use IORD and IOWR. Code to follow (you can laugh at my C code all you want, I am a VHDL guy who dabbles in embedded software when needed :) ).  for (i=0;i<32;i++) {  ReadData[i] = IORD( REMOTE_UPDATE_BASE, i); }

[Altera_Forum]

--- Quote Start ---  Hmm...  You are correct, my table is wrong. MSM mode should be "factory" for that register.  Here is what I get when I dump the registers in application mode (you can see register 0x0 is '1'). For register 0xC I am getting a value of 0x8, which doesn't make sense. It must only be valid for factory mode.  ReadData[0] 0x1  ReadData[1] 0x0  ReadData[2] 0x0  ReadData[3] 0x0  ReadData[4] 0x8  ReadData[5] 0x0  ReadData[6] 0x0  ReadData[7] 0x0  ReadData[8] 0x1  ReadData[9] 0x0  ReadData[10] 0x8  ReadData[11] 0x0  readdata[12] 0x8  ReadData[13] 0x0  ReadData[14] 0x0  ReadData[15] 0x10  ReadData[16] 0x1  ReadData[17] 0x0  ReadData[18] 0x0  ReadData[19] 0x0  ReadData[20] 0x80000  ReadData[21] 0x0  ReadData[22] 0x0  ReadData[23] 0x10  ReadData[24] 0x0  ReadData[25] 0x0  ReadData[26] 0x0  ReadData[27] 0x0  ReadData[28] 0x40080  ReadData[29] 0x0  ReadData[30] 0x0  ReadData[31] 0x0  --- Quote End ---    Register 20 (0x14) is intriguing. Is this your boot address (or something based on it)? If there's something that works and is predictable and repeatable, I don't care where it's documented or not documented. :)  Bill A.

[Altera_Forum]

Also notice register 0xF in this register dump. You can see it has a value of 0x10, which indicates "nconfig_source: external configuration reset "nConfig" assertion". I am taking this to mean that the remote update controller has not entered factory mode due to an error. I think any other value in this register indicated that an error occurred (if still in factory mode). 

   --- Quote Start ---   ReadData[0] 0x1  ReadData[1] 0x0  ReadData[2] 0x0  ReadData[3] 0x0  ReadData[4] 0x8  ReadData[5] 0x0  ReadData[6] 0x0  ReadData[7] 0x0  ReadData[8] 0x1  ReadData[9] 0x0  ReadData[10] 0x8  ReadData[11] 0x0  ReadData[12] 0x8  ReadData[13] 0x0  ReadData[14] 0x0  readdata[15] 0x10  ReadData[16] 0x1  ReadData[17] 0x0  ReadData[18] 0x0  ReadData[19] 0x0  ReadData[20] 0x80000  ReadData[21] 0x0  ReadData[22] 0x0  ReadData[23] 0x10  ReadData[24] 0x0  ReadData[25] 0x0  ReadData[26] 0x0  ReadData[27] 0x0  ReadData[28] 0x40080  ReadData[29] 0x0  ReadData[30] 0x0  ReadData[31] 0x0  --- Quote End ---  

[Altera_Forum]

--- Quote Start ---  Register 20 (0x14) is intriguing. Is this your boot address (or something based on it)? If there's something that works and is predictable and repeatable, I don't care where it's documented or not documented.  --- Quote End ---    Yeah, isn't that interesting. If you get to the point of being able to read these registers I would suggest doing as I did and dumping them for all different scenarios to find out what works.   Here is another dump that shows the state after a failed application reconfig. So the mode is factory, the trigger condition (Reg 0xF) is nStatus asserted, yet it still shows the boot address as "application".  ReadData[0] 0x0  ReadData[1] 0x0  ReadData[2] 0x0  ReadData[3] 0x0  ReadData[4] 0x0  ReadData[5] 0x0  ReadData[6] 0x0  ReadData[7] 0x0  ReadData[8] 0x0  ReadData[9] 0x0  ReadData[10] 0x11080000  ReadData[11] 0x0  ReadData[12] 0x80000  ReadData[13] 0x0  ReadData[14] 0x0  ReadData[15] 0x4  ReadData[16] 0x1  ReadData[17] 0x0  ReadData[18] 0x0  ReadData[19] 0x0  ReadData[20] 0x80000  ReadData[21] 0x0  ReadData[22] 0x0  ReadData[23] 0x10  ReadData[24] 0x0  ReadData[25] 0x1  ReadData[26] 0x0  ReadData[27] 0x1  ReadData[28] 0x0  ReadData[29] 0x0  ReadData[30] 0x1  ReadData[31] 0x0

[Altera_Forum]

--- Quote Start ---  I like clarity. Yes, I use IORD and IOWR. Code to follow (you can laugh at my C code all you want, I am a VHDL guy who dabbles in embedded software when needed :) ).  for (i=0;i<32;i++) {  ReadData[i] = IORD( REMOTE_UPDATE_BASE, i); }  --- Quote End ---   LOL - nothing to laugh at here as far as the code goes. It's fine C code that works and is clear what it does. If that's how all your code is you've graduated from dabble to something more advanced (and not advanced dabbler :)). I'm a sw guy with some hw background but none on VHDL/Verilog (but I can read the latter enough to figure out how a port gets it's address - but with human written Verilog, not computer generated remote update Verilog). Your background will allow you to figure this out and get it working. I had to use the docs to the best of my ability. I'm pretty sure I have the fMax limitation - I wonder why it took so long to document it anyway.  Bill A.

[Altera_Forum]

--- Quote Start ---  Yeah, isn't that interesting. If you get to the point of being able to read these registers I would suggest doing as I did and dumping them for all different scenarios to find out what works.   Here is another dump that shows the state after a failed application reconfig. So the mode is factory, the trigger condition (Reg 0xF) is nStatus asserted, yet it still shows the boot address as "application".   --- Quote End ---    It might be right - you did try to reconfig and it failed, but it did load the failed reconfig data from the application address. To me this would be correct. Pass or fail that was the reconfig address.

[Altera_Forum]

--- Quote Start ---  I'm pretty sure I have the fMax limitation - I wonder why it took so long to document it anyway.  --- Quote End ---    Could you figure this out with some quick timing analysis? Timequest (or classic timing analyzer depending on which you use) should be able to tell you if it can't run that fast.   The remote update controller is in there (I thought it might not be visible since it is hard logic). I just checked mine.

[Altera_Forum]

--- Quote Start ---  Could you figure this out with some quick timing analysis? Timequest (or classic timing analyzer depending on which you use) should be able to tell you if it can't run that fast.   --- Quote End ---   Well, the "you" is the hardware guy and he can't be derailed from his current project. He would have to do this I think - I use the demo license just for experimenting in SOPC Builder - and I can't get a POF that way which I need to build a reconfigurable image. I have code to turn on an LED when I see register 0 be non-0 and it never lights. That's proof by a negative, but with remote update reconfiguring, I know the hardware is there and just not reading back.  Bill A.

[Altera_Forum]

Do you have an EPCS Controller in the SOPC system? If so could you just try to write/read the EPCS device to see if it is successful (with the debugger)?  

 I did this all day yesterday. I would either write canned data or my remote update data to flash and then use the USB Blaster along with the "examine" feature of the Quartus programmer to read it back.   One interesting thing I found while doing this. If I write to offset 0x08000 in flash, it ACTUALLY writes to offset 0x0800A7. I think this is because of the header in the .pof file (the size matches up).   It doesn't really matter as long as the EPCS controller takes care of this offset on both writes and reads, but it did make it very confusing when I first started analyzing the flash data and trying to compare my written file to what was read out.

[Altera_Forum]

I got the remote update working. I would tell you how I did it but I am too busy dancing on my desk and running around the office giving high fives. :D 

 Really though, here is what I did...  First things first, I am using the .rbf (raw binary file) as my remote update source. I load the file in over Ethernet (no TCP/IP stack), store it in external SDRAM, then copy to the serial flash using the NIOS II and EPCS Controller. One very important point is that the bits in each byte need to be reversed, as the flash expects the LSb first.  For the remote update I read address 0x0 first. ‘0’ indicates it booted from the factory address and ‘1’ the application address. I set a flag in an unused sector of flash when I receive a firmware update (I probably don’t need to do this since I will most likely always be running from the application image – how often do you not update software in the field?!?). If the flag is set and I booted from the factory address, I read address 0xF from the remote update controller. This tells me the trigger condition for the current boot. If this register is set to either 0x0 or 0x10, it tells me that it loaded from the factory address on purpose vs. trying to load from the application address and failing.   So if I think I have a valid application loaded I reconfigure from the application image. If I booted from the factory address due to an error (from trying to boot the application image) I just run with the factory image.

[Altera_Forum]

Howdy. 

I'm currently integrating this remote update core into one of our designs to replace our current remote update method. We have update files that contain Software images directly after the FPGA hardware image that are loaded into the EPCS.  The default bootloader will scan through the EPCS until it finds this code and then load it into RAM. All pretty much standard default stuff. However for this remote update Factory vs User application thing to work, the bootloader will need to be modified to scan through the EPCS from the CURRENT boot image start. Be it factory or user at some other location in the EPCS. I think I've got all that done, but would like to clarify one of the register entries in the REMOTE UPDATE core. Register 0x04 (eg current source Boot address) shows it is only valid in an MSM mode of factory? according to table 3-3 of the ug_altremote.pdf. So how does one get the current boot address once the user instance has been loaded into the FPGA? I need this value to allow the bootloader to do it's software hunt magic at the new user application location in the EPCS, rather than just starting at an address of 0. It would be nice to be able to read this out rather than having to hard code it into the bootloader..  Thoughts??  Thanks

[Altera_Forum]

--- Quote Start ---  Howdy. I think I've got all that done, but would like to clarify one of the register entries in the REMOTE UPDATE core. Register 0x04 (eg current source Boot address) shows it is only valid in an MSM mode of factory? according to table 3-3 of the ug_altremote.pdf. So how does one get the current boot address once the user instance has been loaded into the FPGA?   --- Quote End ---    In application mode the value of this register is 0x8 for my system, which is not the application boot address.  It must only be valid in factory mode. :(

[Altera_Forum]

hmm, thing is the CIII remote update hardware seems to indicate that this information is available. The CIII Handbook states that Application Information 2 contents in the status register contains the Current Boot Address. (Volume 1, Table 12-5). Now this Application Informations seems to be listed seperately to the Previous State register stuff... So where is it in the SOPC remote update Cores memory map?? This is the only reference I can find to it, but there is no information on how to actually read this Application Information 2 out of the HW.... 

God I'm getting tired of how poorly Altera Document things. Time for a support request I think..

[Altera_Forum]

--- Quote Start ---  In application mode the value of this register is 0x8 for my system, which is not the application boot address.  It must only be valid in factory mode. :(  --- Quote End ---    In my opinion, this alone makes the REMOTE UPDATE feature basically unusable as is.  What you can do is check when running the factory software if the update configuration loaded, then copy the update version in RAM to the execution address and jump to the startup code. The routine you call to copy either has to be copied to and run from the stack, or far easier, put the routine in onchip memory and just call it. None of this was fun but I was able to get this working.  Bill  Edit in bold

[Altera_Forum]

Yes I think whoever did this core was a bit slack and only did a rather half assed job. The documentation is poor. Examples are as usual not real world. 

The docs for the HW remote update core in the CIII itself are even more useless. I really don't understand what Altium are up to... If they don't document these things thoroughly how the hell are we meant to use them. I think I'm just going to wait and see for the moment on what Altiums reply is to my support request. Because without being able to get this simple value out of the memory map (which appears to be available in the HW core) then trying to do nice simple remote updates is going to be a pain. I'm thinking that given I'm currently hard coding where I store things anyway, I will just hardcode the boot address into the bootcode directly rather then trying to look it up from the remote update core.. other way is some table elsewhere in EPCS to store where I last wrote the application code to.. and some CRC to validate it.. which makes the bootcode a fair bit larger.. and messier from my point of view.. That is the kind of thing I was going to do in the factorys software itself.. not the bootloader.

[Altera_Forum]

richo25 - pm me your e-mail address. I have a remote update example and docs from my FAE that are not on the Altera site. You might find them useful.

[Altera_Forum]

--- Quote Start ---  richo25 - pm me your e-mail address. I have a remote update example and docs from my FAE that are not on the Altera site. You might find them useful.  --- Quote End ---    How many more engineers are going to struggle with this before it's put on the Altera WEB site and easily found with a search for Cyclone III Remote Update?  Bill

[Altera_Forum]

--- Quote Start ---  How many more engineers are going to struggle with this before it's put on the Altera WEB site and easily found with a search for Cyclone III Remote Update? Bill  --- Quote End ---    I think the entire RU documentation needs to be redone. It is really poor and still the only way I figured it out was trial and error. Hopefully Altera will step up and revise their user guides and app notes.

[Altera_Forum]

coxmw could you please send it to me too, it will probably be faster than to contact my FAE (although he is a really nice guy)

[Altera_Forum]

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.