PIC18f87k90 external crystal (?) problem [Solved]

[PavelM]

Hello, I would like to share the problem and ask for advice on this forum.
Compiler version 5.101

There is PIC18f87k90 and Weintek HMI.
Initially, I made communication between them and everything worked fine.
PIC18F87k90 as master, Weintek HMI as slave.

On my first PCB, PIC18F87k90 was tuned to external crystal 10MHz, PLL ON, so my initialisation looked like this:

[PCM programmer]

What happens if you disable the PLL and WDT, and run the PIC
off the fundamental frequency of the crystal ? Example:

[Ttelmah]

Do you have a manufacturer and part number for the 14.7456 crystal?.
Understand that all crystals have specifications. Different load capacitances,
different ESR'a and drive levels. Now the '22pF' load capacitors, assuming
a reasonably low PCB capacitance, would be for a crystal requiring about
18pF load capacitance.

The formula is:

Cl = ((Ca*Cb)/(Ca+Cb))+Cs

Where Ca and Cb are the two external capacitors, and Cs is the board stray
capacitance. With reasonably short PCB tracks, Cs of perhaps 7pF would
be typical, so this would give 18pF effective load.
A lot of the 14.7456 crystals I see listed need 10pF load capacitances.
Then you have the drive levels. These are not really based on frequency,
but on typical drive levels needed at particular frequencies. It only takes
a crystal to be a rather low gain type, for the high power drive to be needed
rather than medium. Also, some crystals do require a series resistor,
or they are overdriven by the PIC oscillator.
Now, a 40MHz crystal, can give Modbus timings with less than 0.17%
error. You are worrying about a timing error that is less than 1/10th
of the allowed limits. You have also though made your system run over
45% faster. Now if there are time limits on things in the device, requiring
pauses between things being changed, you may just now be pushing
things too far.

Microchip do have an application note, with recommended crystal
parameters. You need to check that the new crystal meets these values.

[PavelM]

[PavelM]

Ttelmah
It’s not that I was really chasing the transfer speed or speed of MC itself, I just thought that to work with this quartz, I just need to change one quartz to another, but it seems that I need to deal with this issue a little deeper.

https://www.tme.eu/Document/1a73b69e6487c12c6ef660d6ee951878/YIC-49US_49SMT-quartz_crystal.pdf

Here is pdf on crystal by the way if you need.

[PCM programmer]

You gave us the generic data sheet for the crystal.

What is the full part number for the crystal that you received ?

[PavelM]

[Ttelmah]

What was the part number you actually ordered?

Problem is as PCM points out that is a generic data sheet. So an HC49-SSL
is very different from a HC49US. Also they do versions with a huge range
of load capacitances. The page you ordered 'from' should have said what
this is for your crystal.

Generically as you raise the processor frequency, the quality of everything
around the chip has to improve. Decoupling, the power supply etc. etc..

So there are two separate possibilities. The first that the high speed is
causing the problem, the second that the crystal is not oscillating correctly.
That you still have the problems without the PLL enabled, suggests the latter.

[temtronic]

While I don't use that PIC or the HMI....
Assuming the 2 PCBs are the same, except for xtal/caps,
is the 5V VDD well filtered and have you 'bypass' caps as required ?
does that PIC have 2 sets of VDD/VSS and you're not using both ?
any chance the wiring connections to the modbus device isn't 100%
did you clean the PCB ? any 'bad' solder joints ?

I'm thinking a hardware fault. You're going from 40MHz to about 60MHz,so you need a great,stable PSU, well bypassed PCB, and very good grounds

Since the program worked fine at 40MHZ, it 'should' be ok at 60, so don't start changing the program ! Work with a KNOWN GOOD version.
since you have a working 40 board, compare the faster one to it.

Also, can you slow down the 'fast' one to close to 40MHz while using the 14M xtal ?

if that PIC has an internal osc, can you try using it ?

[PavelM]

[temtronic]

Great ! Since it works 100% on the internal, it sounds like the external crystal/caps aren't the correct ones.

[Ttelmah]

My 'suspicion' would be that perhaps the original 10MHz, was designed for
a much higher load capacitance like 30pF, and the new crystal, is actually
something like a 10pF type. If the board has perhaps rather more stray
capacitance than ideal, it'd then be very significantly wrongly loaded.
Result frequency quite well off spec...
The frequency pull is typically proportional to the capacitance error^2,
so if the rating was for a low capacitance like this, the actual pull could
be several thousand PPM....

[PavelM]

Hello everyone again.
Returning to the topic of capacitors. I changed the 22pF capacitors to 12pF capacitors and it did not work properly.
But, when I found out why it does not work correctly, I even felt a little ashamed, but I still decided to share my bad, but experience.
Initially, the first printed circuit board was soldered completely with 10MHz quartz and an operating frequency of 40MHz and everything worked fine.
On the second board, I already wanted to change the quartz to 14.7456 MHz and, in fact, I was specifically interested in transmitting data via modbus rtu, because this is, in fact, my second time in my life when I use modbus.
And since I was interested in data transfer on this quartz, I told the person not to solder it completely, but only the section that belongs to the modbus.
And at some point, in fact, the thought even slipped through my head "shouldn't I disable external interrupts and other peripherals that I use in the program?"
But, then I thought to myself "no, well, if 10MHz quartz works with all external peripherals and interrupts turned on, then why should I turn it off here."
And in my program I use 3 external interrupts on rb0, rb1, rb2 and external interrupt on rb4-rb7. As a result, all these inputs were hanging in the air.
Thus, external interrupts worked for me with great frequency. And it clearly interfered with normal operation of modbus rtu.
So, once again, thanks everyone for your advice, next time I should be more careful.

[Ttelmah]

I think 'aargh' does apply.
Glad you have found what was causing the problem...