• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 233 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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:

MSP430F5335 Crashing

MSP430F5438A: Question about implementing USCI39's suggested workaround

adevries
Intellectual 945 points
Part Number: MSP430F5438A

Hello TI Forum,

I am working on an application where a MSP430F5438A needs to act as an I2C target. Because of this, errata USCI39 applies to me, and I need to implement a workaround for this issue. The recommended workaround is, "Disable the UCSTTIE, UCSTPIE and UCNACKIE before the GIE is set. After GIE is set, the local interrupt enable flags can be set again". If I implement this workaround, will the act of disabling or re-enabling UCSTTIE, UCSTPIE and UCNACKIE potentially clear any unserviced interrupts or prevent an interrupt flag from occurring while disabled? Or will the interrupt flags be preserved and/or still be asserted while the IE's are disabled, and once the IE's are re-enabled, an interrupt can actually be generated and serviced?

Secondly, based on this forum post, it appears that there needs to be extra NOPs after re-enabling the IE registers, possibly based on the speed the MCU is running at. In my application, I am planning to run at 25 MHz, so if that is indeed the case, that would be good to know. Is there any new information available that might suggest how many extra NOPs are needed based on the MCU speed?

Lastly, again based on the linked forum post, it appears that the RETI instruction can trigger this behavior. Since that's the case, does anybody know of a way to force the compiler to replace the RETI instruction with a series of instructions that will disable the IE registers, enable GIE, re-enable the IE registers, then return from interrupt?

Thanks in advance for any assistance!

  • 0
    TI__Mastermind 38410 points

    Normally, The GIE setting is in the system init. I would advise you set the GIE first then init the I2C. So you would meet the problem.

    If you need to disable global interrupt and enable the global interrupt in task excuption time, please let me know, Then you need to consider USCI39.

    Then action of "disabling or re-enabling UCSTTIE, UCSTPIE and UCNACKIE" will only affect the related USCI peripheral, won't affect other peripheral.

  • 0 in reply to Eason Zhou
    Intellectual 945 points

    Hi Eason,

    Thanks for replying.

    Eason Zhou said:
    If you need to disable global interrupt and enable the global interrupt in task excuption time, please let me know, Then you need to consider USCI39.

    That was my first thought too. However, I am using interrupts from different modules in this code and, as I learned from the forum post (https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/462451/msp430f5335-crashing), anytime the MCU enters a interrupt routine GIE is disabled, and then re-enabled when it leaves. So by simply using interrupts in my code, I'm exposed to the problem of USCI39.

    Eason Zhou said:
    Then action of "disabling or re-enabling UCSTTIE, UCSTPIE and UCNACKIE" will only affect the related USCI peripheral, won't affect other peripheral.

    That doesn't quite answer my question. Let me ask it in a different way using an example.

    In cycle 0, GIE = 0, UCSTPIE = 1, UCSTTIE = 1, UCSTPIFG = 1, and UCSTTIFG = 0.

    In cycle 1, I set UCSTPIE = 0 and UCSTTIE = 0. Does this force UCSTPIFG = 0?

    In cycle 2, I set GIE=1

    In cycle 3, I set UCSTPIE = 1 and UCSTTIE = 1. Does this force UCSTPIFG = 0?

    My other question is if GIE = 0, UCSTPIE = 0, UCSTTIE = 0, UCSTPIFG = 1, and UCSTTIFG = 0, and then an I2C start condition happens, will UCSTPIFG be set to 0 and will UCSTTIFG = 1, even though GIE, UCSTPIE, and UCSTTIE = 0?

  • 0 in reply to adevries
    TI__Mastermind 38410 points

    1. See from the link given by you, yes if you use muti IRQ and not control the IRQ timing. It may happen this question. However, see from the description, it says GIE is set by software, which makes me a little confused. I would advise you to do some test under your real condition. Or you can directly control the IRQ timing or use UCTXIFG, UCRXIFG instead of these two flags to avoid it.

    2.  No, it will not force UCSTPIFG = 0. Only receive the START condition, it will automatically clear this bit.

    3. Not sure, as you enable the GIE, it will enter the IRQ. It may be cleared in the IRQ. But only think from hardware side, it will not clear this bit.

    4. Yes.  UCSTPIE, and UCSTTIE is used for enable related interrupt and they have no relationship with the flag settings. You even can judge and handle the status without IRQ by using while(1) directly.

**Attention** This is a public forum