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.

MSP430FR2633: If the MCU is booted with the electrostatic sensor sheet attached to the PCB, the touch panel cannot be operated.

Genius 3215 points

Part Number: MSP430FR2633

Hi All (dennis-san) ,

We added the NMI handler code you previously provided under the main function in main.c on the defective board where LED1 turns OFF after 1–2 days, and conducted a running test.
As a result, after about two weeks, both LED1 and LED2 ended up in the OFF state.
Adding the NMI handler code seems to extend the time until the issue occurs.
It does not appear to be related to the conditions we included this time,
such as NMIIFG NMI pin or SVSH event and OFIFG oscillator fault.
Could there be other possible NMIs? If so, could you provide an example of how to handle them?

Best Regards,
Ito

  • Hello Ito,

    Because Dennis has left TI, please give our team some time to take a look into this case.

    Best Regards,

    Janz Bai

  • Hi Janz,

    Has there been any progress in this investigation?

    Best Regards,

    Ito

  • Hello K.Z,

    Our Cap touch expert is taking look into this case now, it is quite complicated and we need more time. Sorry for the late response.

    BR.

    Janz 

  • Hi Janz,

    Could you give me your opinion?

    I'd like an answer soon.

    Best Regards,

    Ito

  • Hi Janz,

    Have you found an engineer who can respond instead?
    The customer is waiting for a response.
    Please respond as soon as possible to avoid project delays.

    Best Regards,

    Ito

  • Hello Ito,

    Yes, I have one cap touch colleague to look this case, but he is out of office this week because of he has some urgent / unfortunately thing at his home. Let me contact him about current status of this case.

    BR.

    Janz Bai

  • Hi janz,

    Thank you for your reply.

    As a result of implementing the UNMI program, both LED1 and LED2 remained OFF, so I believe the microcontroller is in a state where the UNMI interrupt is not being executed and has stopped.
    I have commented out the code in main.c that enters low-power mode and am currently running a test.

    ・If LED1 stays ON and touch detection stops → There may be some issue with the Captivate event timer interrupt.

    ・If LED1 turns OFF → There may be some issue causing the CPU to stop.

    Would this assessment be correct?
    Here is the information I previously received from Dennis:

    [Regarding the possibility that the CPU is not returning from low-power mode]
    If the CPU does not return, it is highly likely that no interrupt is occurring in the system.
    If other peripherals are not configured to generate interrupts, Captivate would likely be the only interrupt source.
    In Captivate, if "wake on proximity" mode is disabled, the Captivate event timer generates periodic interrupts (by default set to 33 ms in the GUI) to wake the CPU and perform measurements.

    Best Regards,

    Ito

  • Hi Ito,

    I have a question that why your board will enter NMI interrupt? Normally, this should not happened.

    I think the direction will be to find the root cause that why MCU operates wrong. Can you help give more information?

    Eason

  • Hi Zhou,

    Thank you for your reply.

    We are currently continuing with the issue described below:

     https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1517333/msp430fr2633-half-a-day-after-starting-up-the-device-the-touch-sensor-does-not-respond 

     https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1549484/msp430fr2633-if-the-mcu-is-booted-with-the-electrostatic-sensor-sheet-attached-to-the-pcb-the-touch-panel-cannot-be-operated 

    Originally, we suspected that an NMI interrupt might be occurring because 3 out of 40 units experienced abnormal MCU shutdown.

    It is difficult to obtain hardware information from the customer, but we may be able to check some aspects on the software side.
    Please let us know if there is any specific information you would like to have.

    Additionally, we have learned that the microcontrollers mounted on the product boards were purchased about seven years ago.

    We are not sure about the storage conditions of the in-house inventory, but do you have any information on whether there were any known issues with older microcontrollers purchased at that time?

    Best Regards,

    Ito

  • Hi,

    Can you connect to the MCU without reset it? Then you can check where the CPU is now.

    Connect MCU in free run mode.docx

    Can you recreate this issue on your side easily?

    Does the problem happen when the whole product power on? After you reset the MCU, the MSP430 turns good?

    Eason

  • Hi Eason,

    Originally, on the defective board where LED1 would turn OFF within 1–2 days, I added the NMI handler code you previously provided below the main function in main.c and conducted a running test.
    As a result, after about two weeks, both LED1 and LED2 ended up in the OFF state.
    It seems that adding the NMI handler code tends to extend the number of days before the issue occurs.
    You mentioned that by doing a free run, we can determine the CPU’s position, but I don’t really understand the purpose of doing this. Could you please explain?

    Best Regards,

    Ito

  • Hi Ito,

    As you see, if it enters the NMI interrupt, the LED1 or LED2 should be on right? So from the test, the device doesn't enter the NMI interrupt. The reason why to connect the device in free run mode is that: I want to see when the issue happens, where the PC point is . If I connect the device by a reprogramming, it will reset the device. This work is to find the root cause. It can directly check Possible cause #2 - An unhandled system UNMI interrupt  and [Possible cause #1 Not waking from low power mode]

    I just go through the threads, the problem seems happen when the device work for days. Right? Can you ask customer to measure the VCC signal?

    Can you share the schematic as well?

    Eason

  • Hi Eason,

    Thank you for your reply.

    We have commented out the description for the low-power mode.
    We believe this should be fine, but is there any possibility that the operation is not guaranteed because this is an unintended usage?
    So far, it has been running for 10 days with the low-power mode code commented out.
    Previously, the microcontroller stopped after about two weeks.
    We will try the free-run mode.
    Although we haven’t measured for a long time, the ripple and other factors didn’t seem particularly abnormal.
    We will also try long-term measurements on this side.
    Best Regards,
    Ito
  • Hi K.Z,

    Nice to hear that if any more help need from your side. Please let me know.

    Eason

  • Hi Eason,

    Is it okay to measure without using low-power mode, given CapTivate's specifications?

    Best Regards,

    Ito

  • Hi K.Z,

    Yes. It will not influence.

    Eason

**Attention** This is a public forum