Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12589 Discussions

NIOS Software appears to restart

Altera_Forum
Honored Contributor II
992 Views

I built a first generation "larger than life" version of a product using an EP4CGX75 FPGA, and got my system and software running. I now have an ultra-miniature version of this using an EP4CGX15 part. On the new board, the code runs for a while and then "resets" at the exact same place every time and appears to start at the beginning of the program. The point at which the system crashes is different if I make code changes, but for a particular code build, it always stops at the same point and appears to start at the beginning of the code 

 

I have created new QSYS files and have generated a new BSP file. I've deleted previous incremental compiles and the db directory. I've looked at the linker information and everything seems reasonable. The places at which the code crashes have what I would say is fairly innocuous code, e.g., printing the contents of a buffer, not writing to an array or variables. I've looked at the power supply and at the reset signal, and they look OK. Am using Quartus 12.1. (Would prefer not to switch tool versions in the middle of a project, but then again, I need to get this working...) 

 

Any thoughts on what would be a good strategy for debugging this? 

 

Thanks in advance.
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
261 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
261 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
261 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
261 Views

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?
0 Kudos
Altera_Forum
Honored Contributor II
261 Views

I don't use Eclipse that much, but IIRC when you create a new project there should be two of them. A BSP, that is linked to the sopcinfo file, and the application itself, that is linked to the BSP. Are you sure you recreated both projects? I think that when you create a new project in Eclipse, you have the option to create both the Nios2 application and the BSP at the same time.

0 Kudos
Reply