[SOLVED] MCU behaves as if Reset occured while reading ADC.

I am doing a project with PIC18F45K22. All the registers are configured properly. I am testing the project in both Proteus and EasyPIC7. I see a strange problem. When the code inside while(1) executes all the status LEDs, PUMP relay etc... turn as expected but after the while(1) is exected successively then the first statement in while(1) loop which is ADC_Read(x) instruction makes all LEDs and PUMP to turn OFF. What might be the problem ? The ststud LEDs and PUMP if ON has to remain in that state but due to this it blinks once everytime the ADC is read.

Do you have the watchdog timer enabled? Possibly while waiting in the loop for the ADC to return it's value you are allowing the watchdog to time out and cause a soft reset.

Brian.

Thanks for replying betwixt.

Here are somethings which I tested.

I am using PIC16F45K22 at 4 MHz external oscillator. OSC configured as XT in mikroC project. I am attaching a test project which shows the exact problem.

What I did...

I tested both in Proteus and hardware (EasyPIC7) The result are same.

After much debugging I found out that if Timer1 interrupt is enabled then processor resets. I confirm that WDT is not resetting the processor. I even cleared the WDT in ISR (knowing that it is not a good way) which interrupts every 0.5 sec but the problem continued.

If I comment out the InitTimer1() or the TMR1IE_bit = 1; code and then Compile and test then the problem doesn't appear and the system works fine.

If Timer1 interrupt is enabled then Proteus showed that Stack overflow is resetting the processor and so in mikroC Project>Edit Project... menu I set "Stack overflow resets mcu = Disabled" and compiled the code but the problem remained in both Proteus and hardware.

Then I enabled Timer interrupt and compiled the code and saw that the processor resets indefinitely in Proteus but in hardware the processor resets 25 to 65 times depending upon the WDTPS values and then the system functions normally. To test this I have turned ON all LEDs on PORTD and I am blinking RC0 LED in while(1) loop.

The mcu resets 25 to 65 times which can be seen by the blinking of PORTD and RC0 LEDs. After mcu resets 25 to 65 times the system functions normally without any problem. I confirm this because after the processor stops the resetting, PORTD LEDs will be on as coded and RC0 LED blinks at a frequency of 0.5 sec again as coded.

Now I want to know whether Timer1 Interrupt or stack overflow or both are causing the mcu reset.

If Timer1 interrupt or stack overflow is causing the reset then why the ssystem becomes normal after mcu resets 25 to 65 times ?

If stack overflow is causing the mcu reset then why even after I set "stack overflow will cause mcu reset = Disabled" the mcu reset 25 to 65 times and system became normal ?

If there is anything other than Timer1 interrupt or stack overflow which is causing the reset, then what is that.

In Proteus the system doesn't become stable but in hardware the system functions normally after mcu resets 25 to 65 times.

I also tested using 18F46K22 but the same problem remains.

I commented out InitTimer1() function call which enables the timer1 interrupt and also CLR_WDT() which is inside while(1) loop and tested in hardware using different values for WDTPS. For 1:2048 WDTPS value the processor reset every nine seconds and hence I used WDTPS of 1:4096 to make sure WDT doesn't rest the mcu. Then I uncommented CLR_WDT() and InitTimer1() functions and saw that mcu resets 25 to 65 times and LEDs om PORTD blinks with a frequency of 1 sec which is the delay used in the Port_Init() function. After resetting 25 to 65 times the PORTD fully turns on and RC0 LED blinks at a freq of 0.5 sec indication normal functioning of the system.

mikroC project and Proteus file attached. Have to test in hardware to see that mcu resetting stops after resetting 25 to 65 times and then system functions normally.


Please help me with this problem. I have tested my project and it works fine after the mcu stops resetting and hence my project is pending for completion due to this resetting problem. If this problem solves then my project will be complete.

Edit:

Is it because the code inside ISR is lengthy the mcu is resetting ? If yes, then why mcu resetting stops after mcu resets 25 to 65 times ? Why mcu resets even if "stack overflow will reset mcu" is disabled ? :bang: :bang: :bang: :bang:

Using LATx instead of PORTx for outputs didn't made any difference. The problem remains.

- - - Updated - - -

Now I feel it is a bug of mikroC PRO PIC 6.4.0. I wrote the same code in MPLAB X IDE + XC8 Compiler and it worked fine. There is no changes in the code. I am attaching the XC8 project. It worked fine in Proteus and also hardware (EasyPIC7).

XC8 project compiled in PRO mode.

Here is a new version of the test project written in mikroC. Now the system is behaving in a different way. After the system is started none of the LEDs light up but after 10 seconds the LEDs light up and system functions normally.

I don't see anything strange in the asm code generated by mikroC COmpiler.

- - - Updated - - -

Edit:

Finally the problem was solved. The compiler was corrupted and was generating wrong .hex files. Re-installed the Compiler and Compiled and the project worked fine.