System reboot

[della]

Hi guys,
in which cases does system reboot?
Is it due to...:
1) code problems (like division by zero)?
2) real-time problems (like deadline fault)?
3) hardware problems?

Thanks,
Marco

[chris]

Well, the system reboot is typically due to a bad usage of the micro-controller core (the CPU) or an hardware failure and it absolutely does NOT dependent on the real-time issues like deadline miss.
The other causes you mentioned are reasonable.

To be more specifically you can refer to the dsPIC refman, to inquire about the cause of your system reset, looking at the RCON Reset Control Register. Check its value with the debugger after the system reboot.

In the possible sources of reset there\'s the SW reset. This is a call to the reset function that in general should executed only at the system boot, when you turn on the device.
The reset function can be also called because of an explicit call (this is very rare), or as the default interrupt handler. So I suggest to check the following:
[ol]
[*]if it exists an enabled interrupt that has no ISR declare, by default (if you don\'t specify an ISR) the compiler fills the interrupt vector with the reset function;

[*]if a trap is raised and you don\'t declare the ISR for it, the reset function is called.
Note that a trap is a particular interrupt (with high priority) that occurs for \"dangerous\" system error (oscillator failure, address error, stack error, math error, DMA error). The address error is a memory access error, like the common c pointers usage mistakes.

[/ol]

If you want to verify that a trap takes place, use the following line in one (only one) of your source files:

Code: Select all

void _ISRFAST _OscillatorFail(void) 
{ 
        for(; ; ); 
}

void _ISRFAST _AddressError(void) 
{ 
        for(; ; ); 
}

void _ISRFAST _StackError(void) 
{ 
        for(; ; ); 
}


void _ISRFAST _MathError(void) 
{ 
        for(; ; ); 
}


void _ISRFAST _DMACError(void) 
{ 
        for(; ; ); 
}

If a trap occurs the debugger will stop in the relative ISR infinite for.
If you want to make further investigation upon the trap cause, you can then use a specific debugging code (maybe in assembly) instead of the infinite loop (I did once for the address error, ask me for more information).

I hope this will help.
Bye!

[paolo.gai]

Just in addition to what Christian said:
- ERIKA does not implement (yet) any deadline check
- ERIKA does not implement any reset logic

Everything related to reset is left to the application.

There will be soon another implementation that checks for deadlines (a prototype is ready now, but everything will be released by next March or next June).

Ciao,

PJ