Jump to content

More On 12f683 Interrupt - Timer - Delay Problem


Recommended Posts

post-505-1262372996_thumb.png

 

Thanks to everybody who replied to my last post on this situation. I think I now know how to avoid the problem, but it's still kind of interesting.

 

It appears as if manipulation of port gpio.4 by main( ) has an effect on the gpio.0 which is driven from the interrupt.

 

The .jpg scope image attachment shows the outputs of gpio.4 (bottom), which is driven by main( ), and the output of gpio.0 which is driven by the interrupt. Note that gpio.0 gets clobbered whenever main is driving gpio.4, but the timing seems to remain OK when things come back to 'normal' and main ( ) is running the math exercise.

 

Here's the exerciser code:

 

 </P> <P>#include "system.h"
#include <stdlib.h>
#pragma DATA _CONFIG, _FCMEN_OFF&_IESO_OFF&_MCLRE_OFF&_WDT_OFF&_INTOSCIO 
#pragma CLOCK_FREQ  4000000 //processor is 12F683 using internal oscillator</P> <P>
int xseconds = 0;
unsigned char tick;
unsigned char tick1;</P> <P>void interrupt( void )
{
  tmr0 +=9;	
  tick++;	   
  if(tick>19)   
  {
 tick=0;
 tick1++;	  
 if(tick1>49)	   //every 500 ms 
 {
  gpio.0 = xseconds.0; //flash LED 
  tick1=0;		  //reset tick1.
  xseconds++;
 }
  }
intcon.2=0;	   //clear TMR0 overflow flag
} </P> <P>//main program starts here
void main(void)
{
intcon	=  0b10101000;
option_reg = 0b10000000;
wdtcon =  0x00;   // Watchdog not used
osccon =  0b01100000;  // Select internal oscillator at 4MHz
osctune = 0x00;   // Set frequency to factory tuned settings
wdtcon =  0x00;   // Watchdog not used
 ansel =   0x00;
trisio =  0b00000000; 

int i = 0, x = 0;   </P> <P>	while(1)
{								
  for(i=0;i<=8;i++)  // Math Exercise 
	{
  x= x+10;
  delay_ms(250);
  x = x - 9;
  delay_ms(250);
  if(x > 250)
x = 0;
	}
	for(i=0;i<=8;i++) // gpio.4 port exercise
	{
  gpio.4 = 1; 
  delay_ms(250);
  gpio.4 = 0;
  delay_ms(250);		
	}
}
}</P> <P>

 

I know that the code isn't optimal, but it does demonstrate the situation. I'm not a C expert so go easy on my coding. I'm just an old retired guy doing stuff I enjoy......but I did read the C book (....a long time ago).

 

Since I am using delays in both the math exercise section as well as when I am driving gpio.4, it appears as if the delays are not causing a problem. Somehow, driving gpio.4 bleeds over and messes up gpio.0, but does not impact the timing of the interrupt drive clock. Hardware issue????

 

It does,however, make sense not to use delays when using interrupts since the execution of the interrupt does make the delay even less accurate. I supect for not critical stuff it would be OK if one assumes the inherent inaccuracies.

 

Thanks to Shri for pointing out that I did not have timer0 enabled and some of the comments about read before write were well taken. The R/W issue is a topic that I tend to avoid because it hurts my head to think just about it --- plus I have tooth marks all over me from being bitten by it before.

 

Happy New Year all.

 

Rye

Link to post
Share on other sites

and the answer is...............

cmcon0

I neglected to set cmcon0 <0:2> to make all of the ports into digital i/o ports. It appears as if the chip thought that the comparators were active and that was messing things up.

 

Adding: cmcon0 = 0b00000111; fixed the problem.

 

And yes, the manual clearly points it all out in section 4.1........................................

 

Live and learn

 

Rye

post-505-1262382475_thumb.jpg

Link to post
Share on other sites

Its still worth adding the buffer variable workaround to your code as if the two RMW operations happen too close together or there is too much load on the pin, you can get erratic operation. With an ISR doing bit output, its certain to occasionally **** it up and if you aren't aware of the problem you can go crazy trying to figure out what's going wrong, suspecting all sorts of incorrect causes. Doing bit output on a port is only safe if there is only ONE output line as inputs aren't affected. We've all used a bit operation direct to a port to light a LED for debugging, but it is a really bad idea to leave it in the finished code.

 

Its a design 'feature' of the PIC10, PIC12 and PIC16 series. Basically, when you write to the port, it sets the output latches, but when you read from the port it reads the PINS, even for ones that are outputs. This is OK in theory, but anything that drags the output voltage towards the opposite logic level can cause it to mis-read. The static case would be a short to either supply rail, but the PIC rapidly gets pretty hot so I don't recommend trying that! When the pin is changing state though, it only takes a little capacitance to delay things long enough to cause trouble. The RMW sequence in a bit set or clear operation can read the incorrect state from a pin then load it into the output latch 'locking in' the incorrect state.

 

 

Microchip added the LATx registers to the PIC18 series specifically to cure this problem by allowing the output LATCHES to be read for a RMW instead of the pins. They didn't get it perfect though and the RMW bug crops up on PIC18s if you do bit operations on a TRISx register while the I2C module is 'fiddling' with tri-stating its pins! Edit: This bug is NOT CONFIRMED on any PIC18 chips, but some developers have noticed latch-ups on heavily utilised I2C modules in SLAVE mode consistent with a bug of this type.

Edited by IanM
Link to post
Share on other sites

Thanks Ian.

 

That's cleared things up for me and, as you suggest, will probably keep me from getting hung up on the issue in the future. I've been pushing the limit for far too long and needed a little kick.

 

Regards

Rye

Link to post
Share on other sites
Microchip added the LATx registers to the PIC18 series specifically to cure this problem by allowing the output LATCHES to be read for a RMW instead of the pins. They didn't get it perfect though and the RMW bug crops up on PIC18s if you do bit operations on a TRISx register while the I2C module is 'fiddling' with tri-stating its pins!

Ian,

 

Do you have any references for RMW problems with the I2C Module and TRISx on PIC18Fx devices?

 

I believe there was a problem with this on early silicon issues of PIC16Fx devices but not PIC18Fx (DS80131E).

 

I have a prototype, apparently running without any problems, using a PIC18F4520 for both the I2C master and slave but I obviously need to confirm that a bug like this will not bite me when in production.

 

Regards

 

davidb

Link to post
Share on other sites
Do you have any references for RMW problems with the I2C Module and TRISx on PIC18Fx devices?

 

I believe there was a problem with this on early silicon issues of PIC16Fx devices but not PIC18Fx (DS80131E).

 

I have a prototype, apparently running without any problems, using a PIC18F4520 for both the I2C master and slave but I obviously need to confirm that a bug like this will not bite me when in production.

 

Sorry, I don't have a hard reference, and it may well fall into the 'hearsay' category. Of course, if the module's Tris override circuit is correct, TRISx should read back the TRIS latch, but Datasheet != Silicon is nothing new and when the I/O pin circuit is described as 'simplified' it does not inspire confidence. The best advice is code it defensively.

 

I do have a reference to I2C latchups on the 18F6722 with a suspected RMW problem on the Microchip Forum, by John Oldenkamp. It's also worth reading this post in the same thread to gain some perspective. . . .

Link to post
Share on other sites

Ian,

 

Thanks for the reference.

 

I suspect the 'problem' on the PIC18F might be hearsay.

 

I don't like adding code to solve problems that may not exist but if in doubt...

 

Does anyone know any more regarding this issue?

 

Regards

 

davidb

Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...