Interrupt frequency difference 16F877 -> 18F452

David Eaves · Joined: 28 Sep 2004 Posts: 6

Hi there,
This is the first time I haven’t been able to find the answer to my problem in this forum, I've also been trawling the Microchip website. Sorry if this has already been asked or is documented elsewhere...

I just got the PCH compiler as I needed more memory for a program which started off in a 16F877. I've migrated to an 18F452, all is fine I changed the port d address as I was directly referencing it and updated all the fuses (I also compared a 18F452 program headers done with the CCS IDE wizard)

All is working well apart from one thing; the interrupt rate is not as expected. On the board I am using a 3.2768MHz crystal divided down by 64 with Timer 1 to give a 50Hz interrupt rate (3.2768M/4/256/64) this works fine and is spot on with the 16F877

I converted the code to what is shown below which I believe should do the same thing.

setup_timer_0(RTCC_8_BIT | RTCC_INTERNAL | RTCC_DIV_64);
enable interrupts(INT_TIMER0);

(then a global enable later on)

When I run it the interrupt rate seems about 1.5 times slower than it should be. I'm using version 3.202 of the compiler (I have the 30 day update rights still I was just hanging on starting) . Having read the microchip datasheet it seems like it is still divide by 4 on the instruction rate. Is it me being dopey, a bug, or something with the 18F452?

Any help is much appreciated
Thanks

David Eaves

Neutone · Joined: 08 Sep 2003 Posts: 839 Location: Houston

Ttelmah · Guest

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

David Eaves · Joined: 28 Sep 2004 Posts: 6

Thanks for all the input so far:

Neutone, I'm not using WDT, or accessing/modifying the counter value anywhere in the program. The code function is to keep track of time by incrementing a variable until >49 incrementing another then resetting the first etc - it's compact low overhead code. This worked fine on the F877 version. I also have Timer 1 interrupts running at 12.5Hz in theory, these detect key presses and some other housekeeping tasks. The code all worked fine previously and it has been running for months.

Ttelmah
Good point about the crystal, I had read about that but was being a bit slack at checking it. From what you have said I will investigate it and try and find a specification for the crystal and try your mod. Just thinking about it I'll put another make and value of crystal in and see if I get the expected rates for that frequency.

PCM programmer
Very good point, I will do that. I hadn't activated them yet as I have been messing around with my net connection (switching to ADSL) in the last few days and I only got PCH on Friday. I'll get the new version before I try it again.

Thanks again
David

asmallri · Joined: 12 Aug 2004 Posts: 1635 Location: Perth, Australia

David Eaves · Joined: 28 Sep 2004 Posts: 6

Hi all,

Sorry for my delay in the update here - my main job has been keeping me busy.

I did quite a bit of work looking into the timing problem I was having
-printed and read a lot of microchip stuff on crystals and tried different ones
- from this data played around with the Cp and Rs for the crystal. It still stayed the same error.

It then occured to me I should check if the whole thing was running at the right time. I tried transmiting with RS232 and found there were no problems. As the Timer 0 was out by around 1.5 too slow, if it was overall there was no way RS232 would work. So it seems my Crystal setup is okay.

This is silly now as it's not even out by a multiple you can sent up with Timer 0. I've had a good play around with the values and no avail it's still out. I think I'm going to hand code that bit in assembler now just to see if it makes any difference. I've also tried another chip and that had the same problem.

If anyone has any more ideas what the problem is, please let me know.
Thanks
David

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

You're going to have to post a test program. If you do that,
we can copy and paste it right in MPLAB (or the CCS IDE, I suppose)
and compile and run it on our hardware. Instead of conjecture,
we'd figure out the problem very quickly.

Make the test program be small. Only include lines of
code that demonstrate the problem. Don't do any
mistakes like letting the code run off the end of main().
Be sure to post all pre-processor statements that are
part of the program, such as #include, #use statements,
#byte, etc. Be sure to show all variable declarations.
In other words, a complete test program.

David Eaves · Joined: 28 Sep 2004 Posts: 6

Hi there,

Your right, that will be the best way of getting to the bottom of the problem rather than speculation. I will sort out a cut down version tomorrow that shows what is happening.

Thanks
David

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Good. Also post the version of the compiler that you're currently using.

David Eaves · Joined: 28 Sep 2004 Posts: 6

Hi there, as suggested here is the code....
I've gone down to a simple program to hopefully show the problem. In doing this I now found that I'm having the same thing with a 16F877 so there is no difference, but the time is not as expected. I set this program up using the wizard on the CCS interface to make sure all was well that way. In the program I use the delay_ms to make a rough seconds counter, this isn't far out and shows that the crystal is running okay. The seconds counter that should be right seems to be running about 3-4 times slower than it should be.

asmallri · Joined: 12 Aug 2004 Posts: 1635 Location: Perth, Australia

You have a couple of problems here. Firstly the code produced by the compiler is non reentrant. See http://www.ccsinfo.com/forum/viewtopic.php?t=17661&highlight=delayms+interrupts

To solve this problem, if you use code (such as delay_ms) both inside and outside an interrupt handler, then the code outside the handler will disable interrupts for the duration of the function. That is why your sample code does not work.

Also your TMR0 ISR code is not optimal for the time processing. If you change it around a bit you will spend less time in this interrupt handler.

David Eaves · Joined: 28 Sep 2004 Posts: 6

Hi asmallri,

Thanks for the reply. I didn't realise that with the delay function, it is very useful to know. I have found one delay_ms(1) that is called from within the real timer_1 ISR. I'll try this out and see if it makes the difference. Good point with the timer_0 code, that is more elegant.

Update: I got rid of the delay_ms() and the problem is fixed. When I was writing the program before I was using an ancient version of the compiler (at least 4 years old) and it must handle it different hence the problem when I moved up to the 18F and new compiler version.

Thanks again for the help.
David