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.

Cannot debug MSP432 anymore

I left my MSP432 launchpad connected to my computer USB and went to sleep. It had a blinking LED program on it.

Today, when I got here and took my computer out of sleep mode, the LED wasn't lighting up. I removed the cable, waited a bit, and plugged it back in, and the LED is very faintly blinking. It also doesn't connect to CCS anymore, when I try to program it, the "Cannot connect to target" error appears. 

Are there any suggestions and/or explanations as to what happened? 

Paulo

  • Paulo Costa said:
    Are there any suggestions and/or explanations as to what happened?

    I am not sure what happened, but the program in the MSP432 flash might have got corrupted in such a way which locks out JTAG access from the CCS debugger. E.g. have seen the problem on other Cortex-M4F device if the program keeps resetting quickly.

    Try running the Unlock procedure described in section 7 Device Security of http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=slau575&fileType=pdf to see if that allows the CCS debugger to connect again.

  • Hi Chester,
    Thanks for your response.
    I simply connected it back and it resumed working normally.

    I think this is a very weird bug. Could you try running this code overnight and see if the same happens?

    #include "driverlib.h"

    void delay1000ms();

    int main(void)
    {
    WDT_A_holdTimer();

    // Configure clock
    GPIO_setAsPeripheralModuleFunctionOutputPin(GPIO_PORT_PJ,
    GPIO_PIN4 | GPIO_PIN3,
    GPIO_PRIMARY_MODULE_FUNCTION);

    // Optional API that helps with getMCLK, getACLK functions
    CS_setExternalClockSourceFrequency(32000,48000000);


    // If we want to support 48MHz operation, we have to set the core voltage level high
    PCM_setCoreVoltageLevel(PCM_VCORE0);
    FlashCtl_setWaitState(FLASH_BANK0,2);
    FlashCtl_setWaitState(FLASH_BANK1,2);

    // Starting LFXT in non-bypass mode without a timeout
    CS_startHFXT(false);

    // Initializing MCLK to HFXT (48MHz)
    CS_initClockSignal(CS_MCLK,CS_HFXTCLK_SELECT,CS_CLOCK_DIVIDER_1);

    // Configure GPIO
    GPIO_setAsOutputPin(GPIO_PORT_P1,GPIO_PIN0);

    // Blink LED
    while(1){
    GPIO_toggleOutputOnPin(GPIO_PORT_P1,GPIO_PIN0);
    delay1000ms();

    }


    }

    void delay1000ms(){
    int i = 48000000/6;
    while(i > 0) i--;
    }

  • Some comments from looking at the code:

    Paulo Costa said:
    // If we want to support 48MHz operation, we have to set the core voltage level high
     PCM_setCoreVoltageLevel(PCM_VCORE0);

    From the datasheet the maximum allowed CPU frequency at VCORE0 is 24MHz. Attempting to set the CPU frequency to 48MHz using VCORE0 is operating the device outside of it's specification any may cause the CPU to misbehave, e.g. crash.

    Therefore, the code should be setting VCORE1:

     // If we want to support 48MHz operation, we have to set the core voltage level high
     PCM_setCoreVoltageLevel(PCM_VCORE1);
    

    This might explain the observed problem.

    Paulo Costa said:
    void delay1000ms(){
    int i = 48000000/6;
    while(i > 0) i--;
     }

    Because the loop variable hasn't been declared as volatile, the compiler is free to remove the delay loop as it has no observable effect on the code operation. In fact, if you compile this program for the Release configuration you will see that the compiler optimizer completely removes the delay1000ms function.

    To ensure the delay1000ms function isn't optimized out use:

     void delay1000ms(){
       volatile int i = 48000000/6;
       while(i > 0) i--;
     }
    

**Attention** This is a public forum