Forum Discussion

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

altremote_update - cold-start issue

Hi,

I'm having some problems with the altremote_update core on a Cyclone III FPGA.

===# 1 ===

- reconfiguration from application offset (0x080000) after cold-start of the system does not work. the system reconfigures with the factory image (offset 0x0)

- if I try again (same system, same firmware, no power cycle after the previous operation) it works

I have done some readings of the 0x4 and 0x7 registers in before the 1st (after cold-start) and 2nd configuration and got the following:

reconfiguration after cold start 

         	       0	1	2	3
0x4	            0x0	0x3	0x3	0x020000
0x7	            0x0	0x0	0x0	0x0
(0,1,2,3 - read source)

2nd reconfiguration 

         	       0	1	2	        3
0x4	            0x0	0x3	0x080000	0x020000
0x7	            0x0	0x2	0x0	        0x0
(0,1,2,3 - read source)

===# 2 ===

After the 2nd (succesful) dynamic reconfiguration, the system stays in the new firmware for about 15 seconds and than reconfigures itself with factory image.

=============

before reconfiguration trigger I set param 4 to word offset of application image (0x020000). I do not make use of the watchdog.

Is there something I should (not) do? Do I have to set/reset the watchdog? Can the reconfiguration work only by setting the register 0x4?

The ug of the altremote_update core doesn't bring to much light in this situation :-(

Thanks!

8 Replies

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

    The 2nd bit set (value=0x2) in register 7 for past status (read source 1), shows that fpga reconfigured because of a watchdog timeout.

    If I remeber correctly the watchdog timer is automatically enabled in user configuration and disabled in factory configuration. So you need to explicitly disable or periodically reset it when the application image has been loaded (and preferably after you have checked it is correctly operating).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    --- Quote Start ---

    The 2nd bit set (value=0x2) in register 7 for past status (read source 1), shows that fpga reconfigured because of a watchdog timeout.

    If I remeber correctly the watchdog timer is automatically enabled in user configuration and disabled in factory configuration. So you need to explicitly disable or periodically reset it when the application image has been loaded (and preferably after you have checked it is correctly operating).

    --- Quote End ---

    Thanks! It was the watchdog!

    That's what I did and it worked. Both issues were solved with this.

    :(Altera needs to revise documentation for some cores... especially this one.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    I thought I have solved the issue, but it's still there... before reconfiguration (factory->application) I set the watchdog timer to maximum value (all upper bits 1) and enable the watchdog.

    In application mode I created toggling signal (50% duty cycle, 10 us period) to act as a watchdog reset (basically it gets reset every 5 us and the reset strobe stays active for 5 us).

    But it doesn't seem to work: my design gets reconfigured after ~3 minutes back to factory image.

    Do I have to do anything else when reaching application image except reseting the timer? Is there a minimum distance between 2 timer resets?

    I don't understand what I do wrong....
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    What's the clock frequency driving the remote update core?

    For CIII it must be fclk<40MHz.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    --- Quote Start ---

    What's the clock frequency driving the remote update core?

    For CIII it must be fclk<40MHz.

    --- Quote End ---

    the clock is 25 (and ok since I am able to change boot address and reconfigure).

    one susicion: the clock is fed by a PLL and may not be available during and short after configuration. can this be an issue?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    The PLL is not an issue. I use it, too

    I'm concerned about those 3 minutes

    With a 25MHz clock and maximum wd timer I calculate you should get about a 21sec timeout.

    Try with a longer reset cycle time or with a shorter timeout value different from all 1
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    --- Quote Start ---

    The PLL is not an issue. I use it, too

    I'm concerned about those 3 minutes

    With a 25MHz clock and maximum wd timer I calculate you should get about a 21sec timeout.

    Try with a longer reset cycle time or with a shorter timeout value different from all 1

    --- Quote End ---

    ok, I will try that after the weekend.

    however I believe that your assumptuon that the ru core is using my clock for operation is wrong. in order to detect errors while loading the new application (crc, timeout) the RU core must be using its own clock independent on the existance of a user one (=valid application image). the 25 mhz should onl be a register interface clock.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    You are right. I browsed the CIII datasheet and I found that watchdog timer is actually driven by a 10MHz internal clock, while the user clock is only for register access.

    However this means a 52sec timeout, which is far lower than your 3 minutes.