MCF51MM256 - the OSCINIT bit of the Multipurpose Clock Generator is never set

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MCF51MM256 - the OSCINIT bit of the Multipurpose Clock Generator is never set

Jump to solution
842 Views
ArtyCF
Contributor II

Hello,

 

I am using an MCF51MM device on a custom PCB that is based very closely on the schematic of the TWR-MCF51MM development kit.   I have been unable to get beyond a specific point in the configuration of the Multipurpose Clock Generator (MCG), specifically where the program waits indefinately for the OSCINIT bit in the MCGSC register to be set.  However, if I run the exact same code on the microcontroller in the TWR-MCF51MM board there is no problem at all.

 

My application is using MQX and I have identified the specific point where the code gets stuck to be in the module "bsp_init.c" , the third line in the function _mqx_clock_init_16MHz().  See below:

 

static void _mqx_clock_init_16MHz()
{
    VMCF51MM_MCG_STRUCT_PTR mcg_ptr =
        (VMCF51MM_MCG_STRUCT_PTR)&(((VMCF51MM_STRUCT_PTR)BSP_IPSBAR)->MCG);

    /*
    ** ------FBE MODE------  
    ** Assume 16MHz external clock source connected.
    ** RANGE = 1; HGO = 1; ERCLKEN=1; EREFS = 1; BDIV = 00
    */

    mcg_ptr->MCGC2 =  MCF51XX_MCGC2_RANGE_MASK
                    | MCF51XX_MCGC2_HGO_MASK
                    | MCF51XX_MCGC2_ERCLKEN_MASK
                    | MCF51XX_MCGC2_EREFS_MASK;

    /*
    ** Loop until OSCINIT (bit 1) in MCGSC is 1,
    ** indicating the crystal selected
    ** by the EREFS bit has been initialized.
    */
//    while( ! mcg_ptr->MCGSC & MCF51XX_MCGSC_OSCINIT_MASK );
    while( !(mcg_ptr->MCGSC & MCF51XX_MCGSC_OSCINIT_MASK) ){};    // STEVE: repaired operator precedence bug in BSP

.

.

.

 

(Note that there was a bug that line, which at first I was sure must be the cause of this problem, but unfortunately it appears not to be).

 

I have pretty much ruled out the possibility that the 16MHz crystal is the problem because on my custom board the microcontroller's ROM based USB bootloader functions properly and in fact I can see that when the bootloader is running the oscillator is working fine.

 

I have checked the header file which defines the masks used in the code above and they are correct according to the datasheet.  In a debugger I have also watched the MCGC2 and MCGSC registers and they appear to be correct.

 

The only difference that I can see is that the microcontrollers on my custom board are part number MCF51MM256VLL while the one on the development board is a PCF51MM256VLL (i.e. it has a Product Development code).

 

Does anyone have any ideas on what might be the cause of this?

 

Thank you.

Labels (1)
0 Kudos
Reply
1 Solution
659 Views
ArtyCF
Contributor II

Well, that's embarrassing.

 

I may be just talking to myself here but it turns out that the person who designed our PCB switched the external oscillators on me.  So in fact the 16MHz crystal was connected to OSC1 and the 32kHz crystal was connected to OSC2, not the other way around as it is on the development board.

 

For the benefit of anyone who might one day also make this mistake, I was able to get the code up and running by modifying the MQX board support package and setting up the Clock Check &Select Control register (CCSCTRL) appropriately to use the 16MHz crystal on OSC1.

 

Moving forward....

View solution in original post

0 Kudos
Reply
2 Replies
659 Views
ArtyCF
Contributor II

Additional information, I reconfigured the MQX board support package to use the 32kHz external crystal oscillator instead of the 16MHz crystal and found that inside the setup function _mqx_clock_init_32KHz() the program hangs once again waiting for the OSCINIT bit in the MCGSC register to set.

 

I'm beginning to suspect that the crystal oscillator in these MCF51MM256 devices may be defective.

0 Kudos
Reply
660 Views
ArtyCF
Contributor II

Well, that's embarrassing.

 

I may be just talking to myself here but it turns out that the person who designed our PCB switched the external oscillators on me.  So in fact the 16MHz crystal was connected to OSC1 and the 32kHz crystal was connected to OSC2, not the other way around as it is on the development board.

 

For the benefit of anyone who might one day also make this mistake, I was able to get the code up and running by modifying the MQX board support package and setting up the Clock Check &Select Control register (CCSCTRL) appropriately to use the 16MHz crystal on OSC1.

 

Moving forward....

0 Kudos
Reply