• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 82 subscribers
  • Views 110 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.

SM320F28335-HT: Two stacked microcontrolers failure

Sandra Jimenez Martinez
Prodigy 40 points

Part Number: SM320F28335-HT

Good morning,

We have two SM320F28335GBS microcontrollers mounted on a stacked system. Initially, they were running independently and everything worked correctly.

Later on, we enabled communication between them via SPI. The SPI communication worked correctly during normal operation. The system topology was as follows:

  • One PCB communicated with an external node via CAN bus
  • This PCB then communicated with the second PCB via SPI
  • Data was exchanged back and forth repeatedly without any issues

After this had been running correctly, the system was powered off and on again (only to change a very minor configuration parameter; no hardware modifications were made).

Upon powering the system back on, we observed:

  • An abnormally high current consumption
  • Both DSPs stopped functioning
  • On one device, VDD1.8V is shorted to GND
  • On the other device, VDD1.8V and VDD3.3V (both analog and digital) are shorted to GND
  • Additionally, VDD1.8V and VDD3.3V are shorted together, i.e. there is continuity not only to GND but also between the supply rails themselves

The rest of the PCBs in the stack (including the power supply boards) are not affected and do not show any abnormal shorts.

There are no series resistors, buffers, or level shifters on the SPI or SCI lines between the two DSPs. The GPIOs are configured as inputs during initialization, with internal pull-ups enabled by default.

At this point, the DSPs appear to be permanently damaged.

We would appreciate any insight into:

  • Possible latch-up or back-powering scenarios through GPIOs during power-down / power-up conditions
  • Recommended protection measures for SPI/SCI interfaces between two F28335 devices, especially in stacked or shared-power systems

I don't really understand what happened so any help will be appreciated.

Thank you in advance for your help.

  • 0
    TI__Mastermind 22851 points

    Hi Sandra,

    Can you give a little more details on your system? Is there high voltage present, is there proper isolation between digital and analog grounds, is there a lot of noise on the PCB or power rails? What is the power supply board input and output specifications? During power down was any spark or potential short observed?

    Regards,

    Peter

  • 0
    Prodigy 40 points

    Hello Peter,

    Thank you for your response.

    The analog and digital grounds are the same. There isn't any high voltage or noise and there wasn't any spark nor abnormal situation.

    The power supply pcb input is 28V and the outputs are 3.3V, 1.8V for the microcontroller and others for the function PCB. However, neither the power supply or the functionality boards were damaged, just the uC.

    Thank you again,

    Best regards

  • 0 in reply to Sandra Jimenez Martinez
    TI__Mastermind 22851 points

    Hi Sandra,

    Thanks for the extra details. Are the uC devices also experiencing abnormally high temperature? Are you able to use a thermal camera to document? Typically, faults like these occur when the voltage connected to any of the device pins exceeds the VDDIO/VDDA voltage (typically 3.3V + 0.3V). This will adversely affect the device and damage it. Since this affects more than 1 uC at a time, this is most likely a system-level issue as opposed to device-level. 

    For the CAN/SPI middle node, what device is this? Potential damage can also occur when the power rails are not powered on and off properly (refer to the datasheet it should have a diagram specifically) . There is a specific sequence

    Regards,

    Peter

  • 0 in reply to Peter Luong
    Prodigy 40 points

    Hi Peter,

    The uC were not experiencing any high temperature (as they are currently shortcircuited I would prefer not to power them on right now). As for the system, it has been tested individually and it is not being problematic. Apart from that, we have another stack working since january with one extra PCB with the same uC and not a single error has happened. The problems come when the two uC PCBs are stacked and interact between them (as when they are doing different tasks there isnt any problem either) so the problem seems to be there.

    For the SPI, the signals are connected directly (tx with rx but there isnt any extra device). Idem for the CAN. The only things we do have are commercial isolators (ISO1050DUB and MAX1430)

    Best regards

  • 0 in reply to Sandra Jimenez Martinez
    TI__Mastermind 22851 points

    Hi Sandra,

    Based on the additional info, there's nothing you mentioned that would easily point to an obvious issue. Let me discuss this issue with my team and see if there are any other possible causes for this. In the mean time, are you able to replace the uC with a known good device for additional testing?

    Regards,

    Peter

  • 0 in reply to Peter Luong
    Prodigy 40 points

    Hi Peter,

    I have some new information:

    We have identified behavior that appears to depend on whether the JTAG programmer remains connected after flashing. When the programmer stays connected, flashing completes successfully and the system initially works as expected; however, after a power OFF/ON cycle, incorrect behavior appears and persists across further power cycles. If the programmer is then disconnected, the system immediately returns to correct operation and remains stable even after additional power OFF/ON cycles. In contrast, when the programmer is disconnected immediately after flashing, correct behavior is always observed, independently of power cycling or power‑up/power‑down order.

    Based on these observations, our main suspicion regarding the original destructive failure is the following: PCB µC 1 was reprogrammed while the programmer was connected and, after flashing, remained in an undefined or partially driven I/O state influenced by the JTAG connection during power‑up. At the same time, PCB µC 2 attempted to start SPI communication. During this window, one device may have been actively driving a logic level opposite to the other (for example, one device forcing a LOW while the other had the SPI pin pulled HIGH by default, as GPIO pull‑ups are enabled by default according to the datasheet). This situation could have led to excessive current through the SPI GPIOs, potentially triggering latch‑up or permanent silicon damage.

    What we find particularly concerning is that this behavior is only observed on one of the two boards (although they are practically the same board and they are identically designed).

    This behavior is not observed in configurations that do not involve this interaction, which reinforces our hypothesis that the combination of reprogramming, keeping the programmer connected during power cycling, and having unprotected SPI lines between PCB µC 1 and PCB µC 2 played a key role in the failure.

    what is your opinion?? is this a normal behavior??

    Best regards

  • 0 in reply to Sandra Jimenez Martinez
    TI__Mastermind 22851 points

    Hi Sandra,

    Thanks for the additional information, let me look into this in more detail. I will get back to you

    Regards,

    Peter

  • 0 in reply to Peter Luong
    TI__Mastermind 22851 points

    Hi Sandra, I am still looking into this