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

[Wimax]

Hi Trastikata,

I see this 000000010000011 in RCON in the first (main) start and this 000000000000000 in the second event.
I think that the first indicates an hardware reset just after the mcu programming phase, the second event doesn't seem an hardware reset.
It's really a nightmare...

[trastikata]

If it were a coding error, it should always crash, It actually works after the second restart.

Wimax,

Obviously there is no MCU reset judging by the RCON register. A coding error is not necessary to always crash, depends on code and variable handling.

Looks like the PC jumps to start position for some reason, without posting some code, it would be hard to guess anything.

you said "after the mcu programming phase" - is there a Bootloader involved?

[RGV250]

Hi,
Would it help to put some debug serial outputs in strategic places and possibly a loop counter.
This might narrow it down to where you could put more debug in.

Regards,
Bob

[trastikata]

Hi,
Would it help to put some debug serial outputs in strategic places and possibly a loop counter.
This might narrow it down to where you could put more debug in.

Bob,

for tracking glitches in code I usually use a LED. Simply add a line "High LED" and it is immediately clear if the line has been reached.

@Wimax

Add a "Low LED : DelayMs 1000" at the beginning of your code to distinguish a reset and then move down the code that line "High LED" until you find where exactly the PC resets.

[Wimax]

Hello,

First of all, thanks for all the advice.
The reboot occurs when I start the SCCP module to generate the trigger signal for the ADCs (Dual Edge Compare PWM, the only mode that seems suitable for this purpose). I thought it was a DMA issue, but even when I disable all channels, the problem persists.

[trastikata]

The reboot occurs when I start the SCCP module to generate the trigger signal for the ADCs (Dual Edge Compare PWM, the only mode that seems suitable for this purpose). I thought it was a DMA issue, but even when I disable all channels, the problem persists.

Wimax,

the PTG is not suitable for your case?

[Wimax]

Hi Trastikata,

Yes, I could probably use the module, but I can't understand why I'm getting this behaviour when using the SCCP module as a timer/trigger source.
I think I've tried almost everything without success; I've ruled out a compiler bug from the outset.
However, the restart does not have the same effects as an hardware reset – the RAM is not cleared. In the end, I solved the issue by inserting these lines before the call to the procedure that sets the internal clock to 200 MHz:

Code Select Expand

If RCON.7=0  Then

   GoTo Recover

EndIf

RCON=0
When the MCU restarts it jumps to:

Code Select Expand

Recover:

IFS1bits_DMA1IF = 0
IFS1bits_DMA2IF = 0
IFS0bits_DMA3IF = 0 

IFS5bits_ADCAN0IF=0
IFS5bits_ADCAN1IF=0

DMACH1bits_CHEN=1
DMACH2bits_CHEN=1
DMACH3bits_CHEN=1

INTCON2bits_GIE = 1

DelayCS 200

Timer3_Start()
While CCP2CON1Lbits_CCPON = 1 : Wend
just before "Timer3_Start()" that sets CCP2CON1Lbits_CCPON = 1 (this "resets" the CPU the first time). 
The reset is a jump to zero as RAM is preserved and the same is true for all other settings so the code is executed without problems at the second start.
The CCP2 module is stopped when DMA1 transfer is over:

Code Select Expand

Isr DMA1Interrupt 

Timer3_Stop()

IFS0bits_DMA1IF=0

EndIsr   


Honestly speaking I don't like this solution very much, but it seems to be effective.

[trastikata]

Without seeing the full code I could only guess. Is it possible you have an interrupt enabled without the corresponding interrupt handling procedure?

Anyway it is good you found a solution.