• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 224 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.

MSPM0G3507: MSPM0G3507_I2C_Interrupt

sato takuya
Prodigy 10 points

Part Number: MSPM0G3507

Q1. Is my understanding right about TX FIFO Trigger?

TXFIFOTRG occured when TXFIFO is empty because it meets the condition "transmit FIFO contains <= defined bytes", I think.

 

Q2. I found that after executing the following functions, TXFIFOTRG is occured in RIS Register (Offset = 1030h). Is this the desired behavior?

(1) DL_I2C_enableTarget

(2) NVIC_EnableIRQ

(3) DL_I2C_flushTargetTXFIFO

 

The conditions related to I2C peripheral are as below.

Frequency = 100kHz, TX FIFO Trigger Level = 1byte, No masked for interrupt status.

 

(1) and (2): At initialization of I2C function, there is no I2C communication, or TXFIFO is empty.

(3): After TX FIFO is flushed, TXFIFO is empty.

 

Q3. Should I mask the interrupt status not to occure TX FIFO Trigger?

 

  • 0
    Guru 101825 points

    As a Target (I2C slave) I suspect you want the TXEMPTY_ON_TREQ feature (DL_I2C_enableTargetTXEmptyOnTXRequest()) [Ref TRM (SLAU846C) Sec 24.2.3.12.1]. With that set, you will only get a STXEMPTY during a transaction, not when idle.

    Unsolicited: You may also want TXWAIT_STALE_TXFIFO (DL_I2C_enableTargetTXWaitWhenTXFIFOStale()) [Ref same TRM section]. This gives you a chance to flush the Tx FIFO if you over-filled it during the previous transaction.

  • 0 in reply to Bruce McKenney
    Prodigy 10 points

    Hi Bruce-san,

    Thank you for your comments.

    Your suggestion might be fruitful for my development.

    But could you reply to my 3 questions because I want to be clear first?

    I appreciate your support.

  • 0
    Guru 101825 points

    Q1: Yes, generally. The interrupt condition (RIS) occurs:

    a) In normal operation: When the Tx FIFO level crosses the TXTRIG (counting down). Flushing an empty FIFO doesn't trigger the interrupt.

    b) When the Target is enabled (SCTR:ACTIVE := 1) and the TxFIFO level is below TXTRIG

    These happen independently of whether there is a transaction in progress.

    Q2: Yes, this is expected behavior. My observation is that it is the enableTarget() that triggers the interrupt condition. Flushing a non-empty FIFO (above TXTRIG) will also trigger it, but I think that's not the case you're describing.

    Q3: Generally, I would say yes, you should disable the trigger when there's no active transaction. I say this only because in general a Target doesn't know ahead of time what data the Controller will ask for. [This is where TXEMPTY_ON_TREQ comes in.] I suppose there could be applications where the Target knows this in advance in which case you could use the trigger to pre-load the FIFO. 

  • 0 in reply to Bruce McKenney
    Prodigy 10 points

    Hi Bruce-san,

    My understanding is as below. If there are wrong points, please let me know.

    a) DL_I2C_enableTarget, NVIC_EnableIRQ and flushing TxFIFO are trigger the interrupt TXFIFOTRG.

    b) Flushing TxFIFO is different by the below conditions. 

       b-1) TxFIFO = empty --> No interrupt

       b-2) TxFIFO <> empty --> Trigger the interrupt

    c) Before the desired I2C transaction, I should mask the interrupt status.

    And I wonder how to handle FIFO TRG level.

    For example, when I want to cope with the I2C data as only 1 byte, or not multiple bytes in TX/RX FIFO, I select the below setting, is it right?

    RX Trigger Level: RX FIFO contains >= 1 bytes

    TX Trigger Level: TX FIFO contains <= 0 bytes

    I appreciate your support.

  • +1 in reply to sato takuya
    Guru 101825 points

    a) DL_I2C_enableTarget and flushing TxFIFO can each trigger TXFIFOTRG [based on Q1:(b)/(a) respectively]. NVIC_EnableIRQ won't (in itself) trigger TXFIFOTRG; it merely allows that condition to propagate to the CPU (ISR).

    b) Yes.

    c) Yes. For small transactions, a low trigger level will make your Target more responsive. I2C has flow control (clock stretching) so no data will be lost. If you were (someday) to deal with larger transfers, loading up the FIFOs can make things faster.

  • 0 in reply to Bruce McKenney
    Prodigy 10 points

    Hi Bruce-san,

    Thank you for your explanation.

    I would like to use mask the interrupt status at the I2C peripheral initialization, or before the desired transaction.

    And I also refer STALE_TXFIFO flag to use flushing TXFIFO at proper timing.