This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC430 -> mapping MCLK to output pin problem

Other Parts Discussed in Thread: CC430F6137

Has anyone managed to get MCLK to map to an output pin on a CC430F6137?  I am able to get ACLK out on pins P2.4 or P2.6, but when I set those same pins to PM_MCLK (PM_MCLK == 4 in my book)  all I get is 32768Hz (ACLK), no matter what I set MCLK to.

So, this example works as I expect (LCD and UART display/debug code removed for clarity):

  PMAPPWD = 0x02D52;             // Get write-access to port mapping regs 
  P2MAP4 = PM_ACLK;              // map ACLK or MCLK to P2.4
  P2MAP6 = PM_ACLK;              // map ACLK or MCLK to P2.6
  PMAPPWD = 0;

  P2DIR |= (BIT4 | BIT6);    // set xCLK signals out to pins

  P2SEL |= (BIT4 | BIT6);    // set mapped outputs for P2.4, P2.6:

  for (clk = 0; clk <=5; clk++)
  {

      UCSCTL4 = (clk<<8) + (4<<4)+ (4<<0);  
      delay(50);
      for (X=0; X<5; X++)
      {
           delay(250);
      }
  }

And I can measure the correct output pin values (32768, ~10kHz, ~33kHz, 2.1MHz, 1.048MHz respectively). 

Then I change "PM_ACLK" to "PM_MCLK" and repeat with the loop from clk=3 to clk=5 and I use

      UCSCTL4 = (0<<8) + (4<<4)+ (clk<<0);

The output pins show only 32768Hz. 

I've tried this with both XX430 and CC430 (rev D) chips.

SMCLK is driving the UART based on a 1.048MHz DCO clock, and I print status throughout the above test code (printing removed for clarity) using the UART.   So I'm pretty sure the DCO is really 2MHz, DCODIV is really 1MHz, SMCLK is 1.048Mhz, and ACLK is really 32768Hz.  I even think that MCLK is 1.048MHz. I just can't output it onto a pin to prove it.

Any ideas?

Thanks,
Neal

 

 

 

 

 

 

  • Are you sure you're driving MCLK from DCODIV and not from REFOCLK? Maybe your MCLK is really just 32kHz. Check the clock module config commands.

     There's a difference between SELM2 and SELM_2 :) ( the first sets bit 2 of the SELM bits -> DCOCLKDIV, the second sets the value 2 for the SELM bits ->REFOCLK)

  • Jens-Michael - thanks for the suggestion, but that wasn't the issue as I  wasn't using SELM_2 or SELM2 - my code was using literal numbers as I posted (eg:  5<<0 etc...). 

    The problem turned out to be a bad include file with GCC (yes, I shoulda mentioned we're using MSPGCC-4).  They had the base offsets for the PMAP registers wrong for Ports 2 and Ports 3.   Once we figured that out the rest fell into place.    The newest MSPGCC 4 release has the corrections in pmcontrol.h, and we're able to see MCLK on the output pins.

    Another tip for anyone following in my path: make sure to set bit 1 (0x02) in PMAPCTL so you are able to change the PMAP registers more than once.

    Neal

     

    Jens-Michael Gross said:

    Are you sure you're driving MCLK from DCODIV and not from REFOCLK? Maybe your MCLK is really just 32kHz. Check the clock module config commands.

     There's a difference between SELM2 and SELM_2 :) ( the first sets bit 2 of the SELM bits -> DCOCLKDIV, the second sets the value 2 for the SELM bits ->REFOCLK)

     

  • Neal Friedman said:
    I  wasn't using SELM_2 or SELM2

    I should take more time to analyze the code completely. It totally slipped me that you're reconfiguring the clock setting sin your loop. I just assumed that you (as it too often happens in this board) simply had omitted the init code for the system clocks. So I concentrated on the problem why you're reading 32kHz when trying to output the (configured elswhere) MCLK to the port pin.
    Of course I couldn't know about the includes. I'm an mspgcc3 user and I know of the problems with newer header files for the latest MSPs. (actually I wrote some of those for the 54xx in the mspgcc project, as there were only a few and buggy ones when I started with this processor)

    Personally, I cannot recommend using MSPGCC4 for commercial usage. There are still too many bugs and unsolved 430x architecture problems (large data pointers, interrupt vectors, libraries etc.). If you don't need the huge flash of the newer processors, the mspgcc3 is better suited. (and I use the flash above 64k for slow data storage anyway, just not for code)

**Attention** This is a public forum