PIC16F1789 4xPLL Problem (small rant) - Page 1
Forum section: electronics / general

author: jpanhalt
author_rank: Super Contributor
timestamp: April 03, 2022, 06:43:18 pm
content: I am using a PIC16F1789 in my current project. The package is a TGFP44 and chip revision ID is 00000000.The internal oscillator was set to 4 MHz with 4xPLL enabled in the configuration (PLLEN) and code (SPPLEN set). Everything was fine for the past month or so in both debug and release versions until about an hour ago. The program, which uses a Timer1 based clock, just stopped. About 5 minutes later after disconnecting and reconnecting, it started again for a few minutes, then stopped apparently permanently. OSCSTAT shows 10011101 (i.e., bit<6> clear = 4xPLL not ready).I changed to the 16 MHz internal oscillator (OSCCON = 01111000) and program runs as it did before.Errata has this comment:QuoteI cleared PLLEN in the configuration and set SPLLEN in code with a 4 MHz clock. That worked, but I don't know for how long. OSCSTAT still showed 10011101, i.e., 4xPLL not ready. So, I will just not use 4xPLL. That errata applies to both revision numbers that are available. What a PITA.

author: AndyC_772
author_rank: Super Contributor
timestamp: April 03, 2022, 07:21:39 pm
content: I use exactly that device, with PSMC running from the 4x PLL (64 MHz), in a customer project. It 'just works', in production quantities.On that basis I believe the errata is correct, and once it's got started, it runs correctly forever. I think your problem may be elsewhere.Are you using a PCB with a solid, uninterrupted ground plane under the device? PLL issues are usually noise related, in my experience.

author: jpanhalt
author_rank: Super Contributor
timestamp: April 03, 2022, 07:40:58 pm
content: The ground plane is not 100% solid; there are a few tracks in it. But, all of the copper poor is well connected on the bottom and with vias to the top. I am not using PSMC in any way. I chose the chip as a migration from the 16F1829 but with more pins to facilitate routing. It is just a thermocouple data logger with a little extra arithmetic. Sixteen MHz is as fast as I can go with the 2 SPI interfaces. (I could go faster with one and slow down for the other, but 16 MHz produced almost unnoticed latency on screen refreshes due to scrolling.)Do you set 4xPLL in CONFIG? After several readings of the ERRATA, I think that is the trick. Don't do it. I could have made that point while writing the errata in a lot fewer words.

author: woofy
author_rank: Frequent Contributor
timestamp: April 03, 2022, 09:42:50 pm
content: Do you have good decoupling close to the device on both pairs of power pins.2 x 100nF ceramic should be fine

author: jpanhalt
author_rank: Super Contributor
timestamp: April 03, 2022, 10:18:02 pm
content: C4 and C11 are 100 nF on Vdd.Edit: As suggested, just don't use CONFIG to set 4xPLL with that chip. It works, if CONFIG PLLEN =0 (OFF) and SPLLEN is set in regular code. The ERRATA could have been stated more simply.

author: woofy
author_rank: Frequent Contributor
timestamp: April 04, 2022, 08:44:55 am
content: Capacitor placement looks good, but how are they connected to the ground plane?I can see the Vdd connections but the other ends don't look connected.

author: jpanhalt
author_rank: Super Contributor
timestamp: April 04, 2022, 10:58:34 am
content: Copper pours top and bottom and vias for ground. On the occasion when a pour doesn't go where I want, I use a trace named GND. That is pretty infrequent as one has great control over the polygon pours in EAGLE 7.x (e.g., separation, fill line width). I don't recall there are any instances of that in this board.Since 4xPLL works fine when set in code but not when set in CONFIG (previous post), I don't think decoupling is the issue. I have attached top and bottom with the pours shown.