Positron BASIC Community

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.

Wimax, are u able to post full code ?

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.

Quote from: Wimax on Jun 29, 2026, 08:43 PMI 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.
 

Quote from: Wimax on Jun 29, 2026, 10:46 PMI 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.

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

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...

Quote from: Wimax on Jun 29, 2026, 08:43 PMIf 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?

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

Quote from: RGV250 on Today at 06:28 AMHi,
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.

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.

Quote from: Wimax on Today at 03:21 PMThe 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?