HMC6352

Questions on control of serial busses
YahooArchive
Posts: 1462
Joined: Fri Oct 19, 2012 5:11 am

HMC6352

Post by YahooArchive »

The 6352 spec is pretty short on details, but what does this program do?

#define I2Cspeed100
#include

'Read the EEPROM locations
DIM astr(10) AS STRING
DIM bstr(10) AS STRING

astr = "r" ' read EEPROM

for i=0 to 8
astr(1) = i

i2cout (0,1,$42, 2, astr)
wait (1)
i2cin (0,1,$42,-1,"", 1, bstr)
print hex(bstr(0))

wait (1)
next i

----------------------------------------------

According to the spec it should print

42
?? undefined
??
??
??
1
4
1 some value > 1
50

----------------------------------------------

If this is what you see, then maybe next try writing to RAM location $7F (what
they use in their example) and see if you can read it back



YahooArchive
Posts: 1462
Joined: Fri Oct 19, 2012 5:11 am

Re: HMC6352

Post by YahooArchive »

Noted. will try.
One question in the following.
HMC6352 READ addr is $43, I read your I2CIN is using addr $42, what is the
reason or just a typing mistake.

Brian

YahooArchive
Posts: 1462
Joined: Fri Oct 19, 2012 5:11 am

Re: HMC6352

Post by YahooArchive »

> HMC6352 READ addr is $43, I read your I2CIN is using addr $42, what is the
reason or just a typing mistake.

The i2C routine will set or clear the LSB depending on a read or write, so using
$42 or $43 has the same result.


> > i2cout (0,1,$42, 2, astr)
> > wait (1)
> > i2cin (0,1,$42,-1,"", 1, bstr)

This separation of write and read is needed for the 6352 because it is REALLY
SLOW.

For most i2c devices this could be done with

i2cin (0, 1, $42, 2, astr, 1, bstr)

which would do the write of command and read back of the data in a single
operation.

YahooArchive
Posts: 1462
Joined: Fri Oct 19, 2012 5:11 am

Re: HMC6352

Post by YahooArchive »

Note that the program will clear LSB. Already use the following program and
checking very carfully.

1) The voltage source using 3.3V instead
2) Read and Write already seperate in two lines
3) Make sure all grounding is link together
4) the result is still, all the reading from EEPROM is 00

As I show on my video, the ARMite is sending some signal and receiving somthing
from the digital compass. But the result is not correct.

YahooArchive
Posts: 1462
Joined: Fri Oct 19, 2012 5:11 am

Re: HMC6352

Post by YahooArchive »

As far as I know there are no known problems with the i2c routines in BASIC or C
for the ARMmite. It has been used to interface to numerous other devices. The
C routines were used extensively for a testjig for an IC verification platform,
and the BASIC was based on that code. The routines do not support slave clock
stretching, but that can be added to the code (it does not look to be the issue
here).

I am blocked from looking at your scope captures here, and attachments are
stripped from messages to the group.

Does the data you see on the scope correspond to what the ARMmite reports?

You can always look at the source code in BASIC in the BASIClib directory.

You might check the SparkFun Forum, there are a huge number of posts on the
HMC6352.

YahooArchive
Posts: 1462
Joined: Fri Oct 19, 2012 5:11 am

Re: HMC6352

Post by YahooArchive »

>The routines do not support slave clock stretching, but that can be added to
the code (it does not look to be the issue here).
>

update at 11

looks like this may be the issue

http://forum.sparkfun.com/viewtopic.php ... ht=hmc6352

to add clock stretching in BASIClib/I2C.bas

everywhere you see

INPUT SCLpin ' release SCL high

replace with

INPUT SCLpin
WHILE IN(SCLpin) = 0
LOOP

I will make this a macro at some point and add it to the source

YahooArchive
Posts: 1462
Joined: Fri Oct 19, 2012 5:11 am

Re: HMC6352

Post by YahooArchive »

Running C and I have the C source . We just pulled out the I2C code - to
work with separately - will look for a place to put the jpg scope traces. I
don't see that stretching is required looking at the HMC6352 spec sheet.

Bill

YahooArchive
Posts: 1462
Joined: Fri Oct 19, 2012 5:11 am

Re: HMC6352

Post by YahooArchive »

> Got it working with the code below - Note the change of read 8 bits to 10
> bits - must be a stop/start bit issue. No sure if the clock stretching is
> needed. Should be able to work back to a minimum changed code, but moving on
> to other code development since this works and this device is only in our
> prototype board. We are using a different SPI device going forward.

My guess (I don't have the HMC6352) is that the HMC6352 is slow to respond, and
you have effectively slowed the ARM read down so it works. Though how reliably,
I couldn't guess.

Making it a 10 bit read for i2c WILL break for other i2c devices.

There are not start/stop bits like a serial port, but start and stop conditions
where there are transitions on SDA while SCL is high

YahooArchive
Posts: 1462
Joined: Fri Oct 19, 2012 5:11 am

Re: HMC6352

Post by YahooArchive »

I agree - an ugly hack that only makes the HMC6352 work, but I only have
this I2C device in this prototype - so works for me. The 2 extra clocks
could be just a two clock wait for the device to respond.



The HMC6352 manual shows two clock ticks between the M_SDA high and the
S_SDA low on a data transfer

YahooArchive
Posts: 1462
Joined: Fri Oct 19, 2012 5:11 am

Re: HMC6352

Post by YahooArchive »

Read thru your comments. Is that means this is not possible to read the
HMC6352 by ARMbassic yet.

Brian

Post Reply