NIOS Software appears to restart

Assuming it's software, and not hardware:

Did your changes include things like shrinking the size of the stack or the size of fixed buffers? Your problem description overall sounds like memory corruption leading to an erroneous branch to the reset vector, which is kind of easy to do if your stack is too small and you use a "big" function like printf().

When you're changing code and seeing the change in behavior, what you're doing is changing the layout of the memory, so the same bug is trashing different parts of your program. You can try things like increasing the size of the stack / allocated buffers and see if the problem "goes away". You can also do things like comment out functions (e.g. your printing to buffer) and remove increasingly large quantities of code until the problem "goes away" so you get a hint what area of the program your bug is in. Finally, since your behavior is repeatable / fixed with a given compile, you should be able to use a hardware breakpoint immediately before the apparent reset happens, and single step until it does.

Theres lots of debugging tricks, but what you want to do will depend on the details of your program.

Well, here's where I show that I'm stretching myself by writing software....

OK. I just went back and checked. The new and original designs both have the same-sized single hunk of memory and all the sections use this (.heap, .rodata, .rwdata, .stack, .text).

In both cases, the size shown in the BSP editor matches what exists in the system.

* Do I have to do anything else other than generate a new BSP to make sure that the linker does the right thing?

* How can I verify the size of the allocated areas?

* Shouldn't I expect to see an error like "insufficient memory" if it doesn't fit?

I can set a breakpoint and demonstrate that the program goes awry (in one case) at a printf. This seems to match your hypothesis that the stack may not be big enough.

If you aren't using a multitask operating system, then the stack and the heap memory will share the same memory space. The heap will just begin to allocate the memory from the beginning of the area, whereas the stack will start from it's end and go down as you use it. I'm not sure a malloc() call will in fact report insufficient memory before it collides with the stack.

Do you allocate a lot of memory in your code? Are you using a mechanism that puts a lot on the stack, such as a recursive algorithm? If you use the debugger, you should be able to see the addresses of the allocated buffers returned by malloc() and monitor the stack pointer, to check for any collisions.

I think I've figured out what is going on, but I'm not sure how to fix it.

I took my original design, copied it to a different place on the system and started using it. For some reason, even though I pointed to the eclipse workspace in the new directory, when I look at the path, it points to the old one. So, what is happening is that the bsp file isn't matched up. I just created a new hello world project from scratch and am trying to use this as a starting point. Once I have this set up, I can copy my working software set into the directory and hopefully it will work.

I went through the process to create a new project using the hello world template, pointed it to the correct SOPCINFO file, and compile it. The problem I'm now running into is that there isn't a run configuration. I go to set up a run configuration, but there is no ELF file. I browse for an ELF file and find nothing. I've cleaned and rebuilt the project. Any thoughts on next steps?