Program resets in Release mode but not in Debug mode

[[email protected]]

Program resets when it reaches the same place when in Release Mode but not if the compile is done in Debug Mode & then programmed into the dsPIC.

[PCM programmer]

The fuses are different between Release and Debug mode. Look at the
end of the .LST file after compiling in each mode. Compare the fuses.
Look for differences.

For example, the Brownout fuse is disabled in Debug mode. Suppose
your program turns on a device with a high current drain, causing the
power supply to droop. This could cause a Brownout reset in Release
mode but not in Debug mode.

[Ttelmah]

Also the watchdog is disabled in debug mode. This too could result in a reset at a particular point in time after the boot, if it is on in the running code.

[temtronic]

I've got to be the ONLY person who doesn't use 'DEBUG' mode ! I even got Microchip to modify MPLAB so we could change the default (as it was 'debug' and code never worked for me....)

Jay

[Ttelmah]

Not the only one. I've got a couple of PIC24 boards, where there are no spare pins for ICD, so they have to be built in release mode from scratch. Does 'focus' the mind a little....

[[email protected]]

Thanks everyone for your help.

The .lst files for the Debug & Release Modes are are identical except for the DEBUG/NODEBUG entries.

I've checked all references to the WDT & they are either commented out or set to OFF.

The environment is;
MPLAB IDE v8.92,
CCS PICD C Compiler Version 5.079
dsPIC33FJ128MC804
PICkit3

ROM used: 23590 bytes (27%)
Largest free fragment is 41946
RAM used: 1384 (8%) at main() level
1599 (10%) worst case
Stack used: 82 locations (44 in main + 38 for interrupts)
Stack size: 128

This looks so much like a stack problem I've seen before but not with this compiler.

[Ttelmah]

So, build with a bigger stack.
128, is small. It'll run out doing simple prints at this level.
Typically 256, or more is needed.

So your main file should start like:

[[email protected]]

I tried the larger stack method you suggested, no joy!

Are you doing simple prints of the stack pointer?

I've used simple prints to identify the point it crashes consistently.

[Ttelmah]

In such a situation, I'd start by identifying the restart cause. For things like maths errors of address overflow errors, I'd create an interrupt handler for these , and extract the address from the stack, in this handler. Then I'd look at the instruction in front of the failure point to see what is triggering it. The same can be done for a stack overflow.
I must admit given that expanding the stack didn't fix the problem, I'd be suspicious that some difference between yuor debug and release environment is triggering the problem. How is MCLR wired for instance?. The debugger pulls this up.
Are you sure you are building the code for release, not DEBUG (remember MPLAB defaults to selecting debug, unless you specify a release build).
On some PIC's the DEBUG build does change the I/O pin programming to digital, while on the release this has to be explicitly done.
Also the debugger does provide a ground connection. Are you sure the board is correctly powered and has a good ground to the circuitry it is driving?.

[[email protected]]

I've been doing PIC designs for years, pretty much the same ICSP design always. Never share the data, clock, & MCLR with other peripherals. 4.7K on the MCLR & 0.1uF cap at the ICSP connector, very short runs. I doubt it's hardware.

I have a 30Mhz crystal, Gyro/Acell & CAN on the board with 14 debounced PB inputs.

Fairly simple hardware. Good LDO power supplies, well bypassed, big traces.

I do have an RS232 port available. It would be a big help to get the location where stack pointer & interrupt are.

Thanks

[[email protected]]

I've found 'restart_cause' & I have a TRAP_CONFLICT?

[newguy]

Sounds like you're using a 16 bit device? Trying to access an odd address will create an address conflict trap (I think). Do you declare or use an array? I once got that error with a larger struct, and the struct had an array as a member. I seem to remember getting that reset/trap when the compiler tried to access a certain element of the array - I think the math on the address was wrong.

If you are using a 16 bit device, it should have interrupt handlers for various traps. Look at the header file and near the bottom all interrupt sources will be listed. Create a handler for the trap and within it print out whatever you can to whatever port(s) you have available. Even flashing an LED in trial & error fashion will eventually help you narrow in on the cause.

Edit: a stack overflow will also cause this. Increase your stack again - try 512 or even 1024 or higher.

[Ttelmah]

Yes. If you use a pointer that is designed to access an 8bit value and goes to an odd data boundary to access a 16 bit value, you will get an address error trap. So:

[[email protected]]

I moved the stack to;

#build ( 0x1800:0x1A00 )

and it cleared the problem.

Thanks for your help.

[[email protected]]

I see what you're saying about the byte boundaries. I inherited this code, the author has done some strange array pointers. Also I ported it from his PIC18 to the dsPIC33. Since then I've had to check all variables for correctness.

Thanks again.