Anyone got the I2C0 working fully using the HAL?

[gu48bz]

Posted on July 02, 2008 at 08:46

Anyone got the I2C0 working fully using the HAL?

[gu48bz]

Posted on May 17, 2011 at 09:32

Hi,

I've been attempting to get the I2C bus working on this chip for several days now and have been hitting several barriers: 1. The demo apps supplied with the HAL 1.1 don't work. Would appear to be an initialisation issue as from monitoring the lines nowt is coming out. 2. I got some demo code from Hitex, but they only show how to do a I2C read of 2 bytes. This code does work (of a fashion), so proves my hw is ok, but avoids using the HAL as they too couldn't get the HAL I2C code to work either. Using a mutation of the Hitex code I can generate the start bit, the address, but then I can't get any further data to write out. I've done as suggested on the datasheet and set PE to 1, but all this does is blitz out another bytes worth on the bus of value 0xFF (which is acked ok by my eeprom device!). Further writes to DR just don't appear on the bus. If anyone has managed to make this thing to fly take me out of my missery and post a snippit of code that works... pleeeeaseeee! Cheers Steve

[gu48bz]

Posted on May 17, 2011 at 09:32

Hi Again,

I've done some more digging around and I am sure that my problem is that the I2C peripheral isn't reading the SDA line properly. I am using port 2.0 and 2.1 acting as in master mode. After I write the slave address out and the addressed IC pulls the SDA low to do the ack it would appear that its not seen by the I2C peripheral inside the ST912. If I read back immediately the error bit is set to say the ACK with not received... I beleive this is making all other calls then fail. I've double checked out the hardware by reading the port lines while configured in GPIO input mode and they seem to work fine, so in theory it can sense the levels. I suspect there is some magic init sequence for port 2 required to make this happen (at the moment I configure them as Alt2 mode, open collector)... Anyone got any ideas? I see from seraching the forum some other person back in November was fighting was this as well, but the thread didn't go anywhere. Thanks Steve

[stefano239955_stm1_stmicro]

Posted on May 17, 2011 at 09:32

Hi Steve,

I'm using the IAR compiler. I have a working code running on the eval baord based on the str91x_libs i2c sample code. The GPIO pins for port 2 shold be configured as alternate output 2 (if you use I2C as master). Did you enable the SCU for I2C and GPIO2?

[gu48bz]

Posted on May 17, 2011 at 09:32

Hi,

I'm using the Keil compiler, but the assembler that it generates looks pretty convincing. I've got the SCU enabled for I2C0 and GPIO2. I've also tried experimenting in that area and if they're not configured then I don't get any clock out. One factor I haven't ruled out yet is having 96MHz system clock, with the Peripheral clock on a /2 divider.

[gu48bz]

Posted on May 17, 2011 at 09:32

Quote:

On 25-09-2006 at 12:07, Anonymous wrote: Hi Steve, I'm using the IAR compiler. I have a working code running on the eval baord based on the str91x_libs i2c sample code. The GPIO pins for port 2 shold be configured as alternate output 2 (if you use I2C as master). Did you enable the SCU for I2C and GPIO2? Hi, I had another eye-ball over that demo code and one reason it doesn't work (or more by chance) is that when they setup GPIO0, they don't set the direction. I've found that the value in memory is 0 on the Keil platform, which dicates it's an input, not an output. I've fixed this but it still doesn't work. I have a sneaking suspision that the demo / HAL i2C code is working due to smoke and mirrors and instantly breaks once moved away from the IAR platform. I'm finding on the demo code that its convinced that the bus is busy when it's not when it sends the start bit (SR1 has 0x93 in it). From monitoring the lines this is not the case. My next task is to carefully compare the Hitex I2C init demo code with the HAL, as Hitex gets far further (start bit+address sent out), before the code fails with no ACK.

[hugh2]

Posted on May 17, 2011 at 09:32 The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6Ve&d=%2Fa%2F0X0000000bpW%2FR8H1zydtdSg5YKesVeHwRhM2V9wGznzaAMJ_aSGnWbE&asPdf=false