Forum Discussion

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

Remote-update: watchdog timer

Cyclone 3 device.

I am implementing remote update, and always get watchdog timer error for user image reconfiguration as a cause (bit 1 of parameter 111b).

Questions:

- which value of previous reconf cause register (read_source=01) should I get after power cycle? I did not find it covered in the Remote update manual, and seems the value is 0 (no cause at all);

- after I perform AS update using Blaster device, I expect that cause will be other than 0 (either nconfig or nstatus) because Blaster device operates these lines, however I get status 0 (no cause for reconfig);

Here's my code for factory image


          // state 0: reading reason for previous reconfig
    4'h0: begin
        r_param <= 3'b111;                // status reg
        r_read_source <= 2'b01;        // previous status reg
        r_read_param <= 1'b1;
        r_sm <= r_sm + 1'b1;    // next state
    end
    // state 1: waiting read completion, setting up digit group counter
    4'h1: begin
        r_read_param <= 1'b0;
        if(~w_busy) begin                                    // not busy any more?
            r_cfg_status <= { 1'b0, w_data_out };        // latch status returned, 2 bits * 3 groups
        end
...
                // state 5: writing watchdog reset bit to be _reset_ (no watchdog is used)
    3'h5: begin
         r_param <= 3'b011;                // boot address reg
         r_data_in <= 24'h0;            // watchdog is disabled
         r_write_param <= 1'b1;                // start write parameter command
         r_sm <= r_sm + 1'b1;    // next state
    end
       // wait for watchdog disable write completion, and writing start address of new config image
    3'h6: begin
        r_write_param <= 1'b0;                // reset write parameter command bit
        if(~w_busy) begin                        // not busy any more?
             r_param <= 3'b100;                // boot address reg
             r_data_in <= 24'h08_0000;    // boot address itself
             r_write_param <= 1'b1;                // start write parameter command
             r_sm <= r_sm + 1'b1;    // next state
         end
     end
      // state 6: performing reconfiguration
    3'h7: begin
         r_write_param <= 1'b0;                // reset write parameter command bit
          if(~w_busy) begin                        // not busy any more?
               r_reconfig <= 1'b1;                    // trigger reconfiguration
          end
         end

You can see I disabled watchdog timer, and I also did not load image @ address 80000, thus I would expect error reported to be CRC error, but getting 00010 instead (watchdog bit is set) from previous config cause reg (r_read_source[1:0] <= 2'b01).

What's wrong?

Edit: I added another statement into the state 5 above

r_read_source <= 2'b0;

and put reconfiguration into the loop (so that (1) it displays code returned by reading previous reason for reconfig and (2) proceed with another reconfiguration) and funny enough behavior has slightly changed:

  1. power cycle;

  2. code returned is 000000;

  3. first reconfig attempted;

  4. reverting back to factory config @ 0 displaying code 010000 (nconfig_source);

  5. second reconfig attempted;

  6. reverting back to factory displaying code 000001 (runconfig_source);

  7. the same as going to step 3, displays 010000, after next reconfig 000001, after next 010000 etc etc

Anyone can explain this behavior?

1 Reply

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I've got application image to configure successfully, to do it:

    1. added this "r_read_source[1:0] <= 2'b0;" before wiriting, it seems with r_read_source set to 01 it was behaving weirdly;

    2. boot address supplied should be already without two least significant bits, thus "r_data_in[23:0] <= 24'h02_0000;", however some documentation was stating that these bits are automatically removed from 24-bit vector.

    But the status register issue is still there.