I'm evaluating two I2C drivers, one comes from Keil MCB1800 demo board software and other is from LPCOpen software pack. Both drivers work but I have some issues with LPCOpen driver. As many have noticed there is a possible infinite loop condition inside the transfer function. With my hardware the driver is stuck while using USB and I2C communications simultaneously and so far I'm unable to fix this. Keil's driver works fine with the same hardware. Also Keil's driver seems to be more... understandable, I would say. LPCOpen uses event handler/interrupts and just feels overcomplicated. I'm using it in master mode. Basically I have few i2c slave components on this board so I have to configure them first and then read some periodic data. Anyway, all seem to work fine except the fact that the i2c lines are inverted with Keil. Please see attached pictures.
This is writing to i2c address 0x76, register 0x03 and data 0x00 with LPCOpen driver
Same operation with Keil driver
Reading data form i2c is exactly the same, everything is just inverted with Keil.
Honestly, I don't understand. I2C pins are configured with internal pull-ups ON and external 4.7kOhm pull-ups.
My problem is, I'm using a proprietary tool/software to configure and debug one of i2c components through the i2c.
The tool sees the i2c line busy and just wouldn't connect to the bus.
Any idea where should I look to invert both signals?
It looks to me like Keil is (just) driving the bus low while the I2C is not operating. Others can perhaps chime in as to why that might be. I haven't used either of these drivers (I haven't figured out if I can use Keil drivers in code generated by STMCubeMX since my target is STM).
For I2C master I just bit-bang usually. You can get 100kHz mode on any pins and it's fully interruptable.
On this particular MCU (LPC1833) the I2C SCL and SDA pins seem to be separated from any GPIO group. Basically, according to datasheet, these are dedicated pins. The only possibility to control their state, if I understand, is to use SFS register
There is an init code for I2C, as you can see the internal pull-ups are enabled
Somehow this code configures the I2C lines down by default.
OK, I found the issue in START/STOP generating functions. It's all about clearing flags. Here is the fix, see attached picture. So if you have a similar I2C behavior, look at these functions first.