PIC24 cm reset error

[jit_singh_tara]

Dear Friends ,

I am trying to convert a code from PIC18 TO PIC24(PIC24FGA1024GA610).....i AM facing Configuration Word Mismatch reset issue when reading on POWER ON the " RCON " rEGISTER.

I want to know what could be the reason . One more observation .:
If i mask a certain code region there is no reset .If i unmask it there is continuous resettng of the mcu .With the RCON REGISTER reading 768.i.e 0b00000011 00000000. So i am getting 2 bits high on RCON register.) --------> VREGS and CM.

How to resolve this.....

 

[Aussie Susan]

Show us your code and the CONFIG settings.
What do you mean by 'masking' a certain region of code?
Susan

 

[FvM]

There's no PIC24FGA1024GA610, you are talking about PIC24FJ1024GA610? VREGS bit doesn't reflect a reset reason.

Did you review the explanation of CM Reset in data sheet?

11.4.4.2 Continuous State Monitoring
In addition to being protected from direct writes, the contents of the RPINRx and RPORx registers are constantly monitored in hardware by shadow registers. If an unexpected change in any of the registers occurs (such as cell disturbances caused by ESD or other external events), a Configuration Mismatch Reset will be triggered.

 

[jit_singh_tara]

Hi friends ,

Getting TRAP CONFLICT ERROR on reading RCON .I want to know how to resolve this .PLease share trap service routine for oscillator fail, address trap , stack error trap , math error trap etc.

Please share routine for mikroc pro compiler for dspic/pic24.

- - - Updated - - -

Show us your code and the CONFIG settings.
What do you mean by 'masking' a certain region of code?
Susan

By masking i mean that if a comment certain region of code the resetting stops.....but upon enabling it the reset starts to occur....

 

[FvM]

It's rarely meaningful to handle these traps in final code, because they should never happen. At best, you may want to record the PC from it's triggered and possibly output it in console output, if present in your design. It's however reasonable to define dummy handlers to avoid the trap conflict error (unhandled exception) and set debugger breakpoint on it.

Reading RCON itself can't cause trap conflict or an exception. How are you debugging your code? MPLAB debugger?

 

[jit_singh_tara]

It's rarely meaningful to handle these traps in final code, because they should never happen. At best, you may want to record the PC from it's triggered and possibly output it in console output, if present in your design. It's however reasonable to define dummy handlers to avoid the trap conflict error (unhandled exception) and set debugger breakpoint on it.

Reading RCON itself can't cause trap conflict or an exception. How are you debugging your code? MPLAB debugger?

I am using mikroc pro compiler for dspic/pic24.So far i am reading RCON register on Power on reset.I have enabled RCON read on power on and show on LCD .so IT READS 32768 whenever mcu resets because of the trap conflict.

I need trap handler routine for the same compiler so that i can use mikroprog ICD to see what is happening in the case of trap . Any example for trap handler would be of grt help.I tried with following routine in the debugging mode but the problem doesnt come in debugging mode. (3 breakpoints are available.).


MCU resetting in release mode , MCU not entering any handler so far in DEBUGGING MODE and it is not resetting in debug mode.
Is there something wrong with the syntax of trap handler .please suggest.

----------------------------TRAP HANDLER ROUTINES----------------------------------------------------


void OscillatorFailTrap() 
{ // if oscillator fails, the code jumps here
  INTCON1bits.OSCFAIL = 0; //Clear the trap flag
  portb.f7 = 1;     //LED ON INDICATION               // BREAKPOINT1  APPLIED AT THIS POINT
  while(1);
}

void AddressTrap() 
{  // if the addressing mode is wrong, the code jumps here
  INTCON1bits.ADDRERR = 0; //Clear the trap flag
  portb.f7 = 1;     //LED ON INDICATION                // BREAKPOINT2 APPLIED AT THIS POINT
  while(1);
}

void StackErrorTrap() 
{ // stack overflow, underflow...
 INTCON1bits.STKERR = 0; //Clear the trap flag
 portb.f7 = 1;     //LED ON INDICATION                // BREAKPOINT3 APPLIED AT THIS POINT
 while(1);
}


void MathErrorTrap() 
{ // div by zero etc...
  INTCON1bits.MATHERR = 0; //Clear the trap flag
  portb.f7 = 1;     //LED ON INDICATION
  while(1);
}

 

[jit_singh_tara]

hi i wENT THROUGH RCON STATUS , and found that RCON.F15 is the real cause of the reset. Though i am getting RCON.F0 = 1,RCON.F1 = 1 also on POR. But since i WAS MAKING RCON = 0 after reading it on POR so it was not displaying these bits.

In a nutshell reset occurs because of trap only , RCON.F15 bit comes to be high always on EVERY TRAP CONFLICT RESET .

 

[jit_singh_tara]

SO i am able to see which trap is happening using ISR in the debugging mode . Now do i have to run the program step by step to see on which statement it is happening and then change it .

Please clarify that if i have managed to find out the trap cause say address trap using debugging mode.Now how do i correct this trap issue in release mode or normal running mode of mcu.


There is a change in the trap handing routines syntax.....sharing :

//---------------------------------------------------------------------------------------------
//---------------------mikroc pro for dspic/pic24 compiler---------------------------------
//---------------------------------------------------------------------------------------------



void OscillatorFailTrap() iv 0x06
{ // if oscillator fails, the code jumps here
  INTCON1bits.OSCFAIL = 0;                        //Clear the trap flag
  //portb.f7 = 1;
  //while(1);
}

void AddressTrap() iv 0x08
{  // if the addressing mode is wrong, the code jumps here
  INTCON1bits.ADDRERR = 0;                    //Clear the trap flag
  //portb.f7 = 1;  
  //while(1);
}

void StackErrorTrap() iv 0x0A
{ // stack overflow, underflow...
 INTCON1bits.STKERR = 0;                       //Clear the trap flag
 //portb.f7 = 1;
 //while(1);
}


void MathErrorTrap() iv 0x0C
{ // div by zero etc...
  INTCON1bits.MATHERR = 0;                   //Clear the trap flag
  //portb.f7 = 1;
  //while(1);
}

- - - Updated - - -

It's rarely meaningful to handle these traps in final code, because they should never happen. At best, you may want to record the PC from it's triggered and possibly output it in console output, if present in your design. It's however reasonable to define dummy handlers to avoid the trap conflict error (unhandled exception) and set debugger breakpoint on it.

Reading RCON itself can't cause trap conflict or an exception. How are you debugging your code? MPLAB debugger?

SO i am able to see which trap is happening using ISR in the debugging mode . Now do i have to run the program step by step to see on which statement it is happening and then change it .

Please clarify that if i have managed to find out the trap cause say address trap using debugging mode.Now how do i correct this trap issue in release mode or normal running mode of mcu.

 

[Aussie Susan]

IF you look at the datasheet, you will see the information that is stored on the stack when a trap is triggered. If you look at the saved PC value, it will tell you the instruction that immediately follows the one that caused the trap (remember that the PC is incremented when fetching the instruction).
You can then look at your linker map to see which routine was running when the trap was called.
You also need to look at the other registers if you are getting address traps and you could be using indirect addressing.
If the trap always occurs, then set a breakpoint in the function that is causing the problem and just step through that. If the function is sometimes running correctly and other times failing (which probably indicates that a parameter or other global value is the root cause) then it can be a bit harder but again, set the breakpoint, let the program continue and count how many times you let it continue before the failure - then reset and do the same but step through the last time through the function.
I suspect that you are taking a simplistic approach to interpreting the RCON and related registers. You must read the data sheet and the "Interrupts" FRM (Family Reference Manual) documents. It is not unusual for the POR and BOR bits to be set following a reset and this is discussed in the documentation.
You say that RCON bit TRAPR is being set - then you need to look at the INTCON1 register to see which trap triggered the reset (that you were not intercepting). When you know which one to look at, then you can intercept the trap (and per the code you show above) and use the technique I've described above to find the problem.
Also, you seem to be getting wound up about debug and release mode. The problem is in your code that is executing in both modes and so you need to use debug mode to find and fix the problem - then, as FvM has said - you can use release mode without worrying about it.
Susan