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.

CCS/MSP430F5528: Question about using MSP430 in TIDA-01226 design

Part Number: MSP430F5528
Other Parts Discussed in Thread: MSP430F5514, TIDA-01226, DLPC3439, DLPDLCR4710EVM-G2

Tool/software: Code Composer Studio


In the TIDA-01226 schematic, the MSP430F5514 is used. In my design, I replaced it with the MSP430F5528 because the 5528 has more RAM.
The following phenomenon has appeared in use:
After the system is turned on, the light source is not lit (the light source needs the MSP430 to send the I2C command to light), the MSP430 hangs up and the program runs away.
In actual test, the MSP430's power supply is 3.32V. When it is turned up to 3.54V, sometimes the light source can be lit, and then the MSP430 will soon hang up.
The MSP430 chip was taken down and re-welded, and the phenomenon did not change.
What are the possible reasons that led to this phenomenon?
  • Hi JingMingJun,

    My first guess would be that you have a large array or a lot of global varieties that causes a watchdog timeout before the device finishes initializing them. If this is your case, you can try to add "__no_init" with your large array to avoid the initializing.
    If this is not the case, could you please provide more information, such as part of your design's schematic/layout, part of your code, etc..
    Let me know if you have updates.

  • Hi JingMingJun,

    Any update from your side? If not, I'll close this thread.

  • Hi Harry
    I am very sorry, I am not able to respond in time.
    I am in the process of confirming this problem with the software staff.
    Some information updates:
    Downloader MSP-FET430UIF, power output sometimes reaches 3.54V.
    When the downloader's power output is about 3.3V,
    it is almost impossible to illuminate the light source,
    but in the case of online simulation, the light source can be lit
    (and then the 430 program runs away).
    The reason is not clear.
  • In addition, the MSP430's watchdog was not activated.
  • Hi Harry

    The schematic in PDF format has been uploaded, please check it.

    Thanks & Regards,
  • Hi JingMingJun,

    Let me try to get back from the top.

    Firstly, you replaced the F5514 with F5528 in your design. Here, do you get a new layout from your side or you ordered a TI Design and replace this at the TI Design board? Seems you got your own design, I just want to double confirm.

    If you are using a new design, could you please let me know the difference here? What changes have you made in both hardware side and software side? Have you tried the software provided by the TI Design?

    Noticed that you said when using 3.3V from the MSP430 FET tools, the LED can't be lit up. Have you measured the current consumption? The MSP FET can only provide about 100mA current and you may want to check the driven strength here.

    Plus, you said the watchdog is not activated. I just want to make sure you don't use large amount global variables/arrays that requiring the compiler to initialize them. It'll cause watchdog overflow even you disable the watchdog at the first of your main function, since this compiler initialization happens before the main function. Please take a try to use the "__no_init" attribute if you have a lot of variables.

    Please let me know if you got any update.

  • Hi Harry

    My schematic is modified based on the TI schematic (TIDA-01226).
    Because the F5528 has the same package and PIN definition as the F5514,
    I just replaced the F5514 with the F5528 in the schematic
    (the schematic has been uploaded) and the PCB layout has not changed.

    Compared with TI design,
    1) Because I want to use the MSP430's low-power standby mode,
    MSP430 needs to be awakened by the rising edge of the power-on signal, so I changed the switch signal from P6.0 to P2.3;
    2) Using a 1/2 BUFF, the two fan speed feedback signals are turned into one and connected to the MSP430;
    3) System power input, changed from 19VDC to 15VDC,
    15VDC to 5VDC to 3.3VDC, as the power of MSP430,
    15VDC to 12VDC to 5VDC..., as the power supply for the DLPC3439 system,
    The MSP430 can control the 15VDC power supply of the DLP system to be turned on or off.
    4) The UART function is enabled;
    5) JTAG, delete, only keep SBW;
    6) TRIG_IN_A/B, delete;
    7) P3P3V_PWR_EN, delete;

    The software I used was also modified and functionally added based on the software provided by TI.
    Because the code changes a lot, I don't know if I can use the TI source code for verification.
    Regarding the difference in software, if you have specific content you want to know,
    please let me know, I will confirm with the software staff, and then reply to you.

    The power system on the board is also enabled while the MSP430 FET tool is connected.
    Therefore, the possibility of insufficient drive strength is relatively small.

    Regarding the "__no_init" attribute, I will also ask the software staff to confirm and then update.


  • Hi JingMingJun,

    Sorry but I still need some time thinking about your issue.
    I'll let you know if I get some finding.
    Also, please keep posting if you have update from your side.

  • Hi Harry

    Sure, no problem.

  • Hi JingMingJun,

    Just came up that if there is a power cycle order in your system that MSP430 is powered up after some other components, which causes MSP430's IO goes high (above ~3V) before MSP430's DVCC powers up. If this is the case, the F5528 may be powered up by the IO charge. But this power up is not a normal working situation and may cause malfunction.
    Could you please check the power up order for your system and try to avoid this scenario?

  • Hi Harry

    Thank you for your reply.
    I checked my system and under my test conditions, the MSP430 was the first to power up.
    However, it is also checked that when an external video signal is connected, there is a pin that may be in the situation you said. Actually confirmed, when the MSP430 is not powered, the video signal is connected. The voltage at the MSP430 port (P4.6) is 1.2V (the power supply of the MSP430 is 0.72V). Below 3V, should there be no problem?

  • Hi JingMingJun,

    Sorry just came back from the holiday.
    Do you mean you probe the DVCC pin at 0.72V when the P4.6 is 1.2V before MSP430 powered up in your last post? If so, this probably is not a problem as the 0.72V is below the SVS, thus MSP430 should not powered up.
    Also, do you get any update these days? Have you monitored your power supply? Since you use a 15V-5V-3.3V system, I'm not sure your power topology, but if there is a large ripple or a pulse that exceed the power supply limit, it'll also cause malfunction.
    Please let me know your update.

  • Hi Harry

    I am sorry to reply so late.
    Is it possible that the problem I explained earlier is related to the CCS settings?
    (1) The IC I am using is: MSP430F5528,
    (2) The project I am using is:
    DLPDLCR4710EVM-G2 MSP430 Software (with WPC project)
    (3) The version of CCS is: CCS8.0.0

    CCS-Properties-MSP430 Compiler-Processor Options:
    (1) Configuration: Debug or Release
    Should be set to "Release" mode, right?
    (2) Silicon version: mspx or msp
    I think it should be set to "msp", but the WPC project seems to be specified as "mspx".
    When using the default settings below, build error.
    Actual settings used:

    In addition,
    In the following document:
    Code Composer StudioTM IDE v8.x for MSP430TM MCUs_slau157ar.pdf
    As described below:
    -------------------------------------------------- ---------------------------------
    With the CCS compiler, the #pragma DATA_SECTION() directive must be used:
    /* CCS C Code */
    #pragma DATA_SECTION(alpha, "MYSEGMENT")
    Int alpha;
    #pragma DATA_SECTION(beta, "MYSEGMENT")
    Int beta;

    With the CCS compiler, the following scheme with the #pragma CODE_SECTION() directive must be
    /* CCS C Code */
    #pragma CODE_SECTION(g, "MYSEGMENT")
    Void g(void)
    -------------------------------------------------- ---------------------------------
    However, in the following TI software project, it is not used:
    DLPDLCR4710EVM-G2 MSP430 Software
    Is this a problem?
  • Hi JingMingJun,

    In general, I don't think the project setting contributes your problem.
    For the debug/release option, if you never touch these before, these two settings should function equally.
    For the processor configuration, mspx/large/small/globals is correct since the SRAM address is located below 0xFFFF.
    As for the #pragma settings you mentioned, it's mainly to show how to place code/data into "named segment". If you don't use this feature, this won't affect you.