I don't know. I'm not actively monitoring the bus.

Do most i2c devices have a minimum speed? In the datasheet it only has a maximum of 400khz. I'm using 20khz. Could that be an issue?

 

I don't know. I'm not actively monitoring the bus.

Do most i2c devices have a minimum speed? In the datasheet it only has a maximum of 400khz. I'm using 20khz. Could that be an issue?

No. There is no minimum speed and the clock pulses do not have to be uniform or synchronous.
You need to see if the peripheral device is alive by looking for that first ACK pulse. If you don't have that, then nothing else will matter.
You should also understand how to create a STOP Condition before you issue the first START Condition. This is sometimes called a bus RESET.

 

OK, I think the problem has something to do with the oscillator, but I'm not sure. I changed the values of the load capacitors and I seem to be occasionally reading values now. (I don't know about the ACK pulses. I'm using an i2c library, so I don't know about that.)

The datasheet says the chip has 2 x 20pf capacitors internally. One thing I don't understand is that this is claimed to be alterable via i2c, but I don't know how you're supposed to use i2c if the oscillator is not working (the datasheet also says there is a selection for crystal frequency, which doesn't make sense to me either.)

So my question is what capacitors should I use externally if there are 2 x 20pf inside and my crystal says it needs 18pf load capacitance?
One similar schematic has a 33ohm resistor in one of the lines of the crystal. Could this be necessary?

 

So my question is

if you have the datasheet attached here, more people may be able to help you.

no, a link to somewhere else doesn't count. you have to help others help you.

 

if you have the datasheet attached here, more people may be able to help you.

no, a link to somewhere else doesn't count. you have to help others help you.

If you would have read the thread, you'll realize I already did that.

 

If you are talking about '8007 crystal then I don't think this will have any bearing on the I2C as the timing comes from the master. You set the crystal capacitance by writing, using I2C, to a register in the '8007 so that wouldn't work well if it changed the I2C.

 

Back to the ACK pulses.
You haven't said which processor you are using (or if you have I can't find it) but usually the I2C library functions return the value of ACK so you can check for errors.
Which processor, compiler/assembler and I2C library are you using?

 

If you are talking about '8007 crystal then I don't think this will have any bearing on the I2C as the timing comes from the master. You set the crystal capacitance by writing, using I2C, to a register in the '8007 so that wouldn't work well if it changed the I2C.

Oh, I thought that the crystal on the 8007 had to be operating in order for you to access the registers via i2c. That doesn't explain why I'm now occasionally able to read back values though (after changing the load capacitance on the 8007).

 

Back to the ACK pulses.
You haven't said which processor you are using (or if you have I can't find it) but usually the I2C library functions return the value of ACK so you can check for errors.
Which processor, compiler/assembler and I2C library are you using?

Yeah, the problem is that I'm at the flash limit for my microcontroller and adding the code for checking the ACK makes it go over. Yeah I know I can remove other stuff and get a better micro (and I eventually will), but I want to know what load caps I need to use?

 

So my question is what capacitors should I use externally if there are 2 x 20pf inside and my crystal says it needs 18pf load capacitance?
One similar schematic has a 33ohm resistor in one of the lines of the crystal. Could this be necessary?

OK, nevermind. It looks like the cap would have to be lowered slightly inside the 8007. Is the 20 close enough to the 18 load capacitance to not be an issue?

 

Geeeeze. I can't remember the last time I was up against a hard memory limit. It is so penny wise and pound foolish. How will you ever fix the next bug that comes along. Memory in an embedded project is almost free, why would you tie one arm behind your back like that?

 

Well, I checked on a scope and the i2c looks fine. I also just purchased the Bus Pirate and I'm going to make sure the data is readable. If it is, I think I've narrowed the problem to the chip itself. It may not be soldered right because it's a QFN-24 and I had to do it by hand or the version of the chip I got sent may not be right. There is a QN8007 and a QN8007B, but both have similar markings on the chip so I can't tell. Maybe I was sent the non B one which is apparently an old discontinued model.

And thanks for the continued help. I really appreciate it. I'll update when I analyze the i2c.

 

I received the Bus Pirate and confirmed that I have the B version of the chip (the correct version).

So I analyzed the i2c signal from the PIC chip, and this is the result I got in the software:
Does it look normal to you? The i2c analysis says there's a bunch of errors. It is possible I just don't have the software setup properly because I can only get it to capture 1/4 of the time (it seems if I'm lucky and press capture at the right time, that' when I get a result.)

 

Here's what I get out of that.. I don't know what it all means in the grand scheme of what you are trying to do. Sorry for the bad notations.. by the time I got finished looking at it I didn't want to redraw it.
In a nutshell,
The master issues Start, then a write to slave address 6Eh. The slave ACKnowledges.
The master sends 7Dh and the slave ACKs indicating it got the data and the master can continue.
The master sends BFh and the slave NAKs indicating it wants no more data.
The master issues a stoP to end the transaction.

Despite the potential issues, it looks like the master wrote 7DBFh to the slave at 6Eh. That could mean 'set the register address to 7Dh in slave 6Eh and write BFh to it' - depends on the slave but a set of 8 bit registers that are written individually could account for the slave's NAK at the end. Does that fit with what you expect? If not, I've noted some potential issues to think about on the sketch including a suspicion that the analyzer is missing things e.g. SDA transitions with SCL=1 and different SCL times.

Good luck!

EDIT: the first data byte is 7Dh, not 7Bh. Sorry for any confusion.

 

So I used the buspirate to probe all addresses and the device returns all addresses, so the chip is not responding by pulling it low at 0x56 and 0x57 like it should. Is there any legitimate reason why it would do this?

I've taken this thing to the lowest level possible. I got a clamshell-type QFN programming enclosure that converts the QFN to a DIP. I then wired the buspirate up to the enclosure. AND it still doesn't work.

So at this point I know the chips are either busted (tested several) or there is something weird about the IIC they use or the datasheet is just wrong.

I contacted the company, but the problem is the US company was closed in 2015 and moved to china and the chinese are clueless and won't help. I insist on making this work and it has to be this chip (there are certain specific reasons).

 

AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!

When it scans all slave addresses and it lists them all instead of the two read and write addresses, does this mean it is ACKing every address?

So anyway, even though it is not behaving like a normal device and only reading back two registers, when I force it to read the supposed read address 0x57, I get the data:

When I type [0x57 r:10]
I get back the data in the first 10 registers

However, it has two bytes before the registers begin (0xFF and 0x00).

 

The previous shot showed writing to a slave at 6eh. What address do you expect the slave to be at?
Of note: 6Eh is frequently the default address for devices that accept some address-setting protocol. The master sends a request to 6eh and all of the slaves at the default address reply with a unique string. Only one will make it through, the others will be arbitrated off the bus. When the unique ID string is received, the master then sends a 'set address to xxh' command to set that slave to xx.
Can you post another shot - like or quote so I'll get an alert.

 

The previous shot showed writing to a slave at 6eh. What address do you expect the slave to be at?
Of note: 6Eh is frequently the default address for devices that accept some address-setting protocol. The master sends a request to 6eh and all of the slaves at the default address reply with a unique string. Only one will make it through, the others will be arbitrated off the bus. When the unique ID string is received, the master then sends a 'set address to xxh' command to set that slave to xx.
Can you post another shot - like or quote so I'll get an alert.

I have no idea because I had it set up to scan all slave addresses to find the correct one. Anyway, this is beside the problem.

I have likely found the problem. I was able to read/write the device at the correct slave address (the one in the datasheet) using a different PIC that has hardware master I2C. The PIC that I was using before had software I2C master only (using the mikroC library). Apparently that doesn't work with that particular device (unconfirmed).

I am now making a board with the better PIC, so I'll see what happens.

The device itself also has the peculiarity of responding on all addresses unlike any other chip I've tried. This made the debugging process harder because I assumed the problem was with the IC or the wiring of the IC, but not the PIC.

 

The device itself also has the peculiarity of responding on all addresses unlike any other chip I've tried. This made the debugging process harder because I assumed the problem was with the IC or the wiring of the IC, but not the PIC.

Wow. That is.. unusual. It is also out of I2C spec - maybe they screwed up and that's why they call it 'modified I2C'.

If you are sure that it is ACKing multiple addresses (by looking at the busses with the Logic Analyzer), that is weird. The default address when SEB=0 should be 0101011 (sec. 5.1 of the datasheet). That makes the slave address 2Bh or 56h to write and 57h to read depending on how you prefer to think about it. I believe the PIC wants SSPADD to be 2Bh and let it figure out the read/write bit. The QN looks like it wants the address right-justified too, based on the description for the DEV_ADD register 02h on pp28.

It looks like the slave address setup goes like this:
Set SEB=0 to make 2Bh the default address.
Write the desired slave address to register 02h (DEV_ADD).
Set SEB=1 to run at the new address in register 02h
Note that on power up the default address is set to 2Bh so SEB is don't care until you set the new slave address. After that, set SEB=1.

When you pick your slave address, stay clear of <14h or so. I2C defines a set of reserved addresses down there and some PICs want those left alone while others don't care. Which PICs require that restriction is not particularly well documented.

Interesting that MicroC's libraries didn't work but the uCHIP master did. MicroC is bit-banged and uCHIP master is hardware generated. I've used both successfully and without too much thought, even. It shouldn't be that sensitive.

I did note on your posted logic analyzer image (at the *) that SDA cycled while the clock was high. That shouldn't be an issue with I2C but maybe this slave doesn't like that and that's why MicroC failed and the hardware uCHIP master worked. It probably doesn't have those stray transitions.

Good luck!

EDIT: It's hard to see in the layout shown in post #11 but is the MOD pin 12 connected to GND? If it is floating high, that would put the interface into the 3-wire mode, not I2C. If it is supposed to be connected, the lack of thermal relief at the pad may make soldering the pin problematic.