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

pic24fj512gb606 not resetting on cpu_reset() and wdt reset

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Emmo



Joined: 02 Feb 2017
Posts: 14

View user's profile Send private message

pic24fj512gb606 not resetting on cpu_reset() and wdt reset
PostPosted: Thu Jul 13, 2017 8:14 am     Reply with quote

Hello guys,

I once more need your help :-( I'm working with a pic24fj512gb606 and ccs compiler v5.073. I made a very very very simple program after I figure out, my pic is not resetting when I call reset_cpu(). Same behavior when watchdog is hitting. It seems, the device stays in an unknown state. Nothing is working anymore. I already checked the forum about same issues. I found out, that debug mode can be the problem. So I add #fuses nodebug and removed #device icd=3. My project is set in release and not debug, too. But the problem is still there. Here is my code:

Code:

#include <24FJ512GB606.h>

#device ADC=12              //return 12bit adc value
//#device icd=3               //uses PGC3/PGD3 pins

//#FUSES BROWNOUT_NOSL        //brownout reset
#FUSES NOIESO               //Internal External Switch Over mode disabled
#FUSES NOWDT
#FUSES NODEBUG
//#FUSES WDT_SW               //No Watch Dog Timer, enabled in Software
//#FUSES WPOSTS12             //Watchdog postscaler 2,048 sec
//#FUSES WDTCLK_SYS           //WDT uses system clock as clock source
//#FUSES PROTECT              //turn on code protect - blocks reading of the MCU program
//#FUSES SOSC_SEL             //SOSC circuit selected
#FUSES SOSC_DIG             //Digital mode, I/O port functionality of SOSCI and SOSCO pins
#FUSES NOCKSNOFSM           //Clock Switching is disabled, fail Safe clock monitor is disabled
#FUSES NOBSS                //No boot segment
#FUSES NOWRT                //Program memory not write protected
//#FUSES WINDIS               //Watch Dog Timer in non-Window mode
#FUSES NOJTAG               //JTAG disabled
//#FUSES FRC_PLL              //Internal Fast RC oscillator with PLL
//#FUSES LVR                //Low Voltage Regulator Enabled, Controlled in Software
#FUSES NOBTSWP              //BOOTSWP Instruction Disabled
#FUSES NOIOL1WAY            //Allows multiple reconfigurations of peripheral pins

#use delay(internal=32MHz,restart_wdt)  //run at 32MHz
//#use delay(internal=32MHz,USB_FULL,restart_wdt,ACT=USB)

#include <usb_cdc.h>

//#zero_ram
void main(void)
{
    delay_ms(72);
    output_high(PIN_E0);
    delay_ms(2000);
    output_low(PIN_E0);
    delay_ms(2000);
    while(1)
    {
        reset_cpu();
        /*#asm
        RESET
        #endasm*/
        output_high(PIN_E0);
    }
}

I connected a LED to pin E0 and look if it is flashing. With the code above it is on for 2sec and then go out forever. Only a power reset helps. The funny thing is, when I'm using this: #use delay(internal=32MHz,USB_FULL,restart_wdt,ACT=USB), the device is resetting as it should do and the LED is blinking. I dont know why I have to use usb for a proper reset. And when I set #use delay(internal=8MHz,restart_wdt) it is working, too. Make no sense to me. What is wrong? If someone got an idea, let me know please! Thanks!
Ttelmah



Joined: 11 Mar 2010
Posts: 19436

View user's profile Send private message

PostPosted: Thu Jul 13, 2017 9:04 am     Reply with quote

Though this shouldn't apply:
Code:

7. Module: Reset
If a lower priority address error trap occurs while
a higher priority oscillator failure trap is being
processed, the TRAPR bit (RCON<15>) is not
set. A Trap Conflict Reset does not occur as
expected and the device may stop executing
code.
Work around
None. However, a MCLR/POR Reset will
recover the device.


Is interesting, since it talks about the chip getting into a state where it stops executing code.

What environment are you using to compile this from?. If MPLAB, remember you need to re-compile in release mode, and setup the programming device as a 'programmer', not as a 'debugger'. If you program with the device set as a debugger, it tends to switch back to debug...
Emmo



Joined: 02 Feb 2017
Posts: 14

View user's profile Send private message

PostPosted: Fri Jul 14, 2017 12:37 am     Reply with quote

Ttelmah wrote:
Though this shouldn't apply:
Code:

7. Module: Reset
If a lower priority address error trap occurs while
a higher priority oscillator failure trap is being
processed, the TRAPR bit (RCON<15>) is not
set. A Trap Conflict Reset does not occur as
expected and the device may stop executing
code.
Work around
None. However, a MCLR/POR Reset will
recover the device.


Is interesting, since it talks about the chip getting into a state where it stops executing code.

What environment are you using to compile this from?. If MPLAB, remember you need to re-compile in release mode, and setup the programming device as a 'programmer', not as a 'debugger'. If you program with the device set as a debugger, it tends to switch back to debug...


I tested MCLR Reset and it is not recovering the device. I pull MCLR Pin to GND and nothing happened. Only power reset is recovering.

I'm using MPLAB X v3.65. I have CCS IDE v5.07, too. Tested with both and no one is working.
Ttelmah



Joined: 11 Mar 2010
Posts: 19436

View user's profile Send private message

PostPosted: Fri Jul 14, 2017 5:06 am     Reply with quote

Check MCLR is enabled. It may be defaulting to off.

The only thing that requires a power down and MCLR can't recover from is a FET getting into the locked state by an ESD event.
Ben1172



Joined: 22 Aug 2017
Posts: 7

View user's profile Send private message

PostPosted: Thu Aug 24, 2017 10:19 am     Reply with quote

This is an old thread, but for others info, I too had this problem

It seems some 24FJ pic have a problem clock switching in software to PLL enabled internal osc.

But setting up the oscillator using configuration bits can solves this.

After your delay statement add #FUSE FRC_PLL
This overrides the CCS code to configure the oscillator thru software.

CCS tech support mentioned they will put an exception in their next build (5.075?) for this family to not configure the oscillator thru software, so this issue should go away soon.
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