Forum Discussion

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

"Rescue" monitor idea

Our NIOS design has a field-upgrade capability via USB. As of right now we transfer the FW image (NIOS code or FPGA config), do a little checksumming and burn it into CFI flash (code) or EPCS (FPGA config). If something goes wrong during the programming and the user doesn't manage to reflash then the device is bricked.

I'm toying with the idea of adding a small NIOS "rescue" image and putting it into EPCS after the FPGA config. Whenever the FPGA boots from EPCS it would boot the rescue image which would have ability to do USB transfers and CFI/EPCS programming.

Once the rescue image boots it checks whether the current firmware image in CFI flash is ok, sets a watchdog and boots the CFI flash image, which in turn switches off the watchdog. If the watchdog expires the rescue monitor knows something is wrong and takes control again. At this point our diagnostic utility would be able to do memory tests, reflash the firmware, etc.

I'm wondering if anyone has done something like this and has any tips. A couple of things I haven't worked out yet:

- Is it possible to have more than one FPGA image in EPCS? Right now the weak spot is when we upgrade the FPGA config in EPCS. As far as I know that's a one-shot deal and you have to hope your config image at offset 0 is ok.

- Can I put my rescue monitor at the top of the EPCS instead of directly after the FPGA config so I don't have to rewrite the monitor each time the FPGA image grows? It's been a while since I looked at the boot loader sources but it seems like the bootloader scans the config data and then assumes the NIOS code follows. Has anyone successfully placed their code higher up in the EPCS and rewritten the EPCS boot loader to go to that address?

Thanks for any comments and insights,

Andrew

6 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    You may check the "remote system upgrade" feature of Cyclone III. They added hardware to help this.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    you could use 2 epcs devices for the two configs and a MAX cpld (with a built in watchdog) to switch between them...

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    I've just done this. But one caveat - my NIOS code is embedded in the FPGA image in an M4K onchip memory - I'm not loading NIOS code via the EPCS boot loader.

    I have room for two FPGA images in EPCS. At POR, FPGA image 0 is loaded. My software then:

    - checks whether or not FPGA image 1 is present in the EPCS

    - reads the remote upgrade core to make sure that we are running in FPGA image 0

    - reads the remote upgrade core to make sure that we didn't load FPGA image 0 because of a watchdog or CRC failure in FPGA image 1,

    - (optional) checks an external indication to see whether or not to load FPGA image 1,

    - and if all systems are go, sets the reconfig address in the remote upgrade core, and triggers a reconfig.

    When I upgrade, I will ALWAYS overwrite image 1, doing just sector erases for image 1.

    AND - alas, Altera has NOT provided an avalon core for the remote upgrade megafunction - you have to add your own logic to connect it to your SOPC system. One hint - I found that you just need to assert read or write to the megafunction for 1 clock cycle. If you leave read or write asserted, you might find that your write works, but reads don't.

    If you are using the EPCS boot loader, you will need to figure out how to tell the EPCS loader to use the FW that follows FPGA image 1 instead of FPGA image 0.

    \chuck
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    Hi Chuck,

    Are you using Cyclone III? Our design is plain old Cyclone I at the moment although we might upgrade.

    Thanks,

    Andrew
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    --- Quote Start ---

    originally posted by stonie@Mar 28 2007, 06:09 AM

    you could use 2 epcs devices for the two configs and a max cpld (with a built in watchdog) to switch between them...

    <div align='right'><{post_snapback}> (index.php?act=findpost&pid=22585)

    --- quote end ---

    --- Quote End ---

    I had this idea 2 year ago and implemented it, but two epcs devices are more expensive than 1 MAXII with a cfi .... now the design is coded into a maxii epm570f100 that does the fpga config, fail save fpga image handling (there is always a working image available), a watchdog, and of course 512bytes user flash available via spi (2MHz). The maxii device is full 100% used.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    --- Quote Start ---

    originally posted by queisser@Mar 29 2007, 05:50 PM

    are you using cyclone iii? ...

    --- Quote End ---

    I&#39;m using Stratix II. And I see that the remote upgrade core is not available in Cyclone or even Cyclone II (even though the EPCS controller is available) so what I&#39;m doing may not be possible in Cyclone/CycloneII.

    But CycloneIII does appear to have the remote upgrade core, so it should work there.

    We chose the EPCS config so that we wouldn&#39;t have to invest the extra time in a MAX+CFI approach, and for the smaller footprint; but after the fact, I&#39;m a little disappointed that there&#39;s no way to externally control the page that the EPCS boots from, and that the only control appears to be using the remote upgrade core.

    (Well, actually, I&#39;m not 100% sure there isn&#39;t something you could do in the Cyclone/CycloneII parts to select a different EPCS sector and then trigger the reconfig, as I didn&#39;t dig that deep; but the absence of the core suggests not).

    \chuck