• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 79 subscribers
  • Views 930 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Compiler/MSP430F5438A: Revision F is unstable in production

Jeffrey Westgeest
Intellectual 615 points
Part Number: MSP430F5438A

Tool/software: TI C/C++ Compiler

Hello,

For a production run of 100 units we found that 50% of the MSP430F5438A ref. F is working properly.

The other 50% is not booting correctly.

I have plugged in the debugger and found that with a "good" cpu the debugger has no problems.

With a "bad" cpu the debugger is lost, stepping with the debugger is not giving any problems but free run can result in different end "crashes" 

for example:

  • The PC is pointing to an address in flash that is not used and contains 0xFFFF.
  • The cpu goes into low power mode, SCG1 = 1 / SCG0 = 1 / OSCOFF = 1/ CPUOFF = 1.

The results are completely random, and the code in the cpu is not using an low powermode options. it is always in full power mode.

Our current solution is removing the Ref. f chip and replace it with another. I prefer to solve the problem in code but I have no idea what to test next.

The stack and heap are made bigger to ensure that this is not the problem.

please advice how to solve or debug this problem.

Thank you in advance.

  • 0
    TI__Guru**** 217667 points
    Hello Jeffrey,

    I have a few questions to help identify the issue:

    1. What revision are you replacing the rev F devices with that do not show the issue? Have you checked the erratasheet for similar issues?
    2. What is your system operating frequency and Vcore level? Can you provide initialization code?
    3. What are the CVCORE and CDVCC values? Can you provide the MCU schematic?
    4. Can you provide images of the VCC and RST lines during device start-up?
    5. Do you change the default SVS/SVM settings? Does your firmware ever intend to enter LPM4?

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 615 points
    Dear Ryan,

    I will try to answer your questions are best as possible:

    1. Any other model, this product been running for years now
    2. operation freq. is 20 MHz, so 5 MHz lower then the max. / code I'll have a look
    3. i'll check with debugger. / schematic --> i need to check with the HW engineer.
    4. I'll check with the scope, but the device is booting.
    5. As described in the initial post the code never enters an LPM mode.

    Additional info is that we use this CPU model for a lot of our products, and have never seen problems with is.

    Best regards,

    Jeffrey
  • 0 in reply to Jeffrey Westgeest
    TI__Guru**** 217667 points
    Hi Jeffrey,

    Two more questions while you gather information on the others:

    6. Can you provide the chip markings of failing devices, and do they appear to all be from the same lot as compared to passing rev F silicon?
    7. Have you checked the erratasheet for existing PMM or UCS errata which could explain your issue?

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 615 points
    Hi Ryan,

    1. The revision we will be going to is Rev. H.
    6. the chips marking on both the chips (working and none working are the same)
    7. Yes I have checked the erratasheet, and found nothing.

    best regards,

    Jeffrey
  • 0 in reply to Jeffrey Westgeest
    TI__Guru**** 217667 points
    Thanks Jeff. Since there does not appear to be an errata involved or variance between the working and non-working units, the issue seems to be related to MSP430 initialization in software and possible violation of a datasheet PMM/SVS spec that only affects a random selection of Rev F devices.

    Regards,
    Ryan
  • 0 in reply to Jeffrey Westgeest
    TI__Guru**** 217667 points
    Hi Jeff,

    Do you have any further information to provide? Where does this issue stand?

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 615 points

    This issue is solved by changing the chips.

    We currently do not have the time to solve the problem with this specific revision.

**Attention** This is a public forum