PIC reset and RCON register

[Diver300]

I'm using a pic24FJ64GA004, and something is causing it to reset.

I found that the PIC has a register called RCON, which is supposed to have bits set according to what caused the reset. I've got the PIC to output the value of RCON on a debug port, but the value never changes when a reset occurs. RCON seems to start at 0x0003 as expected, but there are no changes after that.

Has anyone used that register, and is there anything that I am doing wrong?

 

[nsaspook]

Are you sure it's a hardware 'reset'? Improper program execution might look like a hardware reset. Try clearing the RCON bits at powerup boot to see if BOR and POR are set again because of the program 'reset'.

 

[Diver300]

If I clear RCON after outputting, it stays a zero on the next reset. I've put a illegal op-code in, or a "reset" command, and RCON stays at 0.

 

[granddad]

Have you got watchdog timer enabled ?

 

[Diver300]

I have got the watchdog timer enabled.

I don't think that a watchdog reset is happening, but I am trying to use RCON to narrow down what is causing the reset.

 

[granddad]

Hi Diver ... Daft Q .. are you reseting the WD Timer in your code. ?

 

[Diver300]

I am resetting the watchdog timer.

The questions I posted wasn't "Why is my code resetting?", it was "How can I used RCON to find out why my code is resetting?"

The earlier versions, on slightly different boards, have run for literally years without resetting. I'm not sure if this is a layout problem, or some code problem and I am trying to track it down, and I thought that the RCON register would tell me what had last caused a reset, but I can't find how to use it.

 

[granddad]

Got it ... I had a bit of a scratch head with random reset RCON didnt change, I used a trap routine to break then RCON was valid.... I think ? some time ago will look at code.....

Yes it was a address error with UART RX

 

[Diver300]

Can you explain a bit more? I'm not familiar with C. My code is in assembler.

I'm not using interrupts at all, and as far as I can see, that code traps interrupts that have no other handler for them.

I expected RCON to be valid when the code started, and I have debug routine that outputs it near the start of code, but it always seems to be 0x0003 on power up or 0x0000 if I have cleared it previously.

 

[granddad]

Diver ( PIC24 assembler ... wow) If my memory correct , I had serial UART PIC24 RX routine that polled the buffer flag for input, the bytes were taken from RXREG and placed into a FIFO array , but i kept getting resets ,( RCON no flags) that's when I added trap.c , this halts code in the ISR ( while(1)") so in debug I found out it was address error , stack then pointed to the Serial code, ( I understand this error as a 8bit to 16bit alignment address error ). I rewrote the serial routine with a serial RX interrupt instead of poll , sorted ! I was assembler geek with PIC16, but bit the bullet and pursued the mighty C whith PIC24, ( missed out PIC18 ). My C no where near "professional" as I come from a 30 year HW background, You can teach an old dog new tricks..

 

[NorthGuy]

Go to Microchip web site and read errata document for your device. As I recall, many devices had problems with RCON. Yours may be one of them. It shouldn't really be 0 after any reset. So, if it's zero then either this is a bug or there were no reset at all.

You can produce MCLR reset by shorting MCLR to the ground. If you still get 0 after that, than there's some sort of problem with RCON. If not, look if you ever get a true reset.

Typically, you would read RCON at the beginning, then clear it. Otherwise it's useless. If you have any init or crt libraries (such as initializing RAM sections), they may do it for you.

 

[Diver300]

I've just found out that I was outputting the value of RCON incorrectly, so that I was only getting the last 4 bits correctly. Once I fixed that, I was able to get the correct RCON values for a hardware reset, a power reset, a software reset and a reset for illegal commands.

I did check the errata and I couldn't find anything.

The results that I got, even with the bug in the code, could be useful, as the value of 0003 correspond to a power reset, with or without the bug. It looks like my power supply isn't working correctly, or the regulator is getting disabled somehow.

 

[granddad]

Diver , Brown out ? EE's need lots of patience...

 

[NorthGuy]

The results that I got, even with the bug in the code, could be useful, as the value of 0003 correspond to a power reset, with or without the bug. It looks like my power supply isn't working correctly, or the regulator is getting disabled somehow.

Previously (post #9) you said that you get zero if you clear it. This wouldn't be the case if there was a POR. You should make sure you clear RCON before your reset happens. When PIC resets it adds bits to RCON (turns them on), but never clears RCON bits except for POR. Another way to test if you really get PORs is to set a bit in RCON and then see if it gets cleared after reset. If it stays, you didn't have POR.

 

[Diver300]

The code outputs RCON and then clears it, so that the next reset will set the appropriate bits of RCON. The mistake in my code stopped me seeing anything except the last 4 bits of RCON, so when I tested the code, most of the reset types showed as 0x0000. The POR showed up as 0x0003, as the POR bits are in the last 4 bits.

The inadvertent POR resets also showed the up as 0x0003 so I think that the resets are the processor somehow loosing power.

I'm going to run some more logging.

 

[NorthGuy]

If you have any coils, relays, inductors, or heavy loads sitting on the same ground, then when these things operate, ground may go up enough to reset PIC.