--- Quote Start ---
Are you sure the sof file has been generated with the updated hex files?
It seems you have some memory section not correctly initialized: then when the code hits there, it hangs.
Although I believe this is not your problem, you may try to add the following calls in the very beginning of your main() for every code/data segment which is possibly not mapped to the default linker sections.
ALT_LOAD_SECTION_BY_NAME(<name>)
--- Quote End ---
Thanks for your reply!
I believe it is properly generated with the current code. At least, changes made to the source are reflected in the behaviour of the running system. It certainly looks like what you describe, I just can't figure out how it ever gets to that uninitialized memory. The code just sits there in a loop, responding to serial packets. There's no reason why the path the code follows would be different in response to the Nth packet than the (N+1)st, especially if it's (N+1) copies of the same packet. I'm probably clobbering the stack somewhere, and overwriting a return address, I just can't see how that wouldn't cause disaster the first time, too. Does the ELF contain the opcode for NOP in each uninitialized code location? I suppose that would account for the difference in some deeply pathological case. Hmmm, this is giving me an idea. I'll have to see if NIOS II has an "illegal opcode" trap.
--- Quote Start ---
After you loaded the sof configuration, open a Nios shell prompt and write 'nios2-terminal'
If you want full debug functionality (step into code, start, stop ...) you can still use Run As... in Eclipse, but you must disable the default Reset and Download features, so you simply attach the debugger to the running program.
--- Quote End ---
And thank you for this! I've been banging my head against this for weeks. :)
Honored Contributor
