am3358 I2C problem

Moving this to the Starterware forum.

Not my platform. Not sure if I can help. No other takers so far. A few questions.

You mention modifying the Accelerometer example to access the EEPROM. Have you tried the EEPROM examples? Those access 50 bytes. In my opinion, the EEPROM examples should regarded as just a demo and not a start to a usable library. A lot of hard-coded values and global values.

In your tests, what EEPROM addresses are you using? Your results give the impression that you are writing to one address and reading from another address. It also possible you are crossing a page boundary. With larger writes, you could be going past the the burst write limit.

Hi Norman,

The EEPROM example

1) uses I2C0 for internal EEPROM while I need I2C1 as its pins available on the header.

2) reads ONLY not write

The Acceleration example uses I2C1, so I just want to make sure I'm using the right module with all settings from TI. But both behaves the same with my mod to eeprom using I2C0

I believe there's a real big problem in design the HW core I2C of AM3358. It is claimed to be high-speed but compared to a 8-bit ATMEGA 16MHz, it's not faster, even with system clock of 750MHz but I2C clk limited to 12 MHz!!!

Look at 4000+ pages of the manual, I got the feeling that the designers just simply throw everything available to them into this MCU and leave all problems for E2E forum to figure how to get around !?!?

I tried with all kind of methods : interrupt, polling, buffering, ... all behaves the same, really broken. All examples use interrupt! Now StarerWare overuses interrupt for everything SPI, I2C, ... I have a rule of thumb that I use interrupt for async or slave comm only, not for master SPI and I2C as it's very difficult to debug in interrupt mode efficiently. I pay very serious attention to comm implementation as it is a key factor for product quality

Eventually I'm able to make it work for EEPROM, both read & write. But it's just for verification of I2C in order to use it for Capacitive-Touch Panel (CTP). Now I'm struggling to make it work for CTP.

Thanks so much for your response, Norman.

Cheers,

~Duy-Ky

I don't think I've run a the I2C bus higher than 400kHz. Not many devices can keep up if it was faster. A 12Mhz limit seems be quite a bit past the official high speed limit.

Forgot about the EEPROM example being read only. Reminds me that I tried to help someone on the forum in modifying the EEPROM example to write. Guessing at a restart implementation was not easy. The accelerometer example is better base in that regard.

I was also amazed that the StarterWare examples were mostly interrupt driven. Sometimes with DMA. In theory, interrupt examples can be simplified to polled IO. With that in mind, StarterWare does give those that need a more complicated interrupt DMA example. For others, polled IO is "left as an exercise for the reader". I find that u-boot provides a better source of polled IO examples. U-boot code is not too difficult to extract out and compile in CCS. I reference linux for bug and quirk handling only. Linux code is rather difficult to make "bare metal".

Dealing with TI products do require a certain Zen. Or at least detachment.

I have a pretty knowledge about I2C protocol and implemented from sratch several I2C core into FPGA successfully.

As mentioned previously, I modified reference code for I2C1 and polling mode, I also modified uboot I2C code.

I tried them all and all broken one way or another, that's why I believe there's a HW chip problem, not SW one.

The real problem is all the status bits, like access ready, transmit ready, receive ready, busy, ... behave weird

Either interrupt or polling all rely on these status to make a move, so either mode is broken.

Eventually I had to do my old way bit bang for CTP (Capa-Touch Pabel)

I works but terrible slow compared to bit-bang implemented in 8051! Yes 8051!

Using 8051 bit-bang, I'm able to draw a line using my finger, dot after dot very close. But, using AM3358, each dot apart by 1cm, yes by 1 cm. It's just terribly slow.

This problem is not from bit-bang, but from GPIO IRQ, with the rate of I2C BB is about 50 Kbps. I verified on ATMega 50 Kbps I2C and had a smooth line..

Now, I give up using this chip on metal bare development, but I still uses BB-Blk Linux box "as is" as my server.

As mentioned previously, the manual is about 4000+ pages, so this chip must be huge in some manner.

To me, doing a big thing improperly is a lot easier than doing a simple thing properly. That's why I said the chip designer could have simply thrown everything into the chip without a clean chip architecture ?!?