Crystals

[richb]

Hi

I'm using a 20mhz crystal with the PIC16F877A grounded using two 22pF cap's.

The chip is working fine, but one odd thing is it takes at least several seconds to jump into the main routine. Is this normal ?


Thanks,

Rich

 

[tunedwolf]

Depending on the xtal manufacturer 22pf may well be ok, personally I use 33pf which seems better suited across a range rather than just to a particular xtal or manufacturer. I would say that you have either forgotten something in your code, like watchdog timing or something, or perhaps it could be that your power supply is coming up really slowly and the brown-out detector/timer is affecting your code. Check first off that you actually have the config fuses set the way you expected them to be and work from there...

 

[Pommie]

Just to add to what Tunedwolf said, several seconds is not normal.

Mike.

 

[richb]

I had to set the 'HS' mode as i'm using a 20mhz and this seems to affect the speed even with my old 8mhz crystal. My code is very simple, all it is doing is turning on an LED (just for test purposes).

I'm using a stabilised power supply and getting the correct voltage to the chip. Anyone else had this problem?

 

[Pommie]

Have you got a large resistor coupled with a large capacitor on your reset circuit?

Mike.

 

[richb]

on the MCLR line i've connected it to the positive rail and grounded it using a 100NF cap

 

[Nigel Goodwin]

Try posting your entire code, use the 'code' tags to surround it, so it keeps it's formatting.

 

[richb]

using hitec c compiler, sorry no assembly here should be the same though

#include	<pic1687x.h>
#include	<stdio.h>

main(){

	TRISB 	= 0;
	PORTB 	= 0xFF;

}//main

I tried to keep it simple btw

 

[Nigel Goodwin]

Sorry, can't help you then - I don't do C.

 

[richb]

My asm is a little rusty but translate the c code would be this.

My fuse value is: 3FFEH

LIST	p=16F877a
include		"P16f877A.inc"

bsf STATUS, 5
movlw b'00000000'
movwf TRISB
bcf STATUS, 5

Start

movlw b'11111111'
movwf PORTB

end

Still get exactly the same problem with startup time when programming the chip in asm.

 

[philba]

so you have the /mclr pin directly tied to +5V with a 100n to gnd? I assume the cap is really just a bypass cap. Do you have ICSP set up? (ie, how are you programing the chip?). While I don't think the direct connection to +5 is the issue, I think it would create problems for an in-circuit programmer that holds the chip in reset. I'd use a pull-up in any event.

I kind of doubt it's the power up timer though if the voltage is low, it might be slower than the 70ish mS the spec says.

by the way, how do you know when the code starts? since it falls off the end of your main routine, you are executing what ever is left over in memory. It may well be all 3FFFs but who knows. just about anything can happen. I'd put a for( ; ; ) ; as the last statement.

edit: funny thing, if you write "for( ; ; ) ;" with out the spaces, you get for(;;

 

[eblc1388]

I remembered seeing post regarding unreliable crystal operation. It turned out to be a defective crystal and everything is fine after replacing the crystal.

Do you have another crystal (from 8MHz upwards) to try?

 

[richb]

>so you have the /mclr pin directly tied to +5V with a 100n to gnd? I assume >the cap is really just a bypass cap.

Thats correct,

>Do you have ICSP set up? (ie, how are you programing the chip?).

I have a seperate usb programmer for the chip.

>by the way, how do you know when the code starts? since it falls off the0 >end of your main routine, you are executing what ever is left over in >memory. It may well be all 3FFFs but who knows. just about anything can >happen. I'd put a for( ; ; ) ; as the last statement.

I added the for() loop, but unfortunately it didn't seem to resolve the issue.

I've tried with an 11mhz, 8mhz and 20mhz crystal and experience the same issue with all. All i can think it could be is the way i'm tieing it to ground on the MCLR pin.

(btw it seems less of a delay is slower crystal i use)

 

[eng1]

The !MCLR pin should be connected to the positive rail trough a 4k7 resistor, but this shouldn't be a problem - as philba said. Everything seems to be OK with your circuit.. what about the BODEN bit? Try to clear it.

 

[ombrastein]

One thing you might want to check is the origin of the actualy program in the controllers memory. I had this problem on an 877a controller a while back. After weeks of reserach i found that it turns out there is a weird bug in the architechure of these controllers. Under a certain set of circumstances, the function pointer(the register that points to wich intruction the micro should prossess next) starts out in the wrong place. What happens then is that it will start running random instructions, whatever just happens to be in unprogrammed memory. Eventualy you will run into a random instruction that says "goto 0", meaning set function pointer at origin 0, and your program starts. When using 20 MHz controller you run 5 million instructions per second, so even tho its a very small chance of hitting the right instruction(some random goto 0 statment) you will eventualy do so. For a micro controller, 2 seconds is a very long time. (how long does a humen spend to do 10 million operatiomns )

I would google for this problem some more, try fint some articles aobut it. I found that when i had the problem. The simple solution was forcing the origin, the place in the program memory where you store your actual program to somthing like 1 or 2, not 0, and then put a "goto 1" in location 0, or somthing like that... Its been a while isnce i had this problem, so i might not recal the details exactly right. I do know for sure there is a bug like this in the 877a arcitechure (maybe other PIC's as well). I would sugest you do some research into this angle on your problem.

Cheers and good luck
Magnum

 

[ombrastein]

I looked at some old code:

For a previus robot that i built, using an 877a chip i had to add this code:

*****************************************
#opt 3
#include "16F877.H"

//makes sure the uc doesnt go bananas due to bug in chip design
#build(reset=0x002)
***********************************

im using CCS c compiler. Probably is somthing similar to this for other compilers and obviusly for asm

the #build(reset=0x002) tells the compiler to put the code at location 2, and then go to that location whenever the chip is reset. This prevents any important code from beeing put in the unstable 0 location.

 

[Nigel Goodwin]

Presumably you mean the 'program counter', which on power up is set to the reset vector - I've never heard of a problem with that, nor would I imagine there is one? - it would be a SERIOUS bug, and it would be well reported by MicroChip, and the chips recalled.

Your idea that it will 'run random instructions in unprogrammed memory' is completely wrong, unprogrammed memory is set to 0x3FFF - which (not by a coincidence) is a NOP - so if it did happen to jump to unprogrammed memory, then it would run perhaps a millisecond or two of NOP's before looping back to 0x0000.

 

[ombrastein]

ok sorry for the tripple posts here ... just that the more i write about this the more i remeber from when i had this problem...


hers a qiuck list of what the #build instruction does:
This is a ccs instruction only and not pic in general, but im guesing there is someequivalent in asm or hitech c

************************************
Syntax:
#build(segment = address)

#build(segmentt = address, segment = address)

#build(segment = start:end)

#build(segmentt = start: end, segment = start: end)



Elements:
segment is one of the following memory segments which may be assigned a location: MEMORY, RESET, or INTERRUPT.



address is a ROM location memory address. Start and end are used to specify a range in memory to be used.



Start is the first ROM location and end is the last ROM location to be used.



Purpose:
PIC18XXX devices with external ROM or PIC18XXX devices with no internal ROM can direct the compiler to utilize the ROM.



Examples:
#build(memory=0x20000:0x2FFFF) //Assigns memory space

#build(reset=0x200,interrupt=0x208) //Assigns start location of

//reset and interrupt vectors

#build(reset=0x200:0x207

interrupt=0x208:0x2ff) //Assign limited space for

//reset and interrupt vectors.


*************************************

hope this helps...

Of course, this could be way off , but its a problem i know is out there, that can generate very weird microcontroller behavior...

Another thing i would check is the decoupling capacitors ... also check your brown out settings, and watch dog settings. all these can reset your controller, and you dont want that i gues

 

[Nigel Goodwin]

I looked at some old code:

For a previus robot that i built, using an 877a chip i had to add this code:

*****************************************
#opt 3
#include "16F877.H"

//makes sure the uc doesnt go bananas due to bug in chip design
#build(reset=0x002)
***********************************

im using CCS c compiler. Probably is somthing similar to this for other compilers and obviusly for asm

the #build(reset=0x002) tells the compiler to put the code at location 2, and then go to that location whenever the chip is reset. This prevents any important code from beeing put in the unstable 0 location.

I would suggest it's more probably a bug in the C compiler you're using?, the 16F877A has been about for years, and no one else has ever suggested such a thing.

 

[ombrastein]

yup, your right... the program counter is what i was refering to.

As for my idea of what actualy happens beeing wrong, that could very well be...
As i said, its been a while since i had this problem...

What i do know for sure, is that the code i posted solved a problem very similar to what was described here ... I searched for a solution to the problem and came up whit the #build(reset=0x002) thing. From what you said, i gues what this actualy does is set the reset vector to 2, instead of 0.

I also know that i didnt come up with this solution myself, i found it online somewhere (lost the link tho). Im guesing its a very rare problem, could even only be related to ccs compiler. And it could be fixed in newer versions of the chip....