• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 80 subscribers
  • Views 413 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:

MSP430F5438A: Question about implementing USCI39's suggested workaround

MSP430F5438A: How to trigger USCI39?

adevries
Intellectual 955 points

Part Number: MSP430F5438A

Hello TI Forum,

I am attempting to cause unpredictable code execution via the USCI39 issue, and so far I have been unable to. The motivation for this is to prove that it affects our microcontrollers so I can justify updating the existing firmware that seems to be running okay. I read the following forum posts to better understand the issue:

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/409917/help-on-dealing-with-usci39-on-a-5xx-msp430

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/462451/msp430f5335-crashing

According to the errata, "this erratum is triggered if ALL of the following events occur in following order:
1. Pending Interrupt: One of the UCxIFG=1 AND UCxIE=1 while GIE=0
2. The GIE is set by software (e.g. EINT)
3. The pending interrupt is cleared by hardware (external I2C event) in a time window of 1 MCLK clock cycle after the "EINT" instruction is executed."

So, I have been attempting to create those events and therefore cause unpredictable code execution. I have a test setup where two microcontrollers are talking to each other over I2C and a couple GPIO lines. An MSP430F5438A-EP is configured as an I2C target, and a Tiva-TM4C is configured as an I2C controller. These are the steps I am following:

1. MSP430 disables GIE, then drives a GPIO line low.

2. The GPIO line going low triggers the TIVA to send an I2C start command addressed to the MSP430

3. MSP430 drives the GPIO line high, executes 8 NOPs, then enables global interrupts

4. The GPIO line going high triggers the TIVA to send an I2C stop command.

What I am trying to accomplish is to create a pending UCSTTIFG in the MSP430 while GIE = 0, then setting GIE=1, and in the following MCLK cycle clearing the UCSTTIFG by causing a UCSTPIFG.

I have been using an oscilloscope to verify the signal timing, and by using this and adding a precise number of NOPs, I feel like I've gotten pretty close to where I need to be. I can generate the I2C stop signal precisely enough that, for one test I can see the MSP430 call the UCSTPIFG ISR; and by delaying the I2C stop command by 24 nanoseconds on the next test I can see the MSP430 call the UCSTTIFG ISR followed by the UCSTPIFG ISR.

So while I am able to precisely control this I2C stop command and make the MSP430 "oscillate" between executing 1 ISR or 2 ISRs, I can't seem to cause the unpredictable code execution. Does anyone have any ideas for what I might be doing wrong? Or do I magically have a MSP430F5438A that somehow isn't affected by this issue?

  • +1
    Guru 26155 points

    The problem is caused by the interrupt hardware getting confused. It recognizes that it needs to service an interrupt and begins that process. Then the interrupt source is pulled out from under it. (Hardware clearable being the key variable.) So when it calculates the vector address, it has no interrupt source to use. So the vector fetched could come from who knows where. Assuming no other interrupts are pending of course.

    But you have the stop interrupt enabled so by clearing the start condition interrupt you also provide a stop condition. That will not do it.

  • 0 in reply to David Schultz
    Intellectual 955 points

    Hi David,

    Thanks for the reply! If I'm understanding you correctly, the issue with my setup is that I have both UCSTTIE and UCSTPIE enabled. If I only have UCSTTIE enabled, that will trigger the unpredictable code execution, because the MSP430 will attempt to service UCSTTIFG but it will get cleared before it can calculate the vector address.

    Does this mean that, as long as I have UCSTTIE, UCSTPIE and UCNACKIE enabled, the MSP430 is immune to this issue? Since the only thing that would clear UCSTTIFG is UCSPIFG?

  • 0 in reply to adevries
    Guru 26155 points

    I don't know the details of the hardware so can't say if you would be immune. I have said it before but a spurious interrupt vector (which some other processors have) would have been real handy here.

    If you manage to be able to reliably trigger the fault you might want to see if you can figure out which vector is being used. Hopefully one of the defined ones as space at the start of the vector area tends to get repurposed as BSL passwords and such.

    If it is one of the defined vectors, then providing a default handler might solve the problem.

  • 0 in reply to David Schultz
    Intellectual 955 points

    Hi David,

    Okay, thanks for the advice! I will try disabling UCSTPIE and see if that means I can consistently recreate the issue.

**Attention** This is a public forum