• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 79 subscribers
  • Views 306 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.

MSP430FR2512: Delay and Captivate Trigger on Negative or Positive Edge of IRQ?

Jay09
Expert 1030 points

Part Number: MSP430FR2512

Hi There,

I'm using the Captivate REGISTER_I2C interface, with the IRQ feature for notifying the host MCU. I do this with the utility function, I2CSlave_setRequestFlag() (which seems to do the thing).

My question is that on the host MCU, I was triggering on falling edge (the line is held high and gets pulled low, so the falling edge is the SOONEST I can be notified) but I notice that between my request and response i2c requests I need to add ~ 30ms delay in order to get a valid sensor packet. 

Switching to the positive edge allows me to remove the delay. 

Questions: 

1) Which edge should I trigger on?

2) What is the anticipated delay between the request / response?

3) Should I be waiting, or should I pull the i2c response until I get a valid checksum?

4) Should I be doing something else I'm not doing instead?

Putting timing code in feels inherently fragile to me, so I'm hoping someone can enlighten me as to what can be done to make the response as fast as possible while being reliable. My clock speed is 100kHZ, and I'm (for the moment) using internal pullups on the i2c lines. 

Thanks!!

  • +1
    TI__Mastermind 49692 points

    Hello,

    The IRQ code on the MSP430FR2512 uses __delay_cycles() to add a delay between the high-to-low and low-to-high transitions to establish a defined IRQ pulse width for notifying the host. The pulse width must be wide enough for the host to detect it.

    When you trigger the host on the first (high-to-low) transition, the host sends an I2C request to the MSP430FR2512. However, the MSP430FR2512's CPU is still executing the __delay_cycles() function before it can process the I2C command from the host. This is why adding your delay on the host works.

    When triggering on the second (low-to-high) transition, the MSP430FR2512 has finished executing __delay_cycles() and can immediately process the I2C command from the host. This is why a delay on the host is not necessary for this scenario.

    Both approaches are basically doing the same thing. If you'd like the fastest possible response, I'd trigger on the second (low-to-high transition) and try to reduce the __delay_cycles() count to a value that still ensures that the host detects the IRQ pulse.

    CCS/MSP430FR2522: IRQ available in BULK I2C but not in REGISTER_I2C

    Regards,

    James

  • 0 in reply to James Evans
    Expert 1030 points

    Hi James,

    Thanks for such a precise answer. It is much appreciated! 

**Attention** This is a public forum