Help with Getting the CRG to Behave

[sabretooth]

Good evening everyone,

I have recently encountered a problem during testing of my code on-board my HC9S12DP256B.  I code in C using Imagecraft ICC12 Ver 7.  Currently I do all my testing by downloading code into RAM using a serial connection and DBug-12 w/ the target jumpered for EVB mode.

First some background: my C code is designed to abstract the user away from details of setting registers.  I provide people with a set of functions that they can use to set up one of any number of modules on-board the target of their choice (currently I only have code that works on my ‘DP256s, however with additional overhead I’m sure I’ll be able to get the code to work on other variants of HC12s…).  Part of my code allows the user to configure the Clocks and Reset Generator (CRG) and to select the target operating frequency (using the PLL as clk source), with a follow-on requirement to supply the new freq value to other modules thru functions to ensure that these modules (such as the ECT, SCI, EEPROM) “know” what their module clk freq (also known as the bus clk freq) is in order to operate properly.

In my first terminal dump (attached to this post), the CRG is config’d to operate at a PLL freq of 24 MHz (the standard setting once DBug-12 has finished its setup) and with an SCIO BAUD rate of 9600.  In each iteration of tests for different SYNR and REFDIV values, I have printfs that show what these values are in addition to what the PLLCLK freq will be (ie: results that fall under the “- - - CRG TEST A - Success - - -“).  Part of the requirement of my code is that any user-proposed values for SYNR and REFDIV must yield a PLLCLK that is not greater than the max operating freq  (I _assume_ 50MHz, is this value correct for this device?!?), not less than the min oper freq (I have no idea what this is as it is not explicitly called out in the Advance Info manual so I assume it is 16MHz,… is this correct?!?), and must result in an integer-value frequency.  I then determine what BR value is required to set SCI0BR based on the desired BAUD rate and the new bus clk freq (ie: results immediately under “- - - SCI Observation A - - -“).  In addition, each iteration of this test shows what the actual BAUD rates will be (truncated to the nearest integer).

In the second attachment, I show what I get for results when I attempt to change the PLL clk freq on-the-fly.  Things work properly for the first two iterations of 24 and 23 MHz (the PLLCLK/2 becomes the Bus Clk and is also the SCI Module Clk..), however beyond this things go “haywire.”  After doing a memory test, I determined that although my code size is large, there is enough space between the data, text and stack areas to ensure that the stack shouldn’t do any creepy things.  I attempted to set some breakpoints just after modifying the SYNR and REFDIV values; the processor somehow gets “lost” and spits out random values as shown in the second capture right after attempting to set the PLL to operate at 44 MHz (22 MHz Bus Clk freq).

Am I in violation of a basic tenet of how to properly adjust the system operating frequency?   Should I be setting the CRG to operate from the crystal osc (16 MHz), then attempting to set-up the PLL and ensure it has entered into lock prior to making it the clk source?  I am currently checking to see if the PLL has entered lock, however I don’t know if I’m doing this validation step properly as I go from one PLL freq to another on-the-fly.

An application where the freq goes from the crystal osc freq to one PLLCLK setting is fine if you only change the clk freq once, what if I need to go from 23 to 21 MHz or 24 to 18 MHz, then from 18 to 15 MHz, etc?

Please let me know if anyone has any recommendations/ideas, thanks!!

Eric North

Attachments: 1.  TERM_DUMP_9NOV06 1 of 2.TXT

2.  TERM_DUMP_9NOV06 2 of 2.TXT

[xgater]

Changing the pll settings like this sounds risky. Is there some way to cause a reset before setting to the new pll value? At the very least, I would think you need to disable the pll (PLLSEL = 0) before changing the frequency settings and then re-enable it and wait for lock before selecting it as your clock source.

I don't know about your cpu but on mine (MC9S12XDT256) we found that the xtal is very sensitive to humidity, fingers, etc. causing the PLL frequency to shift to 1/5 or some other fraction of the intended frequency. To avoid these issues, make sure you enable the clock monitor and read up on the self-clock mode to decide if you want it to switch back to self clock mode or reset in case the xtal stops dead. I would also suggest testing your xtal circuit for sensitivity to decide if you need to encapsulate it or otherwise protect it.

-Dan

[sabretooth]

Dan,

Thanks for your advice.  After doing some further code development, I’ve implemented some functions that attempt to perform a safe transition between one PLLCLK freq to the next.  To do this, my code does the following:

/**
 *  To set PLLCLK as clk source, or otherwise change the current PLL clk

 *  frequency, do the  following:
 *

 *  1.  Set OSCCLK as clk source, and enable/keep enabled the PLL.
 *  2.  Calculate (in floating point) what the new PLL Clk freq (PCF) will

 *      be using OSCCLK, and params \c cRGSYNRVal and \c cRGREFDIVVal.
 *  3.  convert the new PLL Clk Freq (PCF) to an integer value.
 *  4.  Perform a test to ensure that the new PCF is indeed an integer and

 *      is between the min and max values allowed for this device.  If the

 *      test fails, ensure OSCCLK is made the clk source.
 *  5.  If the test passes, allow the SYNR and REFDIV values to get updated

 *      with the supplied params.
 *  6.  Do a test to wait for CRGFLG to get set, if sucessful, indicates

 *      PLL has entered lock.  If the test fails (ie: a timeout is

 *      reached prior to lock), it means that there's a problem with the

 *      PLL entering into lock.
 *  7.  Upon success of the PLL lock test, Make PLLCLK the clk source.

 *      Update the CRG private data struct
 *      with the new PLL clk freq value.
 */

I perform some tests using my ‘DP256 jumpered for EVB and running the code in RAM using DBug-12.  Things work correctly up to the point that I try to make changes to SYNR, REFDIV and finally SCI0BR.  Anything other than DBug-12’s preset config that uses the PLL with BUSCLK of 24 MHz causes pandemonium in the terminal window.  Upon attempting to abort operation using *XIRQ, I can dig into the three registers mentioned above and determine that they are indeed being set to what I feel are the correct parameters (I’ve included lists of values below for reference).  Unfortuantely the SCI output/input doesn’t want to behave like its supposed to.

SYNR Value   REFDIV Value   Corresponding PLLCLK/2 Freq

    0                        1                                      8

    8                       15                                     9

    4                        7                                     10

   10                       15                                    11

    2                        3                                     12

   12                       15                                    13

    6                        7                                     14

   14                       15                                    15

    0                        0                                     16

   16                       15                                    17

    8                        7                                     18

   18                        15                                  19

    4                         3                                    20

   20                        15                                   21

   10                        7                                    22

   22                       15                                    23

    2                         1                                    24

I haven’t yet done any verification using SCM and the crystal monitor, to be honest I don’t have much direction or info at this point as to how to proceed validating my crystal and PLL’s operation using the functionality of the SCM or crystal monitor.  As for ensuring that the crystal is producing a stable frequency, what should I measure?  Will a scope probe (properly connected; what connections do I make and where?) reveal any trouble with the crystal?

Eric

[DanielM]

Eric,

you should certainly avoid changing the PLL settings while using its output to clock the system. You should always select the crystal clock first and only reselect the PLL after it has achieved lock again.

Here is what the manual says: "only when the LOCK bit is set, is the PLLCLK clock safe to use as the source for the system and core clocks."

Daniel

[sabretooth]

Daniel,

Thanks for your help.  I'll pay more attention to what the manual says in the future with regard to safety and cautionary instructions.  Once I've made some changes to my code I'll have to do some further testing to see if this was the only problem with my system.

Eric