Forum Discussion
Altera_Forum
Honored Contributor
Honored Contributoraltremote_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) 0 1 2 3
0x4 0x0 0x3 0x080000 0x020000
0x7 0x0 0x2 0x0 0x0
(0,1,2,3 - read source)8 Replies
Altera_ForumThe 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--- 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
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
What's the clock frequency driving the remote update core?
For CIII it must be fclk<40MHz. - Altera_Forum--- 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
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--- 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
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.
