XMC4500, I2C002 FIFO issue

[User7989]

Hello,

I have a hexagon kit (XMC4500 F144K1024 AB), and are trying to get the I2C002-app to work.

Started with the I2C002-example, but re-assigned the pins to U2C1, P4.2 (SCL) and P4.7 (SDA), since I need to use these in our final design.

But as soon as one of the threads calls I2C002_StartTransfer with the operator I2C002_WRITE will the program go into an endless loop inside of the standard transmit buffer event handler.

It seems like the statement below will never be fullfilled:
/*Check if TX FIFO is ready for next write*/
while((I2C002_Handle0.I2CRegs->TCSR & USIC_CH_TCSR_TDV_Msk) != USIC_CH_TCSR_TDV_Msk)

If i switch back to the original pin assignments (P5.8 and P2.14) will it go through the loop as it should.

Are there any limitations I have missed with this setup?
The external hardware is identical since i have added 2k2 pull-ups at P4.2 and P4.7.

[User7989]

I'm still stuck with this problem.

Can anyone with stepping AB or AC at least confirm if they can use U2C1, P4.2 (SCL) and P4.7 (SDA) for I2C-communication.

According to chapter 17.5.2.4 can this indicate an error condition, but I don't understand why it should when no data has been posted to TBUF.

[#3]

Hi andersr,

We manage to reproduce the similar issue you observed.
We are looking at this now.
Will update you when we found the root cause.

[User7989]

Hi Jackson,

I'm very happy to see that you are supporting me. Tried today to use the I2C001-app with protocol interrupt handling (same USIC), but It does not help: no data is clocked out and there are no interrupts generated.

Have a prototype PCB ready for manufacturing where the all USIC's are used and the I2C mapped as above. Do you estimate to have an answer within the next couple of days, or should i try to re-assign the I2C to another USIC, and start reworking the PCB?

It will of course also require me to have a UART or SPI master working on U2C1, i hope this will be possible... What are your thoughts here?

[#5]

Hi andersr,

As of today, we still couldn't find out the actual root cause.
I'm really sorry that I'm not sure when I can give you an answer for this issue.
Hence, if you need to finalise the PCB urgently, I would suggest you to change the I2C to other port first.
Using UART on U2C1 shouldn't be any problem as I have tried it myself using pin P3.11 for transmit and P3.5 for receive.

[User7989]

Hello Jackson,

I have now found the cause!

SDA must have both DOUT and DX0 functionality. P4.7, which i was using did not have DX0 for U2C1.

Have now changed SDA pin to P3.5 (still using U2C1), and can finally communicate over the bus. Have only tested with I2C001 so far, but I assume that I2C002 will work the same.

Many thanks for your help!
/Anders

[User7989]

I have a new question concerning the I2C interface (using I2C001-app, but might change back to 002 later)

Running the I2C as a master, and have an external ADC connected.

It might happend (if I access the ADC before a conversion is ready), that I will have a NACK back from the device.

When that happend, will all further access to the port be rejected (no data is clocked out from the USIC), and i don't understand how to recover from that state.

Have looked at some DAVE-examples, but none of the can handle fault conditions.

What i have found so far in the reference manual is that i should do:
I2C001_Handle0.I2CRegs->FMR |= (((uint32_t) 2) << USIC_CH_FMR_MTDV_Pos) & USIC_CH_FMR_MTDV_Msk;
USIC_FlushTxFIFO(I2C001_Handle0.I2CRegs);
USIC_FlushRxFIFO(I2C001_Handle0.I2CRegs);

I can see that the TCSR.TDV bit is cleared, but it does not help. Do you have any suggestions of what to do?

[#8]

Hi andersr,

Yes, it is exactly like what you have mentioned. The pin P4.7 does not have the DX input. That is why it is not possible for I2C communication.

For the case where NACK is received, a STOP condition will be sent.
Therefore, to send out data again, you need to repeat the transfer as a brand new transfer again.
Did you do it this way?

[User7989]

Hi Jackson,

Yes I started from scratch again, since everything that was previously posted to the FIFO was flushed away. From what i can see, have i fullfilled the recommendations from chapter 17.5.2.4.

But it seems like i need to take additional actions to recover from this state.

[#10]

Hello andersr,

maybe the XMC4500 reference manual on page 1685 (17-123) can help you. The last passage describes that in case a NACK is received, the above mentioned stop condition is sent and every TDF code is ignored except the TDF code for a repeated start condition. Have you tried this?

[#11]

thanks andersr.