Can't get HMC6343 compass chip to respond to I2C inquiry on DM6467 system

Know nothing about HMC6343 and DM6467 but I'll bite.

From what I can see from the HMC6343 datasheet, it's address is stored in the EEPROM. Perhaps it has been changed. Factory default is noted to be 0x32. In other places in the doc, 0x32 for write and 0x33 for read. So in 7-bit it's really 0x19. Maybe you can try sweeping through the addresses from 0x01 to 0x7F.

Perhaps the pull-up resistors are too strong for HMC6343. From what I have seen on the EVMs, 2.2K is usually used. The HMC6343 datasheet suggests 10K.

There are slight differences in the scope captures. The manufacturer capture appears to use 5V signals. The HMC6343 datasheet gives 3.3V. Maybe they have I2C level translator in there somewhere. The level translator might compensate for weak pull down.

Another difference is that manufacturer capture has a delay between the START and DATA. Just an observation. Maybe nothing. Not sure if the DM6467 I2C controller can insert a delay.

Norman,

Thanks for taking a shot at it.  Perhaps you can mull this around in your head overnight and come back to me tomorrow.

Below are some positive and negative responses to your shots:

MISS: It can't be an address issue, because the address sent is identical between my failure and the manufaturer's success.

MISS: I don't think it can be the pullup.  Note that 10K is WEAKER than 2.2K, not vice versa.  Also spec sheet says 10K.  And regardless, you'd see SOME partial pull down if not complete, in the case of the resistor being too strong.  This would be similar in nature to the mfgr scope trace where you discover the I2C bottom line is a little above ground, but when the chip pulls NACK it goes closer to ground a bit.  You'd see some kind of thing like this, even pulling down from 3V to 2.8V or something.

HIT: I too noticed that 5V vs 3.3V thing.  I inquired.  The manufacturer replied that he's indeed running 5V with no translators.  I wrote back earlier today asking how this can be, when the data sheet says only up to 3.6V supply.  I'm waiting to hear back on that.  But if the spec sheet is right, then it ought to work at 3.3V.  Note I didn't check the EXACT high and low voltage on the I2C.  It should be fine, though, above and below normal logic thresholds.  I intend to check that as well again later.

HIT: Not sure what kind of hit, but I was wondering about timing too.  I think data should be captured on the rising edge of the clock, but spec says data should remain stable throughout clock high.  I appear to have no worse than zero hold time after clock falling edge, but perhaps it's in fact slightly negative.  If the HMC6343 is seeing it as this, then it could be thinking a logical STOP was issued (data rise while clock high), or confused by a second logical START (data fall while clock high).  This made me wonder about slowing down.  HEY, YOU DIDN'T ANSWER THAT.  WHERE DOES THE CLOCK COME FROM?  I CAN'T FIND IT.  I WANT TO SLOW IT DOWN OR SPEED IT UP.  Finally, regarding the actual delay between START and DATA, I see that now.  Dunno how to make a change...

Thanks again, and perhaps you'll get an inspiration for me overnight.  That's when I normally get mine, but there are none forthcoming for me on this particular problem!

-Helmut

As Homer Simpson would say "50:50, I like them odds".

I was thinking that your instance of the HMC6343 might have a reprogrammed or corrupted address. Not sure how easy it is for that to happen. I did not look in the datasheet too deeply.

My thinking on the pull-up resistors was that the device might be strong enough to pull down a 10K but not strong enough to pull down a 2K.

I learned it the same way. Data changes on falling edge and sampled on rising edge. Implies stable after the rising edge or clock high. I suppose if the device is really really really slow to respond, it will could sample after the subsequent falling edge.  Not many chips use the slow 40kbps.

Changing the I2C clock frequency means digging into the Linux driver. Vaguely remember the code is separated in a common core layer, algorithms and adapters. I think somewhere in the adapters layer, the driver will setup the clock. The frequency may be sent down from the board/platform file.

Thanks.  ref http://e2e.ti.com/support/embedded/linux/f/354/t/162608.aspx#591861

FYI, I already searched the board/platform file board_dm646x_evm.c and can't see it coming from there.  I stopped probing down in the "well" at a search for *device_create(

FYI device_create I was calling from my own drivers in board_dm646x_evm.c, and they made a pdev.  Elsewhere git code gets a clock rate out of pdev.  But I haven't been able to connect those top-down and bottom-up ends...

...my dead end is clkdev.c has clk_find() called from higher up by passing a pdev.  Inside clk_find() it's searching some list of clocks.  I thought somehow from above, device_create() would have clock info that goes into such a list, but I can't find it!