Forum Discussion

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

Problem in migrating design from Quartus 9.0 (SOPC) to 13.1 (Qsys)

Hi there,

I installed Quartus 13.1 (update 4) on a new Windows 8.1 PC and I'm trying to migrate some old designs created with Quartus 9.0 sp2 and SOPC builder.

I had no problem in converting the fpga project and the sopc system to the new Qsys.

I also imported the old Nios application and created the BSP project to replace the old syslib: like before, I used the SSS template with uC OSII and interniche stack.

After minor effort everything compiled fine and I'm now able to configure fpga and download the application into the Nios processor. FPGA firmware is operational and so Nios seems to be, but my application hangs somewhere.

I used the debugger feature and I discovered the code hangs in the alt_sys_init, generating an exception.

From what I can understand, this happens as soon as the timer is initialized.

Infact Nios crashes when I hit the macro call: ALTERA_AVALON_TIMER_INIT ( TIMER, timer)

I also tried to insert code at the very beginning of the alt_sys_init function and this works, as long as I don't execute the following auto-generated initialization code. For example, I inserted a long loop where I toggle a PIO connected to a LED and I see the LED flashing. When the loop terminates and the regular part of alt_sys_init is executed, Nios crashes.

Any ideas?

3 Replies

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

    I hope the attached screenshot can help someone of you to solve my problem.

    I've been stuck on this point for two days.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    As I recall, and I may be hazy here, but I think you need to link in a debugging library and initialize it early in your code. I don't remember the details, but it should be in the Nios software documentation. If I recall correctly, the debug stub needs an exception handler defined that executes when a breakpoint is hit. I think the init routine fills in the breakpoint handler address in the vectors.

    Alternately, you could undefine NIOS2_HAS_DEBUG_STUB and it won't call the function that crashes.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    The NIOS2_HAS_DEBUG_STUB define has no effect. It changes the action taken when exception happens, but the exception itself is still there.

    The issue seems to be caused by a missing irq handler. The strange thing is that with the debugger I see a valid handler short before the exception happens, then it become NULL when alt_irq_enable() is called. Anyway I don't know if this is simply an artifact, since the code goes through a lot of macros and inlined functions which could mislead the debugger.

    Going deeper I found that the exception is thrown when code calls NIOS_WRITE_STATUS(context), where context=1;

    I don't know if this is related to my problem, but I get many of these warning messages during project build:

    0 [main] pwd 6064 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to

    the public mailing list cygwin@cygwin.com

    0 [main] sh 4956 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to

    the public mailing list cygwin@cygwin.com

    0 [main] sh 5384 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to

    the public mailing list cygwin@cygwin.com

    ...