Random reset in Nios II

[Altera_Forum]

Can someone tell me what can basically cause a software random reset in Nios II? 

 Thanks. Carid

[Altera_Forum]

Hello, 

I am not sure this is your case but a lot of times in this forum some people had problems with the connection of reset_n, global_reset_n, debug_request and similar signals in the top level of their projects.  I am sorry if this does not help you, but sometimes the simpler problem causes the strangest errors.  Regards, Gabriele

[Altera_Forum]

Thinkig better to this problem... I don't know what kind of software is running.. If you have some kind of complex software project (bootloader, kernel) it can be a problem like this: 

think about a code that in some point it copies itself somewhere else (it relocates itself) and for an error in the linker script, some portions of software collide (and the first copied goes over another); if the one which is overwritten is the one that manages interrupts or exceptions, you may have the initialization procedure instead of the service routine for some irqs. This happened to me some months ago.

[Altera_Forum]

Thanks for your sharing. But I have a random software reset occurs in my instruction related event.

[Altera_Forum]

From the all the information You've provided, in conclusion, the best answer to Your problem is this: 

something is BAD.  Good luck.

[Altera_Forum]

Thanks, but can you please further elaborate on what is bad? Software or hardware?

[Altera_Forum]

You must provide more information to identify the cause. 

Did you observe any correlation with particular software code execution, i/o switching, interrupts, etc ? And first of all, are you sure about reset signal, power supply stability, external memory timings? Did you try to run a simple program, possibly using only onchip memory, and verified if you still have the random reset behaviour?

[Altera_Forum]

Thanks. I actually have an instruction related event. 

 I added an alt_instruction_exception_register(InstructionException), and some code to allow me to cause an instruction exception when I want to.    My handler does trap my intentional unimplimented instruction but it is also getting traps every second or so from a location in    tcp_wakeup(void * event) PC=105a4f8, addr = 0, inst = 24000117, cause = -1 the instruction is  /* use extension */  WEP =tcb->OSTCBExtPtr;  105a4f8: 24000117 ldw r16,4(r4)

[Altera_Forum]

I really don't know Nios at this level, so I think I can't give you much help. 

I'd try relink and map the problematic code to another section: i.e moving it from sdram to a sram or better onchip memory. I'd also check for possible stack overflows. Is that WEP variable local? If so, try to declare it as static.

[Altera_Forum]

tcp_wakeup is a network function.  

The tcp_wakeup function may need to be mapped to a user defined function. Try running the code without the network functionality, if possible, to isolate the problem.

[Altera_Forum]

You want to look at the value of r4 saved by the trap handler - it might 

be invalid (and if you have the mmu, mpu, misaligned address or unmapped Avalon slave traps enabled) have caused a trap. Some instruction related traps might be slightly asynchronous - so also check the previous 2 or 3 instructions.

[Altera_Forum]

Thanks. So when software reset occurs, will it cause the stack to die?

[Altera_Forum]

A cpu reset probably only changes the program counter and disables any mmu! The other registers might be reset, M9K memory is unlikely to be affected and the contents of external memory are extremely unlikely to change. 

Of course, once the processor is executing code again, it will change registers and memory. So any data in the old stack will remain until overwriten, but the stack pointer will be unknown (written to by the reset code). One thing I've not looked at is whether %r0 is actually writable! It is assumed to read zero - but is a real memory location.