So I've been trying to get this i2c controlled fm transmitter chip working for a while and I was loosing my mind. I contacted the chinese company that designed it and they eventually showed me that the i2c protocol they use to control the chip is not actual i2c. I have two diagrams that show the difference. Does anyone know what this is called if it has a name and if there is a software library for it somewhere? Thanks!

Here is the normal i2c diagram:

Here is their modified one:

 

The difference is not immediately obvious. Where do you see a difference?

 

Well, it looks to me like the SCL line is held high for seven bits sometimes instead of alternating high/low for every bit.

 

Well, it looks to me like the SCL line is held high for seven bits sometimes instead of alternating high/low for every bit.

That's nonsense. The dashed line is an indication that SCL performs it's obvious function so that the diagram can be contracted. Next theory.

 

No, those parts of the line are dotted not solid. They have just condensed the drawing by not showing all the clock and data transitions.
It looks like normal I2C to me.

 

Either the device follows the I2C protocol or it doesn't. I'll lay long odds that the Chinese did their job correctly and the fault is in your hardware and/or firmware. Start with that default assumption and proceed to gather evidence to prove or disprove the hypothesis. If the device does not conform to the I2C protocol then, it is about as useless as a screen door on a submarine.

 

I emailed the chinese guy and he is insisting it is different from normal i2c and he just shows me those two diagrams. I don't know what else to do because I tested the microcontroller with many other i2c devices and it works fine, so I don't know what's going on. I built two different boards, tested to make sure the chip is soldered properly and the schematic is practically pulled from their datasheet, so there shouldn't be a problem.

The weird thing is that I checked the companies datasheets on their other similar products and the section explaining i2c communication is the same except they changed i2c to "2-wire serial" and there is one line stating "uses the Philips I2C standard" which is removed from this one. Maybe this just has to do with copyright.

 

See page 20: http://www.datasheet4u.com/download_new.php?id=1028100
http://www.datasheet4u.com/download_new.php?id=1028100
Thanks for the help!

 

https://en.wikipedia.org/wiki/I²S

I²S (Inter-IC Sound), pronounced I-squared-S, is an electrical serial bus interface standard used for connecting digital audio devices together. It is used to communicate PCM audio data between integrated circuits in an electronic device. The I²S bus separates clock and serial data signals, resulting in a lower jitter than is typical of communications systems that recover the clock from the data stream. Alternatively I²S is spelled I2S (pronounced I-two-S) or IIS (pronounced I-I-S). Despite the name, it is unrelated to the bidirectional I²C bus.

2 minute read of data sheet and 30 seconds on google.

Yes, it has I2S, but that's not what I'm talking about. It uses I2C (or 2-wire serial) for the communication.

 

It is I2C if you pull MOD and SEB pins low and use the correct device address.

 

It is I2C if you pull MOD and SEB pins low and use the correct device address.

Yes, they are connected to ground. I know this sounds stupid, but that doesn't mean I need a pull-down resistor, right? It's just connected to ground.

Here is a schematic. Do you see anything wrong?
You have to right-click and view image to get the full image. Normal click expands it wrong.
BTW thanks for the help.
*100uH should be 100nH

 

What device address are you using?

 

The default one. So according to the datasheet it's 0x56 for write and 0x57 for read. The actual address is 0x2B, but I don't think that's used anywhere.

 

You have 10k pull up resistors on SCL and SDA which is higher than usual (4.7k) but probably OK if the wires are very short and the ground connection is good and short.

 

You have 10k pull up resistors on SCL and SDA which is higher than usual (4.7k) but probably OK if the wires are very short and the ground connection is good and short.

I also tested 3.3K there.

(FYI: Ignore the green line going from + to the ground of the audio jack. That's connected to something else.)

Also caps on the crystal are not needed because they are integrated in the chip.

 

So we still have no evidence that this device implements a different I2C than everybody else. BTW, 0x2B is the 7-bit device address. If you shift it left 1 bit position you get 0x56. Now, when you take 0x56 and the the bit for read you get 0x57. Are these numbers starting to make sense to you?

 

So we still have no evidence that this device implements a different I2C than everybody else. BTW, 0x2B is the 7-bit device address. If you shift it left 1 bit position you get 0x56. Now, when you take 0x56 and the the bit for read you get 0x57. Are these numbers starting to make sense to you?

Yes, I got that. I was wondering if the 0x2B was somehow used in another way (like to initialize the device), but it seems that 0x56 and 0x57 are the only addresses ever used when communicating with the device?

 

Yes, I got that. I was wondering if the 0x2B was somehow used in another way (like to initialize the device), but it seems that 0x56 and 0x57 are the only addresses ever used when communicating with the device?

No -- I don't think so. Are you able to get any intelligent data in or out of the device? In what way are things failing?

I had a similar problem with an ES9018 SabreDAC. I started by writing a test application to examine the contents of each register and I extended this application to allow writing each register. When I had that working I was able to upload and download the entire register file. It made quick work of debugging since I also had templates of what the registers were supposed to contain.

Are you sure you are sending the correct register addresses after the slave address?

 

No -- I don't think so. Are you able to get any intelligent data in or out of the device? In what way are things failing?

I had a similar problem with an ES9018 SabreDAC. I started by writing a test application to examine the contents of each register and I extended this application to allow writing each register. When I had that working I was able to upload and download the entire register file. It made quick work of debugging since I also had templates of what the registers were supposed to contain.

Are you sure you are sending the correct register addresses after the slave address?

No, I cannot read/write any data to the device. The guy suggested that I just try to read and write register 0x08 and whatever I send, I always get FF back, which is what I get with nothing connected.

 

Can you see the ACK pulse after sending the slave address? If not then you might have the wrong slave address.