TC397 操作I2C 寄存器的时候发生Trap

[wangchenyu01]

你好，

背景：我这边使用TC397实现I2C 读写时候出发了Trap，对I2C操作分布在core0 与Core4

发生Trap 后对应的信息如下

DATR 寄存器的SBE 置位1

DEADD 寄存器显示F00E8000

请问发生这一故障的原因是什么 ？如何复现

[wangchenyu01]

maybe i should descrip this issue by english 

background: my team find the sw happen a trap , after analysis and debug , we find the trap class4 Tid3.   in the register DATR , the SBE is setted , and the DEADD is 0XF00E8000(this address is the I2C FIFO TX address). the core0 and core4 write and read the I2C1 device.

could you please support me to make this issue happen quickly , and please tell me which operation will lead to this issue

[Ken_Yeung]

Hello ChenYu,

  It seems that the problem is due to DAE - Data Access Asynchronous Error (TIN3).

And, DATR SBE is set. It means that it is a store bus error.

  Based on the provided information, please check chapter 34.3.1.6.7 Switching between Transmission and Reception.

--> "If the software wants to write to the register TXD when the FIFO in RX state, then this causes a bus error."

  Besides, would you help to explain why both core0 and core4 will use I2C1 device? or, it is already a mechanism to protect the I2C1 device not access by different core at the same time in your system.

BR

Ken Yeung

[wangchenyu01]

hi Ken Yeung

thank you for your support firstly, regarding to the access the I2C device by Core0 and Core4 , it just a mistake by my sides. 

could you please provide a demo support me make this trap happen ? thank you so a lot again .

[wangchenyu01]

I have another question want to inquiry.

1.will sw has to reset after this trap happen?

2.can sw only operate the i2c bus when the bus status is free?

3. seemly we need not to do any thing for the switch between write and read,it just switch by hw automatically. sw only need to monitor the bus status then operate bus according to the bus status?

[Ken_Yeung]

Hi,

 Reply Q1) it is not a must. it depends what need to handle for this trap.  And, what is the target application.

 Reply Q2 & 3) The i2c module hardware complete most operations without software interaction. For example, you can refer to the Master Process Sub-state machine Figure 336. It shows which operations are done by HW or SW. 

BR

Ken Yeung

[wangchenyu01]

hi Ken Yeung

thank you so a lot for your deeply analysis.

I checked the i2c library interface, and I found the read and write interface that you mentioned.I found there is interface called in order to release i2c bus and block it by while.

if I change this release interface and ask the sw jump out this block status after check i2c bus status three time.  

base on this assumption.if i call the read and write interface by only core0. i think the sw could get into trap sometimes. am I right?

[Ken_Yeung · Accepted solution]

Hi ChenYu,

  You may find in Ifxi2c_i2c.c, for function IfxI2c_I2c_read.

Two case for (i) size > 32 or (ii) size <=32

for case (i) start at line 216, since the FIFO is not enough to receive all the data, the software read  4 bytes (except the end case) from the FIFO once it is ready.  So, until it reads all requested data. The FIFO will still in RX state. If you write TXD in this time, it will trigger the Bus Error.

For case (ii) start at line 306, it will wait until the protocol transmission end in the while loop at line 308.

while (IfxI2c_getProtocolInterruptSourceStatus(i2c, IfxI2c_ProtocolInterruptSource_transmissionEnd) == FALSE)

  So, if you do a TXD write in this while loop, it will also trigger the bus error.

   However, I did not able to test my suggestion with HW now. If you find any problem, please let me know.

BR

Ken Yeung 

[wangchenyu01]

let me provide a info 

we get the I2C driver from the website as following:

GitHub - Infineon/AURIX_code_examples: This repository contains code example projects for the AURIX™...

could you please support me check if the diriver have some issue?

[Ken_Yeung]

Hi ChenYu,

  The i2c sample code does not have this issue if only one core call the function. For example, IfxI2c_I2c_read, it is blocking operation. So, it will complete the RX operation before TXD  write.

  If you want to make a Bus error trap happen, you may modify the sample code and try to write the TXD when i2c kernel is still in RX state (check some while loop in IfxI2c_I2c_read).

BR

Ken Yeung

[wangchenyu01]

Thank you so a lot.

[araamse9]

thank you for your support firstly, regarding to the access the I2C device by Core0 and Core4 , it just a mistake by my sides.  teatv download

hellodear.in

[wangchenyu01]

I check the read and write interface in the library. the sw call interface release i2c bus at the end of read and write operations.if we change the interface to jump out the block status. 

in this assumption.could the sw get into the trap by one core?

I think it's possible. am I right?