• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 80 subscribers
  • Views 2367 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

msp432 sample doesn't work with msp432 launchpad

Rick Kimball
Expert 2105 points
Other Parts Discussed in Thread: ENERGIA, MSP430WARE

I was trying some of the msp432 C device samples with CCS on ubuntu 14.04.  Some work as expected however I'm having a problem with the sample

 msp432p401_pcm_09 - device operation at 48MHz with DC-DC Regulator


It seems like it should work as the launchpad seems to have the proper inductor.  I've tried this in an up to date CCS 6.1.0 on 32 bit ubuntu and with the cloud based dev.ti.com site. Both are able to program the board however the code fails and ends up in the error routine and just sits there blinking at me without setting the PCM values or the 48 MHz clock.

Has anyone else tried this sample on an msp432 launchpad? Did it work for you?

-rick

  • 0
    Expert 2105 points
    Just as a point of reference. The board seems to run at 48 MHz using Energia just fine.
  • 0
    Guru 92251 points

    Rick Kimball said:
    Has anyone else tried this sample on an msp432 launchpad? Did it work for you?

    The msp432p401_pcm_09 example from MSP430ware 2.0.0.16 also failed for me. The example code is incorrect, since when it writes to the PCMCTL0 register it uses the incorrect key which causes the write to be ignored. E.g.:

        PCMCTL0 = PCMKEY_M | AMR_1;

    Where PCMKEY_M is 0xffff0000, which is the mask for the bits in the PCMCTL0 which contain the "PCM Key". To be able to modify the PCMCTL0 register the example code should be using PCM_CTL_KEY_VAL (0x695A0000) as the key.

    In the example I changed the two instances of PCMKEY_M to PCM_CTL_KEY_VAL and then the example ran without ending up in the error routine:

        while ((PCMCTL1 & PMR_BUSY));
    PCMCTL0 = PCM_CTL_KEY_VAL | AMR_1;
    while ((PCMCTL1 & PMR_BUSY));
    if (PCMIFG & AM_INVALID_TR_IFG)
        error();                            // Error if transition was not successful
    if ((PCMCTL0 & CPM_M) != CPM_1)
        error();                            // Error if device is not in AM1_LDO mode

    /* Step 2: Transition from AM1_LDO to AM1_DCDC */
    while ((PCMCTL1 & PMR_BUSY));
    PCMCTL0 = PCM_CTL_KEY_VAL | AMR_5;
    while ((PCMCTL1 & PMR_BUSY));
    if (PCMIFG & AM_INVALID_TR_IFG)
        error();                            // Error if transition was not successful
    if ((PCMCTL0 & CPM_M) != CPM_5)
        error();                            // Error if device is not in AM_DCDC_VCORE1 mode

    [I haven't checked the MCLK output on P4.3]

  • 0 in reply to Chester Gillon
    Expert 2105 points

    Good catch Chester, thanks for spotting it.

    Here are other samples that are probably wrong:

    $ grep AMR_ */*
msp432p401_cs_03/msp432p401_cs_03.c:    PCMCTL0 = PCMKEY_M | AMR_1;
msp432p401_pcm_04/msp432p401_pcm_04.c:            PCMCTL0 = PCMKEY_M | AMR_1;
msp432p401_pcm_04/msp432p401_pcm_04.c:            PCMCTL0 = PCMKEY_M | AMR_5;
msp432p401_pcm_05/msp432p401_pcm_05.c:            PCMCTL0 = PCMKEY_M | AMR_8;
msp432p401_pcm_05/msp432p401_pcm_05.c:            PCMCTL0 = PCMKEY_M | AMR_9;
msp432p401_pcm_06/msp432p401_pcm_06.c:            PCMCTL0 = PCMKEY_M | AMR_8;
msp432p401_pcm_06/msp432p401_pcm_06.c:            PCMCTL0 = PCMKEY_M | AMR_9;
msp432p401_pcm_07/msp432p401_pcm_07.c:            PCMCTL0 = PCMKEY_M | AMR_8;
msp432p401_pcm_07/msp432p401_pcm_07.c:            PCMCTL0 = PCMKEY_M | AMR_9;
msp432p401_pcm_08/msp432p401_pcm_08.c:            PCMCTL0 = PCMKEY_M | AMR_4;
msp432p401_pcm_08/msp432p401_pcm_08.c:            PCMCTL0 = PCMKEY_M | AMR_5;
msp432p401_pcm_09/msp432p401_pcm_09.c:    PCMCTL0 = PCMKEY_M | AMR_1;
msp432p401_pcm_09/msp432p401_pcm_09.c:    PCMCTL0 = PCMKEY_M | AMR_5;

    And here is the change to fix them:

    $ grep AMR_ */* | sed -e 's/PCMKEY_M/PCM_CTL_KEY_VAL/g'
msp432p401_cs_03/msp432p401_cs_03.c:    PCMCTL0 = PCM_CTL_KEY_VAL | AMR_1;
msp432p401_pcm_04/msp432p401_pcm_04.c:            PCMCTL0 = PCM_CTL_KEY_VAL | AMR_1;
msp432p401_pcm_04/msp432p401_pcm_04.c:            PCMCTL0 = PCM_CTL_KEY_VAL | AMR_5;
msp432p401_pcm_05/msp432p401_pcm_05.c:            PCMCTL0 = PCM_CTL_KEY_VAL | AMR_8;
msp432p401_pcm_05/msp432p401_pcm_05.c:            PCMCTL0 = PCM_CTL_KEY_VAL | AMR_9;
msp432p401_pcm_06/msp432p401_pcm_06.c:            PCMCTL0 = PCM_CTL_KEY_VAL | AMR_8;
msp432p401_pcm_06/msp432p401_pcm_06.c:            PCMCTL0 = PCM_CTL_KEY_VAL | AMR_9;
msp432p401_pcm_07/msp432p401_pcm_07.c:            PCMCTL0 = PCM_CTL_KEY_VAL | AMR_8;
msp432p401_pcm_07/msp432p401_pcm_07.c:            PCMCTL0 = PCM_CTL_KEY_VAL | AMR_9;
msp432p401_pcm_08/msp432p401_pcm_08.c:            PCMCTL0 = PCM_CTL_KEY_VAL | AMR_4;
msp432p401_pcm_08/msp432p401_pcm_08.c:            PCMCTL0 = PCM_CTL_KEY_VAL | AMR_5;
msp432p401_pcm_09/msp432p401_pcm_09.c:    PCMCTL0 = PCM_CTL_KEY_VAL | AMR_1;
msp432p401_pcm_09/msp432p401_pcm_09.c:    PCMCTL0 = PCM_CTL_KEY_VAL | AMR_5;

    -rick

  • 0 in reply to Rick Kimball
    Expert 2105 points

    Another interesting side note is that the driverlib code creates its own PCM_KEY define in pcm.h and uses that in pcm.c

  • 0 in reply to Rick Kimball
    TI__Genius 17802 points

    Hey guys,

    good catch on the PCM examples. At some point during our development, some of the bit definitions changed in the header file (xxx_M --> xxx_KEY, and xxx_M becomes mask for the field). Since the definitions were reused, this still passed our regression test and only recently surfaced when we manually retested these examples. There were a couple of other places where we had this change in the clock module (CS).

    This has been fixed and the we'll release the updated code soon. For the time being, here's the nightly zip file of the new examples.

    C.zip

    Let us know if this works for you.

    ~Dung

  • 0 in reply to Dung Dang
    Expert 2105 points
    Sorry Dung, I tried out those files and they seem to work better. I just forget to come back here and mention it.

    Thanks,

    -rick
  • 0 in reply to Rick Kimball
    TI__Genius 17802 points
    No problem Rick, thanks for confirming that it works for you.
    ~Dung
  • 0 in reply to Dung Dang
    Prodigy 30 points

    It would appear the latest release breaks this again, but in a different way.   The most recent example now includes the corrected

    PCMCTL0 = PCM_CTL_KEY_VAL | AMR_1;

    However when you build the source you get the error:

    "../msp432p401_cs_09.c", line 105: error #20: identifier "PCM_CTL_KEY_VAL" is undefined

    In looking at the msp432p401r.h header file you find

    #define PCMCTL0_KEY_VAL                                    (0x695A0000)          /* PCM key value */
#define PCMCTL1_KEY_VAL                                    (0x695A0000)          /* PCM key value */

    but no mention of 'PCM_CTL_KEY_VAL'.   Perhaps that #define was deprecated in an effort to support multiple keys for devices that have multiple PCM modules?

**Attention** This is a public forum