CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Program resets in Release mode but not in Debug mode

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
lm_micro@shaw.ca



Joined: 25 Sep 2018
Posts: 9
Location: Canada

View user's profile Send private message AIM Address

Program resets in Release mode but not in Debug mode
PostPosted: Tue Sep 25, 2018 5:12 pm     Reply with quote

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



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Sep 25, 2018 10:17 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Sep 25, 2018 11:24 pm     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Sep 26, 2018 5:38 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Sep 26, 2018 6:56 am     Reply with quote

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.... Smile
lm_micro@shaw.ca



Joined: 25 Sep 2018
Posts: 9
Location: Canada

View user's profile Send private message AIM Address

PostPosted: Thu Sep 27, 2018 2:28 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Sep 28, 2018 12:52 am     Reply with quote

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:
Code:

#include <33FJ128MC804.h>
#build (stack=0x180)
.....


It's possible the default stack in debug mode is being set larger.
lm_micro@shaw.ca



Joined: 25 Sep 2018
Posts: 9
Location: Canada

View user's profile Send private message AIM Address

PostPosted: Fri Sep 28, 2018 10:58 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Sep 28, 2018 11:48 am     Reply with quote

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?.
lm_micro@shaw.ca



Joined: 25 Sep 2018
Posts: 9
Location: Canada

View user's profile Send private message AIM Address

PostPosted: Fri Sep 28, 2018 12:09 pm     Reply with quote

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
lm_micro@shaw.ca



Joined: 25 Sep 2018
Posts: 9
Location: Canada

View user's profile Send private message AIM Address

PostPosted: Fri Sep 28, 2018 12:25 pm     Reply with quote

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



Joined: 24 Jun 2004
Posts: 1899

View user's profile Send private message

PostPosted: Fri Sep 28, 2018 1:20 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Sep 28, 2018 1:31 pm     Reply with quote

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:

Code:

    char * ptr;
    char demo_array[]="Test message";
    int16 val;

    ptr=demo_array;
    ptr++; //because this is a char pointer it increments by 1
   
    val=*(int16 *)ptr;
    //this will give an address error trap.
lm_micro@shaw.ca



Joined: 25 Sep 2018
Posts: 9
Location: Canada

View user's profile Send private message AIM Address

PostPosted: Fri Sep 28, 2018 1:31 pm     Reply with quote

I moved the stack to;

#build ( 0x1800:0x1A00 )

and it cleared the problem.

Thanks for your help.
lm_micro@shaw.ca



Joined: 25 Sep 2018
Posts: 9
Location: Canada

View user's profile Send private message AIM Address

PostPosted: Fri Sep 28, 2018 1:37 pm     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group