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.

MSP430FR4xx UART works in Debug mode but not in release mode

Other Parts Discussed in Thread: MSP430FR4133, MSP430F5529

Hello,

I am using a MSP430FR4133 Launchpad board. I am trying to send out a simple string on the UART TXD line. 

My code works perfectly fine when used in debug mode, and the characters are sent out on TXD line with correct baud rate and timing precision.

However, if I use the same in release mode, (e.g. using a power on reset/ switch to reset) there is garbage information sent out on TXD line. Also the baud rate is incorrect.

Please help me in this regard.

Thanks,

Rohan L

  • Rohan,

    The issue could be in your initialization code for the UART peripheral that could be allowing it to work when being stepped through in debug mode but not when allowed to run on its own. Please provide the following information to help solve this problem:

    - Initialization code
    - Images of where the error occurs, etc.

    Regards,
    Michael Arriete
  • Most probably this is happening because you are sending the data before the MSP430 clock stabilizes. When you are in debugging mode, the clock is already stabilized before you run the program. So UART works correctly. But in release mode, when you do a hardware reset, it sends the data before the clock is stable. So you do not get correct data. If this is the case, it should work if you add a delay of 10 milli-seconds or more before sending the data for the first time. Try this, I hope it should work.

    Regards,

    Vaibhav

    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    If my reply answers your question, please press the  Verify Answer button below the answer to help other users find the correct answer easily.

  • Hello Michael,

    I am using two simple initialization routines. One for the two pins (RXD and TXD) to configure them as the peripheral and not GPIOs.

    Second for configuring the UART registers. Following is the code for initialization.

    CODE:

    int main(void) {


    //Stop the watchdog timer
    WDTCTL = WDTPW | WDTHOLD;

    // Disable the GPIO power-on default high-impedance mode to activate
    // previously configured port settings
    PM5CTL0 &= ~LOCKLPM5;

    //Configure the I/O pins on the ports.

    port_config();

    //Setup the UART registers

    uart_set();

    char *s = "My first UART string\n";

    sendStringOnUART(s);

    return 0;
    }

    Functions definitions are as follows:

    void sendStringOnUART(char *stringToSend)
    {
    int i=0;
    int string_length = 0;

    string_length = strlen(stringToSend);
    for(i=0;i<string_length;i++)
    {
           UCA0TXBUF = stringToSend[i];
           while((UCA0STATW & 0x0001) == 1){
            }
    }
    }

    void uart_set(){

    UCA0CTLW0 = 0x0001;

    UCA0CTLW0 = 0x00B1;

    UCA0CTLW1 = 0x0000;
    UCA0BRW = 0x0008;
    UCA0MCTLW = 0xD600;
    UCA0CTLW0 = 0x00B0;

    }

    void port_config(){

    P1SEL0 = 0x01;
    }

    There is no specific error that occurs. Only that the string can be seen on the terminal while using the debug mode, but garbage values are displayed when run in release mode, i.e. without connecting the board to the PC or running with Code composer studio.

    Appreciate your help on this.

    Thanks,

    Rohan L

  • If you are not connecting the board to the PC, to what and how do you connect the communication? How and what voltage do you supply to the board?
  • Leo,
    Following are the two cases where I am getting the difference.

    1. I Build the code using Code Composer studio, no errors, and then I go to the debug mode. At this time the board is connected to the PC using a USB cable, and the TXD and RXD pins (and GND of course) on the board are connected to the PC using a UART to USB converter (On a different USB port). I run the code in debug mode and I see the string on the PC terminal (I am using Tera-Term for this) perfectly, without any garbage values.

    2. I download the code on the microcontroller and disconnect the board from the PC(USB cable), however I keep the TXD and RXD pins connected to the PC through a UART to USB converter. I connect the board to a power supply through the USB cable. Now both the power on reset and hardware reset using the switch give me garbage values on the Terminal.

    Note: In both the cases the baud rate calculated valued are same in the code, and the same baud rate is on the PC.
    Also, I checked the output from the board pins in both cases using a logic analyzer. In first case the Logic analyzer detected the string, but in second case it gave erroneous output. Therefore, there is no fault in Terminal emulator or UART to USB converter.

    Please let me know your inputs on this. I have posted my entire code above.

    Thanks,
    Rohan L
  • Rohan,

    Did you try adding a delay before sending the string for the first time as I suggested in my reply above?

  • After your step 1. you can stop debug CCS, disconnect the LP from your PC and connect and external power supply. You don’t need to re-flash the program as you describe in your step 2. This will run exactly the same program as during CCS debug.

    Verify if the ground levels are all the same and not carrying any noise. If possible supply your LP from a battery.
  • Hi Vaibhav,

    Yes, I did try doing that. But that did not work. I got the same garbage values on the Terminal.

    Thanks,
    Rohan L
  • Rohan,

    It sounds like when you disconnect the board from the PC there is a compatibility issue with the two power supplies. There could be noise between the devices, through an uncommon ground. Please look into this further. Otherwise, the code should work if initialized correctly.

    Also, please refrain from selecting Verify Answer on posts that do not directly answer your original question. This helps to allow others who have the same question quickly find the answer to their problem. Thanks!

    Regards,
    Michael Arriete
  • How much delay did you add?

    Now, I tried your code on my own MSP430FR4133 Launchpad board. I had the same problem, but it works fine in release mode after I added a delay of 200 milli-seconds after initializing the UART.

    I guess MSP430FR4133 clock takes longer time to stabilize as compared to MSP430F5529, as 10 ms delay was enough for MSP430F5529.

    Can you please increase the delay to 1 or 2 seconds and see if it works!!!
  • Vaibhav,
    Thank you for your suggestion. I will try giving a delay after UART initialization and see the results.

    -Rohan
  • Vaibhav,
    Thanks for your solution. It is working fine after adding the delay of 200 msec. It is now working will in release mode as well without giving out any garbage values.

    Thanks all to other suggestions as well.

    Thanks,
    Rohan
  • You are welcome Rohan! It's good to know that your problem is solved.

    Regards,
    Vaibhav
  • When you need an accurate clock, for example for data communication, you need to ensure the clock is stable prior to start communication.

    By default, the DCO frequency is controlled by FLL and the FLL uses the XT1 oscillator as a reference.

    You need to add the following lines to your program prior to start to use the DCO (for communication) to ensure first the XT1 reference oscillator is stable and second the DCO is stable.

    With this you have the fastest and a safest Boot.

        /* Clock System (CS) (FR2xxx / FR4xxx) */
        
    	// Loop until XT1 is stable
    	do
    	{
    		CSCTL7 &= ~XT1OFFG;					// Clear XT1 fault flag
    	} while ((CSCTL7 & XT1OFFG) != 0);		// Test oscillator fault flag
    
    	// Loop until DCO is stable
        while ((CSCTL7 & (FLLUNLOCK0 | FLLUNLOCK1)) != 0); // Poll until FLL is locked
    
        //
        // ...
        //
    

  • Leo,
    Thank you for the inputs.
    That gives a different perspective for board bring up, and will solve my problem in a more technical manner.

    -Rohan

**Attention** This is a public forum