I2C driver

cancel
Showing results for 
Search instead for 
Did you mean: 

I2C driver

Jump to solution
393 Views
shany
Contributor II

Hello,

I have a strange problem with the I2c driver and I'm starting to run out of ideas.

I'm working on imx28 self designed board and I'm trying to perform simple read and write operations from a device working on i2c bus.

I'm working according to the I2C bus example I found in \WINCE600\SUPPORT_PDK1_9\APP\EEPROM_24LCxxx_I2C_Test and adjusted it to my system.

I've made a certain progress in the I2C driver, however, I still have a few questions

I have 2 problems:

     (a) I can't perform a READ operation. Whenever, I send a READ command to the bus (after a write command with a slave address), it sends the first packet           (slave+read bit), the device ACKs and that's it. There are no more clock cycles after this packet was sent.

     (b) So now,  I'm sending only WRITE command, and after the slave, I'm writing 0xFF byte to the bus. I can see in the scope that the device responds with           data, but I can't read it, cause it's a WRITE command. How can I perform READ operation?

How can I take the information out of the DMA buffers and return it?

Thanks,

Shany


Labels (1)
0 Kudos
1 Solution
69 Views
yossishukron
Contributor III

I think that the best approach would be to compare the behavior you are seeing when you try to access your hardware with the behavior of a working I2C hardware.

And then to try and figure out what is missing to the I2C protocol when you try to access your hardware.


View solution in original post

0 Kudos
2 Replies
69 Views
shany
Contributor II

Hello,

Another thing I forgot to mention, I found a bug in the driver - when writing more than 1 byte, the driver sends another START signal. I've changed it, and now, it works fine, but I'm still not able to perform READ operation. the change is in this file -

WINCE600\PLATFORM\COMMON\SRC\SOC\MX28_FSL_V2_PDK1_9\I2C\PDK\i2cClass.cpp .

In the function ProcessPackets.


0 Kudos
70 Views
yossishukron
Contributor III

I think that the best approach would be to compare the behavior you are seeing when you try to access your hardware with the behavior of a working I2C hardware.

And then to try and figure out what is missing to the I2C protocol when you try to access your hardware.


View solution in original post

0 Kudos