dsPIC33CK256MP508 strange reset

[Wimax]

Hello 

I am using the dspic33ck256mp508 on a custom board. I don't understand why, on start-up, a large part of the programme runs, but at a certain point it restarts and works correctly from then on without problems. If it were a coding error, it should always crash, It actually works after the second restart.

[diebobo]

Wimax, are u able to post full code ?

[Wimax]

It's a very long code, I've tried to intercept the error using "Traps.inc", but I'm not getting any messages. I suspect it's a DMA or SPI conflict; I'm using two channels to manage the two dedicated ADCs and a third channel to manage the hardware SPI in framed mode.
The ADCs receive their trigger from the SCCP module; the end of conversion on the second ADC generates the trigger for the third DMA channel to write to the SPI. It's really annoying to see the reset, even though everything works flawlessly on the second reboot; I'd like to avoid it.

[Stephen Moss]

I don't understand why, on start-up, a large part of the programme runs, but at a certain point it restarts and works correctly from then on without problems. If it were a coding error, it should always crash, It actually works after the second restart.

That is odd, as you say if it were a code issue or the result of a variable over flowing you would expect it to be reasonably consistent.
 

I suspect it's a DMA or SPI conflict; I'm using two channels to manage the two dedicated ADCs and a third channel to manage the hardware SPI in framed mode.

Again, if that were the case would it not also be reasonable consistent as your code is accessing them at the same points.

The following possibilities come to mind...

Watchdog Timeout:
If you have the watchdog timer enabled and a long set up script, it is possible that by the time your setup get around to to changing the default WDT settings to make the WDT timeout longer that the Watchdog timer had already accumulated enough ticks that it resets before you are able to clear the WDT in your main code loop, particularly if it is a long loop and you are only clearing the WDT at the end of the loop.
The reason it only appears to happen once and then is Ok after that would be because your setup script was able to increase the WDT timeout before the first reset, so now the timeout period is long enough that is no longer triggers WDT reset before the WDT is cleared in you main loop. So either try moving the WDT setting changes to the beginning of your setup script so that the timeout period become too long to trigger a reset before the WDT is cleared in your main code loop and/or try clearing the WDT timer at the beginning of your main loop to clear the ticks accumulated during the long setup script and prevent the reset.

Unstable power source:
Alternativity, if it happens shortly after power on, perhaps the power source is not immediately stable and so either it drops far enough that when it recovers the PIC acts as though it has lost then regained power, or it has dropped low enough to trigger a brown out reset if you have the have BOR set.
One way to test for that that may be to disable the BOR if you have it set, if doing that resolves the problem that would suggest that the BOR reset is being triggered and so you may need to look at stabilising the power source.

[trastikata]

Wimax,

you can check RCON register after restart to verify if it is a true PC reset or it is coding error.

If it is PC reset, could you let us know what the RCON register indicates.

Regards