infineon4engineers Facebook

infineon@google+ Google+

infineon@linkedin linkedin

infineon4engi@twitter twitter

infineon@youtube youtube

+ Reply to Thread
Results 1 to 10 of 10

Thread: I2C TX problem

  1. #1
    New Member New Member rum will become famous soon enough
    Join Date
    Jul 2014
    Posts
    120
    Points
    225.3125

    I2C TX problem

    Hello,

    I am using USIC in I2C mode with tx fifo. Sometimes for "unknown reasons" (because no error flags or interrupts are indicate there is a problem) the transmission stops. No data is coming out on bus.
    Manual says that "user must invalidate tx buffer" by writting FMR.MTDV=2 and flush TX fifo before next write to FIFO. I do this operation before every I2C packet transmission. But if the TX stops, this sequence is not able to restart transmissions.
    I have to reset and reinitialize completely USIC.

    TCSR.TDSSM=1,TDEN=1
    When error occurs TCSR.TDV=1, TCSR.TE=1, TCSR.TV=1
    after FMR.MTDV=2
    TCSR.TDV=0, TCSR.TE=0, TCSR.TV=1

    What operations are needed to restart transmission? What else to check?

    rum

  2. #2
    Beginner Beginner persike will become famous soon enough
    Join Date
    Sep 2017
    Location
    Austria
    Posts
    34
    Points
    375
    Are you using Dave 4?
    I had the same problem with it. I "solved" re-starting the I2C App every time that I want to communicate:

    Code:
    I2C_MASTER_Init(&I2C_MASTER_0); // if you don't force an init everytime before a communication the protocol doesn't work
    I2C_MASTER_Transmit(&I2C_MASTER_0,true,SENSOR_WRITE_ADDRESS,&i2c_data,1,false);
    The problem is that this took much time. I'm interested on solving this also.

  3. #3
    New Member New Member rum will become famous soon enough
    Join Date
    Jul 2014
    Posts
    120
    Points
    225.3125
    Hello,

    I am not using DAVE apps but my own code. I've pinpointed the problem as described above. Also simple I2C example shipped with DAVE fails. It must be silicon bug. I hope someone from Infineon support will respond to this thread and give explanation. PLEASE RESPOND AND GET AWARDED!

    rum

  4. #4
    New Member New Member andyl is on a distinguished road
    Join Date
    Sep 2015
    Posts
    39
    Points
    226.71875
    I have the same problem!!
    I'm using the Interrupt Mode with all the Error Interrupts enabled.
    With specific I2C Peripherals conncected to the Bus I regularily get this situation.
    The Bus is in idle state (messured with my logic analyzer and scope), both SDA, SCL high. The drivers also respond with SUCCESS at Rx and Tx both, and yet no more data is clocked out until I reset the I2C USIC Module!

    @Infineon: Please give at least a fast recovery solution: calling I2C_MASTER_Init(&I2C_MASTER_0); takes way to long before every transmission!

  5. #5
    New Member New Member andyl is on a distinguished road
    Join Date
    Sep 2015
    Posts
    39
    Points
    226.71875
    To give more detail, what I see happening is the following:
    1) I communicate with the device successfully for the first time (which unfortunately uses an active bus driver Fairchild FXMAR2102 to drive the edges in both directions very fast in the ns region, maybe this is the problem?).
    2) Now the device "wakes up" and produces some glitches on the SDA and SCL Lines (a lot of short bursts <100ns).
    3) the I2C Protocol Error interrupt triggers sometimes but not always (but at this point I do not use I2C, this happens way after the transaction (1) is finished on the now idle bus before I later start a new I2C transfer. So these glitches should be completely ignored by the I2C Master and also there should be no interrupt happening. No Idea why this happens...)
    4) after this event the bus remains free (both lines high), registers as decribed by @rum, the DAVE drivers accept new transactions wie SUCCESS and yet until reset nothing is clocked out.
    Last edited by andyl; Dec 1st, 2017 at 01:47 AM.

  6. #6
    New Member New Member rum will become famous soon enough
    Join Date
    Jul 2014
    Posts
    120
    Points
    225.3125
    Hello,

    This is my workaround solution. I am using TX FIFO. Before each tx I check result of previous tx

    // workaround to get transmission running again after it gets stuck after some error on i2c (usually ERR)
    // last byte transmitted is stop with data equal to zero
    // if content of transmit buffer if different from zero means transmission is stuck
    if(USIC1_CH0->TBUF[0] & 0x000000FFUL){

    // disable and enable USIC channel, not sure if NOPs are needed
    USIC1_CH0->CCR &= ~((uint32_t)USIC_CH_CCR_MODE_Msk);
    __NOP();
    __NOP();
    __NOP();
    USIC1_CH0->CCR |= ((uint32_t)(I2C_MODE) & USIC_CH_CCR_MODE_Msk);
    }

    adjust for your USIC and channel

    rum

  7. #7
    New Member New Member acassis is on a distinguished road
    Join Date
    Nov 2017
    Posts
    5
    Points
    45
    Hi rum,
    Thank you for this work-around. I hope Infineon fix these USIC BUGs in the next Silicon Tape-Out.

    Their MCUs has a good set of peripherals, good price, etc... but hey Infineon you can do better! Come on! Fix these tons of BUGs in the silicon!

  8. #8
    New Member New Member andyl is on a distinguished road
    Join Date
    Sep 2015
    Posts
    39
    Points
    226.71875
    Thank you rum,

    I use it without the nops which seems to work also.

    I noticed that theses errors tend to cluser, meaning I often get ERR, then a couple of Timeouts (which is my way of detecting that the peripherie stopped working) and then it works again for quite some time.
    If I remove both the I2C devices with this Fairchild FXMAR2102 buffer, I practically never get an Error/Lockup (but this is of course no solution, as I need them).

  9. #9
    Beginner Beginner xiaowo is on a distinguished road
    Join Date
    Jul 2017
    Posts
    14
    Points
    80
    I haven't read all your problems in detail now, but i also had problems with the SCL and SDA line. After many checks, i could find the solution in enabling the digital filter of the USIC:

    I2C001_Handle0.I2CRegs->DX0CR|=USIC_CH_DX0CR_DFEN_Msk;
    I2C001_Handle0.I2CRegs->DX1CR|=USIC_CH_DX1CR_DFEN_Msk;

    This also helped me at I2C and also at the same problem at the SPI.

  10. #10
    Beginner Beginner amanning will become famous soon enough
    Join Date
    Oct 2015
    Posts
    64
    Points
    71.5625
    I had the same problem and implemented a work-around.
    If the data cannot be sent I unblock the bus by pulling the data line low for a short pulse, afterwards the bus works again as expected. This can be done by directly setting the port pin.

    It's horrible, but solved our problem of the bus blocking during ESD tests.

    See my post at: https://www.infineonforums.com/threa...6926#post16926

+ Reply to Thread
Disclaimer

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.


Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.


Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.