Microcontroller reset reason

[electronicsman]

It is again a generic question more related to micro chip family of controllers. If a controller is restting can we narrowed to hardware or software by checking the MCLR pin. At the time of reset if there is no change on MCLR then surely because of software? Anything like that? Please advise.

 

[KlausST]

Hi,

most nowadays microcontrollers have flags that show you the reason of reset.

Klaus

 

[electronicsman]

Thank you for the reply. When I see the Reset Control register it shows two bits to be set BOR, POR. But Brown out Reset is disabled and Power on Reset i think we cannot disable it and I am not seeing any fluctuation on the MCLR pin. Can you please suggest how to debug the issue? The micro is dspic33ev family.

 

[KlausST]

Hi,

When I see the Reset Control register it shows two bits to be set BOR, POR.

How are these bits reset? By software or automatically by hardware?

Klaus

 

[electronicsman]

Hi,

How are these bits reset? By software or automatically by hardware?

Klaus

I am not doing in software it is done automatically by hardware.

 

[KlausST]

Hi,

it is done automatically by hardware.

I mean .... are you sure? Did you consult the datasheet?

Klaus

 

[FvM]

No, the reset reason bits are not automatically reset. You need to reset it after you have determined the previous reset reason.

 

[electronicsman]

I will explain the sequence more clearly
1. The code executes normally.
2. There is a parameter like current which can be varied externally.
3. Once the current reaches exactly a particular value it resets and when we observe the RCON register BOR and POR are set. The code executes after that.
4. If the current increases not sure if anything happens in hardware, software execution almost remains same.

 

[KlausST]

Hi,

I'm not familiar with your microcontroller.

You need to reset it after you have determined the previous reset reason.

This means you - with your software - need to clear thos buts after you read them.
Otherwise they may "survive" the next reset and show you wrong reset causes.
--> clear them.

If they still show BOR and POR, then it's definitely a microcontroller power supply problem.

Do you have
* a good PCB layout
* a solid GND plane, not split in pieces
* used decoupling capacitors at every VCC pin
* used decoupling capacitor at the RESET pin
* used a large enough bulk capacitor somewhere at VCC

For more detailed help, you need to provide more detailed informations:
*

2. There is a parameter like current which can be varied externally.

What does this mean? Is it low frequency current, or pulsed current, near the microcontroller, what magnitude?
* show us your schematic
* show us your PCB layout
* show us your code

Klaus

 

[FvM]

Otherwise they may "survive" the next reset and show you wrong reset causes.
--> clear them.

Yes, they do survive, by design.

- - - Updated - - -

I agree with your method to monitor RCON for the reset cause. As said, RCON must be cleared to get useful information about the next reset event.

Disabling BOR is possible, but probably not useful. If the supply voltage drops below the BOR threshold without resetting the processor, the behavior may be unpredictable. Detecting MCLR pulses, e.g. with an oscilloscope is also questionable. If you expect glitches at MCLR, you better place a capacitor to block it.

 

[Aussie Susan]

I will explain the sequence more clearly
3. Once the current reaches exactly a particular value it resets and when we observe the RCON register BOR and POR are set. The code executes after that.

To me that sounds like a software problem.
You don;t say specifically which dsPIC33EV MCU you are using (it would be useful to know) exactly but they are all fairly similar. You will see the hardware related reset cause in that register but you will not see the 'trap' resets as these are vectored through the IVT. For example if you are getting a 'math' error trap or an 'address' trap then these will be in the INTCON1 register.
It is best to set up an ISR for the common traps (stack overflow, address, math error, illegal instruction) and set a breakpoint in the ISRs. This will let you know exactly what the error was that was causing the reset and also where (roughly if it is in a library function) the error occurred.
Without these ISRs defined, the default action is to set the PC to 0x0000 which will cause the code to restart.
Susan

 

[jit_singh_tara]

To me that sounds like a software problem.
You don;t say specifically which dsPIC33EV MCU you are using (it would be useful to know) exactly but they are all fairly similar. You will see the hardware related reset cause in that register but you will not see the 'trap' resets as these are vectored through the IVT. For example if you are getting a 'math' error trap or an 'address' trap then these will be in the INTCON1 register.
It is best to set up an ISR for the common traps (stack overflow, address, math error, illegal instruction) and set a breakpoint in the ISRs. This will let you know exactly what the error was that was causing the reset and also where (roughly if it is in a library function) the error occurred.
Without these ISRs defined, the default action is to set the PC to 0x0000 which will cause the code to restart.
Susan

hi , Can you suggest how to write ISR for the common traps (stack overflow, address, math error, illegal instruction) . Need syntax for the same.

 

[jit_singh_tara]

Ok i have managed to enable the ISR for the traps . But that is working in debug mode ......How can we make use of it to identify which code statement is making problem in case of address trap.

 

[electronicsman]

I have not tried it myself but it is not very straight forward, you need to write some additional code / flags to actually find the reason. In the default interrupt write a while(1) statement so that it stays there in case of any invalid execution and then start back tracing.

 

[dick_freebird]

I have seen personal computers fail to boot because
the "POR" RC network's electrolytic capacitor became
too leaky for the pullup resistor to overcome.