Forum Discussion

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

NIOS SBT IDE Debugger Problems

I've been all over the forums and have yet to see an answer to this problem.

I'm trying to debug some simple code using the debugger in the NIOS IDE. It basically reads/writes to on chip memory and then periodically writes to a PIO that lights up LEDs on a starter board. I know that the code works because when I compile in Quartus and program the board, the LEDs flash in the order I would expect.

I thought this would be a good opportunity to learn how to use the debugger. I right click on the project and select debug as -> NIOS II Hardware.

It starts up fine, but I get two problems:

1. The debugger ignores my breakpoints. There is a little yellow triangle with an exclamation point and the code on that line is underlined in yellow. If I mouse over it, the message "unresolved breakpoint" appears.

2. If I suspend the debugger it gives me the message "No source available for "main() " ", so I can't even see where the code is suspended.

The debugger seems to work otherwise. When I run it the LEDs light up. When I suspend it the LEDs stop flashing and only one stays lit.

I've tried playing with the debug configuration settings such as toggling the option "Stop on start up at main()", etc. No luck.

Any ideas? Thanks!

8 Replies

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

    One thing is to make sure you compile with NO optimizations.. They will mess with the debugger..

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

    --- Quote Start ---

    1. The debugger ignores my breakpoints. There is a little yellow triangle with an exclamation point and the code on that line is underlined in yellow. If I mouse over it, the message "unresolved breakpoint" appears.

    2. If I suspend the debugger it gives me the message "No source available for "main() " ", so I can't even see where the code is suspended.

    --- Quote End ---

    This usually means the debugger source file list is somewhat corrupted and it has not the correct references to actual source files.

    It happened to me a couple of times, too, but I can't remember how I solved it.

    I guess you already tried to clean the project and recompile all.

    Then, if you have not done yet, create a new debug configuration.

    The last option would be re-create the project from scratch.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Completely deleting the project and starting a new one worked to resolve the bad break points. Now for some reason the processor stays on 0x0000000 no matter what. Whenever I pause, the address is always paused at 0x000000. Doesn't matter how I run it, or for how long. These tools can be so frustrating.

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

    This is very strange.

    Did you perform the same LED test like above? Namely, are you sure your cpu is running and it stops at the breakpoint?

    After the breakpoint, can you resume or restart execution?

    Does your system have a watchdog timer or anything similar which could possibly reset the cpu when execution is suspended?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Yes, the test is identical. I'm not sure the CPU is running. It seems I'm now back to a similar problem I had before where the code never reaches main. It seemed to resolve itself when it happened before, or at least I don't know what I changed that fixed it. Simulation in modelsim revealed that the code never accesses my test memory or writes to the PIO, and it is really confusing how this could be because I literally changed nothing in the code.

    No watchdog timer. The CPU shouldn't reset until the system reset signal is asserted. This only happens in hardware via a push button. Pressing the reset signal while the debugger is running forces the debugger to pause and the code it points to is the reset vector. If I continue from that point the code still never reaches main, but it does tell me that the reset button is working.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Turned out that the problem was caused by having c_plus_plus enabled. Weird.

  • Jens's avatar
    Jens
    Icon for Occasional Contributor rankOccasional Contributor
    8 years ago

    I had the same problem. In my case the solution was to switch the debug level (properties->Nios2 application properties) from Off to On.

    Jens