Forum Discussion

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

NIOS Processor Fails to Reset

We're using a Cyclone III FPGA with a NIOS processor & custom designed logic. The system was built using Quartus V8.1. A configuration sequence can be forced via an external watchdog timer. When the watchdog causes the configuration to occur, the configuraton completes successfully, however, the processor does not appear to correctly reset.

I've confirmed that the configuration was successful by the fact that the custom (non-processor related) logic functions correctly, however, the processor code does not execute. Using the JTAG interface, I was able to bring up the nios2 console, and reset the processor by entering the following commands:

halt

reset

go

The processor will then execute code. Also, when a power on reset sequence occurs, the processor will execute code correctly. It only mis-behaves when the reset occurs from the watchdog timer.

The watchdog timer output is connected the the FPGA nCONFIG input. Again, the configuration sequence occurs correctly.

The system contains Flash memory & DDR DRAM. Both the processor reset signal & Flash reset signals originate from the same internal FPGA reset logic. The reset logic is a 5 bit counter that counts 64 clocks. When counting, the reset is asserted. When the count completes, the counter is disabled, and the reset signal is deasserted.

The DDR DRAM is reset by the DRAM controller, which was generated using SOPC builder. The reset input to this controller originates from the same reset counter described above.

When the system is reset using the JTAG interface & nios2-console, the system seems to perform normally.

The problem occurs on one out of every 5 or 6 boards. The rest seem to operate correctly, indicating some type of timing issue.

Anyone out there encounter a similar problem?

3 Replies

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

    Jake

    At reset, the processor vectors to the base address of Flash (0X0a000000). Execution code is copied from Flash to DRAM. I'm still investigating, but I was able to see the Flash CE# assert 8.36 us after the CPU reset deasserts.

    I 'believe' that this is a Flash read (I'll know more today). I was also able to see the DRAM CKE signal assert 210 us after the cpu reset deasserts (DRAM clocks start 200 us before CKE asserts per DRAM spec).

    While this is not yet definite proof, I think that the data is being moved from Flash to DRAM correctly. The basic sequence looks right -- CPU reset deasserts, Flash activity, then DRAM activity.

    Last night, I had 2 similar thoughts to your recommendation. One was to hold the processor in reset longer than the memory devices. This would guarantee that both memory devices come out of reset before the processor uses them.

    The other thought I had is that maybe the CPU reset pulse width is not long enough. It could be that the the CPU reset is asserted during the final stage of the FPGA configuration, & ends BEFORE the config sequence completes. Maybe just making the CPU reset pulse longer will do the trick.

    In any case, thanks for your input. I'll let everyone here know how things go.

    Fred Oliva
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    What is the reset address of the processor and where is it located (flash, serial flash, onchip RAM, etc.)? Is execution code being copied to the DDR DRAM before execution? Are you sure it's not a DRAM problem?

    I suspect the RAM or the interface to the RAM first. Try holding the NIOS in reset much longer than the DDR controller and see what that does.

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

    --- Quote Start ---

    I suspect the RAM or the interface to the RAM first. Try holding the NIOS in reset much longer than the DDR controller and see what that does.

    Jake

    --- Quote End ---

    An update.....

    I did what you suggested. I isolated the reset to the processor & made the reset pulse to the processor longer (increased from 870 ns to 1.4us). Initially, this did not make a difference.

    I then changed the logic that resets the processor so that I could reset just the processor from an external switch. The processor would successfully reset & execute code when the switch was pressed.

    I then modified the processor reset logic to remove the external reset, and to make the pulse width REALLY long (5 seconds). This did the trick. The system would now take a reset from the watchdog timer & the processor would start up & execute code. Before, when a configuration & reset was initiated from the watchdog, the FPGA would configure, the non-processor FPGA logic would run, but the NIOS would not start.

    After some experimentation, I discovered that I could make the processor pulse width as short as 360ms & the processor would successfully reset & execute code. Any shorter, & I would see the original problem.

    Right now, I believe that there is some sort of race condition with the processor & the way the memory subsystem is starting up. I modified the FPGA design so that the processor pulse width is 670ms & is a separate signal from the reset signal that resets Flash & DDR DRAM controller. The Flash & DRAM controller reset signal is asserted at the same time, but only is 870ns wide.

    I successfully tested the change on both boards that previously exhibited this problem. I also successfully tested the change on boards that previously were working. Finally, I did some repeat testing on one of the boards that previously failed by forcing a watchdog timer reset >10 times. Each time, the system would now come up & run properly.

    Due to time constraints, this is as far as we're going to take this problem at this point unless it resurfaces.

    Thanks for all your help & your suggestion.

    Fred O