• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 80 subscribers
  • Views 335 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.

Original question:

MSP430F6779A: MCU behavior when something wrong e.g. ESD

MSP430FR2532: MSP430FR2532 ESD Test with CCS compiler problems

Eric Shieh
Prodigy 10 points

Part Number: MSP430FR2532

Tool/software:

Dear TI,

We performed ESD testing on the communication pins (SMBUS SDA/SCL)under the following conditions: 0.2 kV, 0.05 s/pulse, 40 times per cycle.
The results confirmed that the ESD impacted the MCU.
Using the same code compiled with both IAR and CCS,
we found that the CCS-compiled version triggered __TI_ISR_TRAP after ESD strikes,
causing the program to enter the WDT and reset the MCU.
In contrast, the IAR-compiled version did not exhibit this issue under the same ESD conditions.

We would like to ask:
Could this phenomenon be related to the CCS compiler?
Is it possible that ESD causes the program to enable unknown or unintended interrupts?
Could it be that the way we defined the interrupts is incorrect?

   
(From what I see in the .map file, it looks like all the interrupts are declared.)

We observed that the customer's printer may apply 5V to 10V pulses (approx. 200 ns) to the communication lines (SDA/SCL),which causes brief fluctuations on Vcc.
Could this kind of ultra-short overvoltage impact the MCU’s operation?
Do you think it is necessary to implement additional hardware protection for such transients?

We look forward to your expert opinion. Thank you!!

Eric Shieh

  • 0
    TI__Genius 9651 points

    Hi Eric,

    1. The difference you are noticing could be because of the CCS compiler. This is something we'd have to look into further. 
    2. I don't think ESD would enable unknown or unintended interrupts
    3. Your interrupt seems to be defined properly, but the comments don't quite align with what you have. I'm assuming they're small typos, but just wanted to point that out just in case.
    4. The ultra-short overvoltage will most definitely impact the MCU's operation. I would recommend implementing additional hardware protection for the transients you are observing. These can cause bit error, false start/stop conditions, damage the pins, and cause unpredictable behavior.

    Is Port_1 ISR the only interrupt handler your application utilizes? If not, please provide all of your interrupt handlers and the interrupts you intend to have enabled.

    Best,

    Owen

  • 0
    Guru 26425 points

    I can't think of any good reason to apply ESD test voltages directly to a MSP430 pin. There should be protection circuitry between the MSP430 and any ESD source. Even if it is just a series resistor to limit fault currents.

  • 0 in reply to Owen Li
    Prodigy 10 points

    Hi Owen,

    Thank you for your reply.

    2. We still have not yet identified the root cause of why ESD triggers __TI_ISR_TRAP, so we will continue investigating this issue.
    4. Thank you for your opinion. I will suggest to our EE engineers to consider adding protection against these ultra-short voltage transients.

    The interrupts we have enabled include WDT, RTC, PORT1, ADC, and USCI_B0.
    Interrupt handlers & enabled:
    (1)WDT
     

    (2)RTC


    (3)PORT1



    (4)ADC


    (5)USCI_B0


  • 0 in reply to David Schultz
    Prodigy 10 points

    Hi David,

    Yes, this ESD experiment is conducted on an already designed battery, and there are indeed surrounding circuits connected.
     

  • 0 in reply to Eric Shieh
    TI__Genius 9651 points

    Eric,

    I don't see anything wrong at first glance, but I would also suggest looking over this E2E thread. This might be helpful with determining if there are any issues with how your interrupts are defined. Looking through the User's Guide and msp430fr2532.h, I'm not seeing anything that raises any concerns.

    As you may know, you usually find yourself in the trap if the handler for an interrupt is not defined, so I'll have to look into this further. Also, thanks for sharing the screenshots of your code. Can you do one more check to see that you are not accidentally enabling any other interrupts? I will also try to find an answer regarding if CCS may be the reason why this is happening.

    [EDIT]: Is it somehow possible that any of the required definitions are not defined? This would result in none of your ISRs being defined, thus resulting with the program ending up in __TI_ISR_TRAP.

    Best,

    Owen

**Attention** This is a public forum