• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 214 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.

MSP430F437: Errata US13.. Need Additional Info about USART Module Errata..

Newman
Expert 5605 points
Part Number: MSP430F437

Hi Team MSP430,

My customer requests some additional info/data WRT MSP430F437 errata US13 as follows..

If a receive interrupt occurs during either of the 3 scenarios below, is there is a chance that the micro doesn’t service the USART RX ISR within the 2 bit times of defined by the errata above.  We are running the UART at 19200 so 2 bit periods is 105us. 

Is there potential for the errata to occur based on the 3 scenarios below.. and is there any way to prevent the scenarios below?  For example, could we disable the UART RX interrupt before the erase/write to info flash?

Scenario 1. Another interrupt has already triggered and the CPU is in another ISR. There are a few other ISRs active while the USART would be receiving packets.
  a) Basic Timer ISR
  b) TimerA1 Capture interrupts
  c) Period ADC Interrupts triggered by a background task

Scenario 2. During a flash write of non-volatile data, the CPU is halted while the Flash Controller erases or writes data to Info Flash

Scenario 3. The program disables the global interrupt before entering sleep mode (LPM3), but doesn’t disable the USART RX interrupt.

Additionally.. Is there a more detailed description for “Unpredictable Program Execution”
  a) Could the PC counter jump to an unexpected location in flash?
  b) Could variables overwrite in RAM?
  c) Could POR/WDT resets occur?

Thanks, Merril

Reference:

https://www.ti.com/lit/ds/symlink/msp430f437.pdf

https://www.ti.com/lit/ug/slau056l/slau056l.pdf

https://www.ti.com/lit/er/slaz208g/slaz208g.pdf

  • 0
    Guru 18885 points

    The errata is about the start bit detect interrupt so scenario 3 appears to conflict with its use. Which is to bring the CPU out of a low power mode where the clock used by the UART is disabled.

    The URXSE bit controls generation of this interrupt so unless it is set, there shouldn't be a problem.

  • 0
    TI__Mastermind 26420 points

    Hey Merril,

    I wasn't able to find much more info but it seems that the start bit detection interrupt is requested at the first edge, indicating a start bit incoming.  But it gets auto cleared a few bits later, after the Start bit has been received.  It seems that there is a time window (I guess at the end of the 2nd bit) in which the interrupt flag is cleared but the MSP430 still thinks there is an interrupt pending.  If allowed, It will try to service an interrupt but find no flag set to point it to the correct vector.  So it can end up jumping to a random ISR vector.   

    I believe scenario 1 is the main risk factor here, and the only way to protect against it would to make sure your ISRs are short enough to still meet the errata response time requirements. 

    For scenario 2 & 3, if the GIE or the USCI interrupt are disabled then I don't think there should be an issue as there will never be an actual interrupt request.  (I believe all interrupts should be disabled before FLASH erase and writes.)

    Hope this helps.  Thanks,

    JD 

  • 0 in reply to JD Crutchfield
    Guru 92251 points

    JD Crutchfield said:
    It seems that there is a time window (I guess at the end of the 2nd bit) in which the interrupt flag is cleared but the MSP430 still thinks there is an interrupt pending.  If allowed, It will try to service an interrupt but find no flag set to point it to the correct vector.  So it can end up jumping to a random ISR vector. 

    Could the "jumping to a random ISR vector" happen for other interrupt sources if their flag gets cleared before the interrupt has been serviced?

    MSP430FR5994: Strange/Undocumented behavior when disabling/enabling individual timer interrupts was an issue on a different MSP430 whereby clearing the CCIE bit for a "lock-free" technique could cause a jump to the wrong address, for reasons which were not understood.

  • 0 in reply to Chester Gillon
    TI__Mastermind 26420 points

    Hey Chester,

    Honestly, I'm really not sure but I don't think so... At least in this case, it seemed to be an errata with the USCI module interrupt requests, that would have been possible to fix with another hardware revision. 

    I don't think this is going to give much insight into the FR5xx device which came several generations later.   

    Thanks,

    JD

**Attention** This is a public forum