cc430F6137 i2c interface with HMC5883l (compass AKA magnetometer)

Dominic,

Hope you are doing well.  I2C is a 7 bit address and the last bit determines if the operation is a read or write operation.  If you post your read and write functions here that might help me tell you if you should be inputting a 7bit address, an 8 bit address, or a 7bit address bit shifted by 1.  It can be confusing.  At the end of the day the best way is to look on the logic analyzer and make sure that the first 8 bits lining up with SCL are 3C for a write and 3D for a read.  If that is true then you are sending the proper address in your I2C read and write commands to the device.

Now going through the Honeywell datasheet it looks like you are trying the sequence to read data continously from the sensor.  Here is the pseudocode they recommend? Can you send us your code to verify it matches? Particularly the interesting part will be how you are doing the waiting and how you are incrementing the address on the device.  The way this device decides what values to send you on a read command is to actually issue a write command first.  This is very common.  So for example the first time you issue the 0x3D 0x06 it is reading from register 0x03 because it automatically increments the register pointer inside the device.  It is very important to issue a write before every read or after every read in the looping case to reset the register point back to 0x03 to get the data from this point. 

1. Write CRA (00) – send 0x3C 0x00 0x70 (8-average, 15 Hz default, normal measurement)

2. Write CRB (01) – send 0x3C 0x01 0xA0 (Gain=5, or any other desired gain)

3. Write Mode (02) – send 0x3C 0x02 0x00 (Continuous-measurement mode)

4. Wait 6 ms or monitor status register or DRDY hardware interrupt pin

5. Loop

           Send 0x3D 0x06 (Read all 6 bytes. If gain is changed then this data set is using previous gain)

           Convert three 16-bit 2’s compliment hex values to decimal values and assign to X, Z, Y, respectively.

           Send 0x3C 0x03 (point to first data register 03)

           Wait about 67 ms (if 15 Hz rate) or monitor status register or DRDY hardware interrupt pin

    End_loop

Jason:

I am making some changes to my code, I ll e-mail it to you once I am done. 

But in the mean time:

 Write CRA (00) – send 0x3C 0x00 0x70 (8-average, 15 Hz default, normal measurement)

• The 0x3C, it is part of the data, or is that the address 0x1E, which under write operation, is 0x3C? I am asking if should explicitly be Txing 0x3C or if 0x1E is shifted to 0x3C "under the hood"

"To clock out the new data, send:
0x3D, and clock out DXRA, DXRB, DZRA, DZRB, DYRA, and DYRB located in registers 3 through 8." page 18 of the HMC datasheet. 

What about that 0x06 that should be along with 0x3D. Now, if 0x3D is for a read operation, how can we send a 0x06? 

Do you agree with me, if I say that in an I2C read operation for device set up in Master mode, we can't Tx data? 

Thanks for your input Jason, appreciate the time!

Dominic,

When you look on the logic analyzer you should see the first full byte being 0x3C.  If you break up 0x3C into its bit form it is 00111100.  The LSB of that byte is a 1 if it is a read (0x3D) and a 0 if it is write (0x3C).  The address is embedded in this byte.  The address is 0x1E but then appended/shifted with a 0 or 1 depending on a read or write.  So in the datasheet the address of the device is 0011110 (7-bit) which when shifted left for a write becomes 00111100 (0x3C).  does that make sense? 

For the read operation you send <0x3d> <number of bytes to be read from current register pointer>.  So to actually read from register 0x03 you would have to set the register pointer by issuing a write.  Here is the pseudocode which parlallels how the datasheet outlines it:

To read 0x03:

send 0x3c 0x03 //set register pointer to 0x03

send 0x3d 0x01 //read 1 byte from register pointer at 0x03

The resultant output you receive should the value stored at register 0x03.

Make sense?

I know the datasheet says send 0x3D 0x06.

But in I2C, once you set up the micro for a read operation, you can't send 0x06. If you want to send any data, you have to sent up the micro for a write operation.

whatever you explained in the previous post makes perfect sense. I can get the HMC to repond now, but I CANT send 0x06 along with 0x3D.

You know what I mean?

If you set up the micro for a read operation master mode. You cannot write out to a slave. You can only expect to RX data from a slave. Am I correct here?

Hi there. I stumbled on this thread and coincidentally am working on a project which is utilizing this exact same micrcontroller and magnetometer (the sparkfun version on a breakout board)

I am new to the TI 430 line of micrcontrollers, and although familiar with arduino micrcontrollers, have limited experience working with micrcontrollers where I had to set registers in code(did a little bit of this with Atmega AVR chips, but only timers and pin voltage change interrupts). This is also my first time using I2C.

I have been trying to get this magnetometer working with this microcontroller by piecing together the example code for I2C provided for this micrcontroller. Specifically, I combined code from the files "cc430x613x_uscib0_i2c_08.c" (code for transmitting arrays of data via I2C) and "cc430x613x_uscib0_i2c_10.c" (code for receiving arrays of data via I2C).

My code can be found at the following link (http://pastebin.com/x7iZ5sCR).

My goal with that code right now is to set up the magnetometer for single measurement mode, and just get one measurement (aka, read 6 bytes). I am lighting up leds on the dev board for visual indication when stepping through the code with a debugger. I am following these instructions from the magnetometer data sheet except for the conversion at the end, I'll figure that out later. I can see the rx array values in my debugger at the end of my code when it should hypothetically have read 6 bytes.

1. Write CRA (00) – send 0x3C 0x00 0x70 (8-average, 15 Hz default or any other rate, normal measurement)
2. Write CRB (01) – send 0x3C 0x01 0xA0 (Gain=5, or any other desired gain)
3. For each measurement query:
Write Mode (02) – send 0x3C 0x02 0x01 (Single-measurement mode)
Wait 6 ms or monitor status register or DRDY hardware interrupt pin
Send 0x3D 0x06 (Read all 6 bytes. If gain is changed then this data set is using previous gain)
Convert three 16-bit 2’s compliment hex values to decimal values and assign to X, Z, Y, respectively

First off, I apologize for the very repetitive and crude nature of my code, I want to successfully get a measurement and understand what everything is doing before I compact and refine the code. Second, I am compiling this using the mspgcc compiler on linux which is why the interrupt syntax is different and I have different includes at the beginning. mspgcc also does not have several TI functions like __even_in_range, but from what I understand these aren't exactly necessary and just for optimization. I am also currently lacking a delay cycles function (not present in mspgcc) but will find a work around.

Is there any advice you could give me or point me in the right direction? Am I doing anything completely wrong? I previously tested the first two transmission parts of my code and it seemed to be working since the code was stepping through correctly on the debugger and going through the interrupt. After I added an earlier version of the receiving code, something went wrong and I somehow broke my magnetometer board. I saw the switch statement receive the wrong value in the interrupt and go into the TX section of it instead of the RX section of it. I think that is because I had UCB0IE |= UCRXIE; to enable the RX interrupt, using orequals, instead of just UCB0IE = UCRXIE;. I'm guessing the microcontroller may have held the sda, sclk lines high for too long, but regardless my code no longer steps through (also hooked up the sensor to my arduino with code off the internet for that specific chip and it also did not respond). And yes, I did have pullup resistors.

I have a new board to play with, and I also have a sparkfun usb logic analyzer to spy on what is going on the sda and sclk lines. I'll probably use the logic analyzer first with my arduino and the magnetometer to see what the correct sequence of events is supposed to look like, then try it on the cc430f6137. I'm hoping to get any input before I try this, though.

Did you check your SDA and SCL lines with a scope? Does something happen on them at all? But I guess it does, since your code does not contain any error handling (e.g. slave not responding). So it would never get past the first transmit attempt if something were wrong with th econnection.

Michael Romanko said:

First off, I apologize for the very repetitive and crude nature of my code, I want to successfully get a measurement and understand what everything is doing before I compact and refine the code.

Michael Romanko said:

Second, I am compiling this using the mspgcc compiler on linux which is why the interrupt syntax is different and I have different includes at the beginning. mspgcc also does not have several TI functions like __even_in_range, but from what I understand these aren't exactly necessary and just for optimization. I am also currently lacking a delay cycles function (not present in mspgcc) but will find a work around.

Current versions do support both, even_in_range and __delay_cycles (I think, it is called __delaycycles there). The latter has been implemented in version 20110809 for up to MAXLONG cycles.
And you're right, even_in_range isn't necessary, only efficient. (and can be easily simulated with inline assembly, if really required)

However, when trying to read the 6 bytes, you don't clear the UCTR bit (it does not auto-clear). So instead of starting a read, you're starting a write. Since you implicitely cleared (in the pasted code) TXIE when settign RXIE, the ISR is never called, as no RX interupt ever happens and the TX interrupt is blocked.
In the code you described (where you only ORed RXIE and therefore didn't clear TXIE), the ISR was called for TX interrupt, and since nothing was to send, the TX ISR stopped transmission and waked main. With no bytes received.
But with the code you posted to pastebin (with TXIE cleared), it will never wake up from the last LPM.

Change

to

and it should work