TDA4VM: query for TDA4's I2C operation with GIC 233

Hi,

Could you please provide some further background.  Which SDK is being used (OS, version), and which Core the the I2C driver is being run on (A72, A53, R5).   

General response is that there are no known issues with I2C. 

Some items to check would be

• Is the Interrupt Service routine is servicing interrupts correctly,
• Make sure that there is only one I2C driver controlling the I2C bus where test is being run.  The I2C driver for a given bus should not be running on multiple cores
• Regarding GIC233, when is it seen to go high, and why is being held high?

Regards,

kb

Hi kb, 

Here is the information about SDK and Core. 

SDK version
PSDKLA : 8.1
PSDKRA : 8.1
EDGE AI : 8.1
I2C driver : A72(Linux)

I checked register document, there are some uncertainties. 

could you check it's status meaning ? 

Q1) in Table 12-392, bit [12] <-- 0 is busy ? or 1 is busy ? 

Q2) in Same table, bit [10] <-- 0 is uflow ? or 1 is uflow ? 

Regards, 

Hi Minu,

If the question is about the above tables from the TRM, I have read the physical addresses using devmem2 with no user application running that uses I2C. Bits 12 and 10 were always 0, so I think it is safe to assume 1 means busy and 1 means uflow.

I have looped in others from TI side to get confirmation, but in the meantime, were you able to check out some of the things my colleague Kip suggested?

Regards,

Takuma

Hi Takuma, 

Thanks for you answer. 

but it's so weird, which means that the value of reading IRQ_STAT regs are different. 

I already wrote my problem : 

(1) when I try to use I2C command, normally it's ok for I2C operation, 

  e.g>  (send 1st I2C command) => (ACK recevied) => (send 2nd I2C command) => (ACK received) .. 

(2) but, when GIC 233 = high, it looks like that I2C working is not correct. 

  e.g>  (send 1st I2C command) => (ACK recevied) => (send 2nd I2C command) => (no response) & time-out error is occured ! 

If I read the IRQ_STAT (I2C_IRQSTATUS_RAW = 0x24h)

- when normal operation in (1), IRQ_STAT = 0x1010 -> 0x1410 -> 0x1000 

- but, when fail operation in (2), IRQ_STAT = 0x10 -> 0x10 -> 0x0 

it looks like that, in normal operatoin BB is high, (for your explanation, it's on busy & uflow)  

but in fail operation, BB is Low (not busy & not uflow) 

it's not easy to understand the current situation for debug. 

is there any other trace for further debugging ? 

Regards, 

Minu Song said:

GIC 233 = high

Could you elaborate a bit on why does this go high? How is this going high?
I will need more details on which instance of I2C & steps to reproduce on TDA4VM TI EVM?

- Keerthy

Basically I want to know the relation between I2C fail & GIC 233. 

but from TI's about answers, it seems that this situation is not normal, and I guess, I have to check I2C waveform at first. 

I will check I2C waveform and after some analysis, I will ask it again.