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]

Bill, 

 I am fighting this myself right now. The documentation is not the best.  First, address 0x20 for the reconfiguration isn't defined in the CIII handbook. If you go here http://www.altera.com/literature/hb/nios2/qts_qii55017.pdf (http://www.altera.com/literature/hb/nios2/qts_qii55017.pdf) on page 28-2 the control/status register is defined. Reading/writing to any address 0x20-0x3F will access this register.  i think you can read the current boot address from this register // read current boot address bootaddress = iord( remote_update_base, 0x4);  *EDIT* It looks like address 0xC shows the last boot address  I am working on this right now to see if it works. I'll let you know...  Mike

[Altera_Forum]

--- Quote Start ---  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).  --- Quote End ---    Do you really need to overwrite the factory image? I am trying to do something similar except always keep the factory image at the default boot address and at startup check to see if there is a valid application image. If so, reconfigure from the application image address and run. This way the factory configuration is always there.   It does slow down the boot up though because once an application image is loaded it always has to reconfigure itself.

[Altera_Forum]

--- Quote Start ---  Bill,  I am fighting this myself right now. The documentation is not the best.  First, address 0x20 for the reconfiguration isn't defined in the CIII handbook. If you go here http://www.altera.com/literature/hb/nios2/qts_qii55017.pdf on page 28-2 the control/status register is defined. Reading/writing to any address 0x20-0x3F will access this register.   --- Quote End ---    Thanks Mike. Why that's not in the main manual baffles me. Especially when the sample code uses 0x20 which contradicts the preceding paragraph.    --- Quote Start ---    i think you can read the current boot address from this register // read current boot address bootaddress = iord( remote_update_base, 0x4);  *EDIT* It looks like address 0xC shows the last boot address    --- Quote End ---  Do you see that in the debugger too? I don't know what you did, but we just plopped a Remote Update into SOPC builder - we did not use the MegaWizard as they seem to imply you should. The Cyclone III doesn't have anything configurable as they show for the Stratix II.  Also, we noted that latest Remote Update chapter adds an fMax limit on Remote Update. It says 40Mhz (Cyclone III), which I'm sure is 1/2 or less the speed of most users. I expect for reading and writing registers that this is not an issue.    --- Quote Start ---   I am working on this right now to see if it works. I'll let you know...   --- Quote End ---  Thanks! Bill A.

[Altera_Forum]

--- Quote Start ---  Do you really need to overwrite the factory image? I am trying to do something similar except always keep the factory image at the default boot address and at startup check to see if there is a valid application image. If so, reconfigure from the application image address and run. This way the factory configuration is always there.   It does slow down the boot up though because once an application image is loaded it always has to reconfigure itself.  --- Quote End ---    I mean overwrite the running copy in SDRAM - not in Flash. Remote Update only loads a second configuration - not the NIOS II software that accompanies it in the second half of EPCS. Why Remote Update doesn't do both is insane - most users would update the logic which might have a software change to go along with it.  Bill

[Altera_Forum]

I am using SOPC builder as well. The fact that it is just a wrapper around the alt_remote_update megafunction is a little confusing, especially since the ports don't match up. Also it would be really nice to have a "traditional" register map instead of the one shown in the megafunction user guide. 

 I have some more information that may be helpful.  Register 0x0 is nice. If the value is 0x0 it booted from the factory address and if it is 0x1 it booted from an application address. The documentation says this register is only valid in factory mode but I have some other Altera documents that say otherwise. This is the bit I was looking for to tell me where the current boot came from.  When it is booted from an application address, register 0xC shows this address. DON"T read this value for the factory configuration because it doesn't show the factory address (which is terribly confusing).  Register 0xF is also helpful in factory configuration mode. It shows the reconfiguration trigger conditions. So if you thought that it should have booted to the application and it is still showing the factory config (again, register 0x0) this register will tell you why.   Mike

[Altera_Forum]

--- Quote Start ---  TAlso, we noted that latest Remote Update chapter adds an fMax limit on Remote Update. It says 40Mhz (Cyclone III), which I'm sure is 1/2 or less the speed of most users. I expect for reading and writing registers that this is not an issue.  --- Quote End ---    I am running at 40MHz (AS config). It seems to be working.....for the most part.

[Altera_Forum]

--- Quote Start ---  I am using SOPC builder as well. The fact that it is just a wrapper around the alt_remote_update megafunction is a little confusing, especially since the ports don't match up. Also it would be really nice to have a "traditional" register map instead of the one shown in the megafunction user guide.   --- Quote End ---    I totally agree on the "traditional register map" aspect.    --- Quote Start ---   I have some more information that may be helpful.  Register 0x0 is nice. If the value is 0x0 it booted from the factory address and if it is 0x1 it booted from an application address. The documentation says this register is only valid in factory mode but I have some other Altera documents that say otherwise. This is the bit I was looking for to tell me where the current boot came from.  When it is booted from an application address, register 0xC shows this address. DON"T read this value for the factory configuration because it doesn't show the factory address (which is terribly confusing).   --- Quote End ---  So on a reconfiguration, we can only read registers 0, 2 and 3. But none of those allow access to the boot address. To be very flexible and not hard code the address, if the application (after a reconfig) could read the address, then it can find the Cyclone configuration and thus the NIOS application that follows. We now must use hard coded addresses.  Same goes for the watchdog - you can set it but when booting into the application, you can't clear it (right?).    --- Quote Start ---   Register 0xF is also helpful in factory configuration mode. It shows the reconfiguration trigger conditions. So if you thought that it should have booted to the application and it is still showing the factory config (again, register 0x0) this register will tell you why.    --- Quote End ---  Yes, this does help.   You've helped a lot and I appreciate your input. I think we do have a problem exceeding fMax. Then I should expect SOPC Builder would issue an error that the clock supplied to Remote Update was too fast. We would have caught this early on instead of now after we've tested the logic for 3 months and don't want to change it.  Bill

[Altera_Forum]

--- Quote Start ---  I am running at 40MHz (AS config). It seems to be working.....for the most part.  --- Quote End ---  That must be the problem then - rats!  Bill A.

[Altera_Forum]

--- Quote Start ---   So on a reconfiguration, we can only read registers 0, 2 and 3. But none of those allow access to the boot address. To be very flexible and not hard code the address, if the application (after a reconfig) could read the address, then it can find the Cyclone configuration and thus the NIOS application that follows. We now must use hard coded addresses.  Same goes for the watchdog - you can set it but when booting into the application, you can't clear it (right?).   --- Quote End ---     I don't quite understand all of this. Some registers are only used in factory mode, some only for application mode, and some for both. You can read more than just those 3 registers in factory mode but those are the only ones I use.  I think the watchdog is only accessible when reconfiguring. So if you set it you must always hit it in your application code. I don't use it but this is how I understand based on the documentation.    --- Quote Start ---   You've helped a lot and I appreciate your input. I think we do have a problem exceeding fMax. Then I should expect SOPC Builder would issue an error that the clock supplied to Remote Update was too fast. We would have caught this early on instead of now after we've tested the logic for 3 months and don't want to change it.  --- Quote End ---    That is a tough one. Are you using a serial flash? I suppose if the flash can handle the clock frequency the core should be able to as well. I think the only reason they put a 40MHz limit on it is for the EPCS devices. My serial flash claims a max 75MHz clock rate but I'm using 40 just because.

[Altera_Forum]

--- Quote Start ---  I don't quite understand all of this. Some registers are only used in factory mode, some only for application mode, and some for both. You can read more than just those 3 registers in factory mode but those are the only ones I use.  --- Quote End ---   In application mode, they mean after a reconfig, right? Wouldn't an ideal situation be that the bootstrap code reads the config address and knows immediately where to start loading the application - this removes the double load and the complexity of the application doing it on a reconfig. The modified bootstrap posted elsewhere here was hard coded to read the application after reading remote update registers, but it was done for Stratix II - you might want to modify it and use it for the Cyclone III.    --- Quote Start ---   I think the watchdog is only accessible when reconfiguring. So if you set it you must always hit it in your application code. I don't use it but this is how I understand based on the documentation.  --- Quote End ---  I wanted to use it just enough to know I was reconfigured and the application NIOS II software was copied and running.    --- Quote Start ---   That is a tough one. Are you using a serial flash? I suppose if the flash can handle the clock frequency the core should be able to as well. I think the only reason they put a 40MHz limit on it is for the EPCS devices. My serial flash claims a max 75MHz clock rate but I'm using 40 just because.  --- Quote End ---  Yes, EPCS but the speed limit isn't with it, it's with the remote update logic (probably because it maintains it's own clock for the WDT). Unless we have a boo-boo and are running the EPCS too fast (100MHz). Will check into it.  Thanks again for your response. Good luck!  Bill A.

[Altera_Forum]

--- Quote Start ---  Good luck!  --- Quote End ---    Argh. I keep getting an error (0x04) in the reconfig trigger source when I try to load the application image in. I guess this is common when the image is corrupt.  What file do you use to load the application image? I am using the .rbf and flipping the bits in each byte (read that here on the forum). This doesn't seem to be the right thing...

[Altera_Forum]

--- Quote Start ---  Argh. I keep getting an error (0x04) in the reconfig trigger source when I try to load the application image in. I guess this is common when the image is corrupt.  What file do you use to load the application image? I am using the .rbf and flipping the bits in each byte (read that here on the forum). This doesn't seem to be the right thing...  --- Quote End ---   I'm loading the .flash file. Using a program on the PC, it converts this to binary, sends the whole block down (Ethernet) and writes it to the second half (0x100000) of EPCS. This part works - in fact I can write to the second half or delete the second half to revert to the factory application. The update application is of course running with the factory configuration.  You can use Tools -> Program flash to get the .flash file. I used that console output to copy/paste into 2 scripts which I run from BAT files stored in the main program folder. I can click them in the IDE to create a new .flash file and also program flash (in lieu of the menu which is way slower).  I can program the factory half if the configuration were to change - it's just not failsafe. With a 5 second total programming time it's not a huge deal. A watchdog to fix a hung update application allowing it to revert to the factory again would be nice - I thought that's what the RU WDT was for and that it was more or less a general purpose WDT.  Bill A.

[Altera_Forum]

From an Altera doc "The watchdog timer is used to make sure that the configuration in application mode is operating correctly. This prvents a load of a valid but incorrect image from hanging the system." 

 So it is really only for somehow accidentally loading in a valid image that is incorrect and will not hit the wtachdog.

[Altera_Forum]

Actually, I get the "nStatus asserted by an external device" bit set in the reconfig trigger source even when booting from a fresh factory image (just overwrote all flash with just one factory image). According to the Altera docs, this should not be happening. I was hoping to use this to detect errors in the application reconfig, but if it is set at factory startup I will have to find another way.

[Altera_Forum]

--- Quote Start ---  Actually, I get the "nStatus asserted by an external device" bit set in the reconfig trigger source even when booting from a fresh factory image (just overwrote all flash with just one factory image). According to the Altera docs, this should not be happening. I was hoping to use this to detect errors in the application reconfig, but if it is set at factory startup I will have to find another way.  --- Quote End ---   Or are you and I finding similar experiences: Cyclone III and Remote Update have problems working together, or, something there is hidden that we're both not doing. I believe the latter because we both could be missing it in the docs. For me it wasn't a "try 'n post here" situation - I've been working on this on and off for a couple of weeks. But I fought SGDMA and TSE issues for over a week only find out the image I programmed into flash was corrupt (despite a correct TCP download!). Once I knew the image was right, I knew I had remote update problems.  What I did that simplified things is I added a function that copied EPCS from factory (0) to update (0x100000), compare them with a read and memcmp, and then did a Remote Update at 0x10000>>2. This way I knew the second image was good. It does reboot (if really into the second configuration I can't say) and the registers never said it was an application/update.  Bill A.

[Altera_Forum]

Funny. I did a search on Altera's site this morning on remote update and this is the first thing that popped up. I saw it was recent and thought I could contribute. I think we are having very similar problems. 

 I just did something very similar to you. I created a file using the Quartus "create programming files" tool that was a .pof at the factory location and the same .pof at the application offset. This is how I found the latest round of problems.   I'll keep plugging away although it is Friday afternoon and my brain hurts. :P

[Altera_Forum]

Now this just doesn't make sense. I am about to break something. 

 I concatonated (for lack of a better word) two .pofs to load in so that I knew both were valid and loaded them with the Quartus programmer.   I dumped the registers and found to be expected that register 0x0 was 0x0 (factory config).   Then I forced a reconfig from the application address, dumped the registers again and got this: 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   So address 0x0 is 0x1, which is great! It means the application image took. However I am completely lost on the rest of the registers. I would expect 0xC (12) to be 0x80000, which is the application boot address. For some reason it shows up in register 0x14 (20), which is the past status 2 boot address.   I assumed I would also use address 0xF to check for errors, but I'm not sure if/what bits are "good" and what ones are "bad". I was hoping check this register in the event that it boots from the factory address and I think it should have booted from the application address to check for errors.

[Altera_Forum]

--- Quote Start ---  Now this just doesn't make sense. I am about to break something.  I concatonated (for lack of a better word) two .pofs to load in so that I knew both were valid and loaded them with the Quartus programmer.   I dumped the registers and found to be expected that register 0x0 was 0x0 (factory config).   <snip>  So address 0x0 is 0x1, which is great! It means the application image took. However I am completely lost on the rest of the registers. I would expect 0xC (12) to be 0x80000, which is the application boot address. For some reason it shows up in register 0x14 (20), which is the past status 2 boot address.    --- Quote End ---   Ok, I was seeing this in the debugger (write to an address expecting to see the change in another and I didn't - something else changed). I don't have a serial port or output on the device (in fact it has only Ethernet!) and I wanted to bad to do what you did (I tried to flashing 2 LEDs to make sense of it). I will do a run checking 0x14 - I just want to see a 0 or non-0 for application. I don't see a change at 0, but I'll accept that being overspeed on the statemachine which I guess is setting these up. But I would expect static registers that I write to to survive a reconfig - if not, I'll give up until we change the logic, if ever (this product is "done"). We're starting a second product and I'll get them to fix this and ask for a WDT that I can enable and turn off after I know the update application is running OK. Maybe that can't be done because it's lost in a reconfig.   --- Quote Start ---   I assumed I would also use address 0xF to check for errors, but I'm not sure if/what bits are "good" and what ones are "bad". I was hoping check this register in the event that it boots from the factory address and I think it should have booted from the application address to check for errors.  --- Quote End ---  You could put in a service request - I did and am still waiting for a response.  LOL @ your head hurts. I hear ya - mine's been hurting for weeks now. :D Have a good weekend.  Bill

[Altera_Forum]

So I mapped out the registers in "classic" form using the megafunction user guide. See the attachment. 

 I ran several tests and dumped the remote update registers at each stage. I am still parsing through the results but hopefully this will give some insight into how to make it work.

[Altera_Forum]

--- Quote Start ---  So I mapped out the registers in "classic" form using the megafunction user guide. See the attachment.  I ran several tests and dumped the remote update registers at each stage. I am still parsing through the results but hopefully this will give some insight into how to make it work.  --- Quote End ---   This is great. Your register 0x0C contradicts table 3-3 in the ALT_REMOTE_UPDATE MF User's Guide. You've found that in application mode this is readable after a reboot? And to be painfully clear - you're using IORD and IOWR with these register numbers as arguments to these macros?  Thanks for documenting this more intelligently! :)  Bill A.