I2C TX problem

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User8819
Level 4
Level 4
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
0 Likes
11 Replies
User13817
Level 3
Level 3
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:


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.
0 Likes
User8819
Level 4
Level 4
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
0 Likes
User10538
Level 3
Level 3
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!
0 Likes
User10538
Level 3
Level 3
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.
0 Likes
User8819
Level 4
Level 4
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
0 Likes
Not applicable
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!
0 Likes
User10538
Level 3
Level 3
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).
0 Likes
Not applicable
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.
0 Likes
User10696
Level 4
Level 4
First solution authored
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/threads/4733-I2C-Bus-hangs?p=16926#post16926
0 Likes
User21926
Level 1
Level 1
Hello,
I am using the I2C001_01 for comunicating with an EEPROM. The program runs on a XMC4400.
My problem is that during the communication sometimes the clock loses a tick and the bus stops comunicating.
On the help page it says that I am supposed to perform some actions in order to restart the comunications:

"In case non-acknowledge is received or when any other error condition occurs, the TCSR.TDV flag remains set,
but no further transmission will take place. The user software must invalidate the transmit buffer and disable transmissions (by writing FMRL.MTDV = 10B),
before configuring the transmission (by writing TBUF) again with appropriate values to react on the previous event.
Additionally the FIFO buffer needs to be flushed and filled again."

But i can´t find a way to access the flag TCSR.TDV.
And I don´t know how to appropriatly reconfigure the TBUF.
Any tips?
0 Likes
RN
Level 1
Level 1
First reply posted Welcome!

Try this:

USIC0_CH1->FMR |= 2UL << USIC_CH_FMR_MTDV_Pos;
USIC0_CH1->TRBSCR |= USIC_CH_TRBSCR_FLUSHTB_Msk;

(adapt USIC and channel)

No Support! A shame that Infineon is not reacting.

0 Likes