I2C Problems

paulwww

New Member
Hi Everyone

I wonder if anyone can help with my i2c issues.

I am trying to interface an 08M2 and/or 14M2 to the Honeywell hmc6532 compass module. I am using this code, which worked fine for a couple of days:

Code:
i2cslave $42, i2cslow, i2cbyte
main:
pause 1000
i2cread $41,(b1,b0)
debug w0
goto main
Now all I get back from the module is an unchanging $43FF. This result has been reported by other users, but I never saw any resolution. I also get this result if I disconnect the module completely, so I am leaning to the conclusion that the module has failed and I need to replace it.

I note the i2cslave command is deprecated so consulted the i2c tutorial but it does not have any example code using the new i2c commands.

Anybody have any advice ?

Many Thanks in anticipation.
 

westaust55

Moderator
Welcome to the PICAXE forum.

That your code was working initially could suggest a hardware fault.

If the module was disconnected and the 4.7 kOhm pull-up resistors on the clock and data lines were still in place then you should receive back $FF (= 255) for both data bytes. That you are receiving $43FF suggests there may be a hardware problem


However you code does not match that given at the forum thread you give a link to at post 8 second example:
Code:
i2cslave $42, i2cslow, i2cbyte
main:
i2cwrite ($41)
[COLOR="#FF0000"]pause 7[/COLOR]
i2cread (b1,b0)
debug w0
pause 100
goto main
or that at post 17:
Code:
i2cslave $42, i2cslow, i2cbyte 

FOR b3 = 0 to 100
   I2CWRITE ($41)
[COLOR="#FF0000"]   PAUSE 10[/COLOR]   I2CREAD (b1,b0)
   DEBUG
   PAUSE 10
NEXT b3
From the datasheet: https://www.sparkfun.com/datasheets/Components/HMC6352.pdf
looking at page 8 it states:
Timing Requirements
Table 3 contains the time delays required by HMC6352 upon receipt of the command to either perform the commanded
task or to have the response available on the I2C bus.
From Table 3 the conversion takes 6000 usec (6 ms) to perform so there is a need to wait at least that time to read valid data.

For the newer I2C commands:
Code:
	HI2CSETUP I2CMASTER, $42, i2cslow, i2cbyte
main:
	HI2COUT ($41)
	pause 7
	HI2CIN (b1,b0)
	debug w0
	pause 100
	goto main
 
Last edited:

paulwww

New Member
I2C Pull-ups

I had removed my 4k7 pull-up resistors after reading that the HMC6352 had its own on-board pull-ups. Still not sure if extra ones are needed?

However, if I switch the compass power leaving the clk/data connected I get either $FFFF or $43FF. I have tried all the combinations of code, even the new commands and can't get a sensible bearing so the module must have failed.

I was just concerned that the original i2c commands may have been deprecated for some compatibility reasons, and the new ones would fix my issue, but sadly no!

Many many thanks for your help...


Welcome to the PICAXE forum.

That your code was working initially could suggest a hardware fault.

If the module was disconnected and the 4.7 kOhm pull-up resistors on the clock and data lines were still in place then you should receve back $FF (= 255) for both data bytes. That you are receiving $43FF suggests there may be a hardware problem


However you code does not match that given at the forum thread you give a link to at post 8 second example:
Code:
i2cslave $42, i2cslow, i2cbyte
main:
i2cwrite ($41)
[COLOR="#FF0000"]pause 7[/COLOR]i2cread (b1,b0)
debug w0
pause 100
goto main
or that at post 17:
Code:
i2cslave $42, i2cslow, i2cbyte 

FOR b3 = 0 to 100
   I2CWRITE ($41)
[COLOR="#FF0000"]   PAUSE 10[/COLOR]   I2CREAD (b1,b0)
   DEBUG
   PAUSE 10
NEXT b3
From the datasheet: https://www.sparkfun.com/datasheets/Components/HMC6352.pdf
looking at page 8 it states:

From Table 3 the conversion takes 6000 usec (6 ms) to perform so there is a need to wait at least that time to read valid data.

For the newer I2C commands:
Code:
	HI2CSETUP I2CMASTER, $42, i2cslow, i2cbyte
main:
	HI2COUT ($41)
	pause 7
	HI2CIN (b1,b0)
	debug w0
	pause 100
	goto main
 

westaust55

Moderator
From the French part of this forum
http://www.picaxeforum.co.uk/showthread.php?18799-Picaxe-et-HMC6352&highlight=HMC6352
this code was confirmed to work (using the older commands)
Code:
i2cslave $42,i2cslow,i2cbyte 
pause 100
do
i2cwrite($41)
[COLOR="#FF0000"]pause 50[/COLOR]
i2cread(b1,b0)
debug w0
pause 1000
if pinC.6 =1 then exit 
loop
The only difference is a much greater pause duration between the "A" command and reading back the bearing data.
It may be worth doing some further testing before you declare your part deceased.

What board are you using? Does the board specifically include pull-up resistors?
Some boards do but have jumpers or bridges that must be closed as often there can be mulitple i2c devices on the bus and there should only be one set of pull-up resistors.
The Sparkfun module does have 10 kOhm pull-ups and seemingly no method of diconenction of these resistors.


From the datasheet:
The HMC6352 Serial Clock (SCL) and Serial Data (SDA) lines do not have internal pull-up resistors, and require resistive
pull-ups (Rp) between the master device (usually a host microprocessor) and the HMC6352. Pull-up resistance values of
about 10k ohms are recommended with a nominal 3.0-volt supply voltage
 

SAborn

Senior Member
As Westy said, try and see what reading you get with the module removed and the 4K7 pullups on the master board (picaxe board) just solder the pullups to the botom of the board for testing, it should then return $FF, if not then its a problem with the picaxe board and not the slave.

If you get $FF returned then try plugging in the slave with the pullup still on the master board as see if it works.

On average only the master bus line has the pullups and not the slave, so its strange to have pullups on the slave as you indicate. (Maybe it dont have pullups or they are too high in value)

How long are you wires between master and slave.
 

westaust55

Moderator
Sorry SAborn, however, many slave modules have pull-up resistors included, inclucding Rev Ed's own AXE033 LCD module.
Note that the 4k7 resistors pull up resistors are pre-soldered onto the AXE033 LCD
module. Therefore additional external resistors are not required.
I have purchased a few modules such as a DS3232 RTC where the pull-ups are from Vcc to half-pads and the user can bridge the pads with a blob of solder if the i2c pull-ups are required - ie the only module on the i2c bus.
 

paulwww

New Member
Just to feedback current position:

Honeywell module does not have pull-ups, but the Sparkfun board does have 10k pull-ups, so they should not be needed. Having removed the ULN2003 from the 14M2 protoboard I now get $FFFF consistently from the module using the latest french code example above, so I am satisfied the module is defunct. There are 3 possible causes:

1. The module was faulty and suffered early life failure
2. Powering the module and picaxe from my 5V Regulated supply was too near the 5.2V Maximum (I remember reading about another user who suffered a similar fate)
3. Powering the module and my motor drive circuit, which uses the L293DNE with internal diode protection, has spiked the module

Difficult to prove which one is the root cause, but I don't want to junk another compass module!

Thanks for everyone's help...
 

inglewoodpete

Senior Member
Do you have ANY other i2c devices? Remove the HMC6352 and connect the other i2c chip (Eg a serial EEPROM or Real Time Clock). Get that working and then return to the HMC6352. Remove the L293 and see if you can get basic communication going with the HMC6352.
 

paulwww

New Member
No don't currently have any other i2c devices to try. I had the compass working standalone for a couple of days, but then it failed when I tried to integrate with the motor controller.
 

SAborn

Senior Member
Difficult to prove which one is the root cause, but I don't want to junk another compass module!
Well dont junk it and try a few more tests like IWP suggests, and to add a few more, try adding more pullups in parallel to reduce the present 10K resistance from the slave, as i have had I2C slaves that would not work with more than 3K9 pullup resistance, with a picaxe, although other slaves worked well on the same bus with higher resistance pullups.
Cable length will change the value up resistance too, (why i asked earlier how long the wiring is)

On all the picaxe pins i have managed to kill over years of use, 99% have always been the I2C pins while using I2C, (my fault) the rest of the chip will work fine, just not I2C, so perhaps you have taken out I2C on the picaxe, this is one of the reasons why IWP asks you to test a different I2C device.

Having removed the ULN2003 from the 14M2 protoboard
Have you tried the HMC6352 slave with the ULN2003 removed.
 

paulwww

New Member
Yes tried that - and short leads. Got some spare 14M2s though, so would be worth plugging a new one in and seeing what results I get with that.
 

paulwww

New Member
Just an update on the resolution of this issue.

Got a replacement compass module fitted, and it works fine with the original code - so no problems there.

Used the dual supply lines of the L293, with separate battery supplies, and fitted 1000uF capacitor to the logic side.

So far so good - everything working as expected.

Don't think the dual supplies will be a problem in my final model, so will probably stick with those.

Thanks again to forum members...
 
Top