• State Answer Suggested
  • Locked Locked
  • Replies 17 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 6794 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR6989 communication to Raspberry Pi Camera (OV5647) using I2C

Aaron Ewing
Prodigy 130 points
Other Parts Discussed in Thread: MSP430FR6989

Hey everyone.

I was hoping someone could help.

I'm working on a university research team and we are trying to send a Nasa-funded CubeSat into space. Our CubeSat is a bit unique in the layout so the type of camera used is very specific. That is why we are attempting to interface a Pi cam with an MSP430.

We are having difficulties currently with getting an ACK from the camera to the MSP430 (we are using an oscilloscope to see) through the I2C lines. We can send a START command and the slave address but the slave does not send an ACK.

What we are currently seeing on the oscilloscope is an attachment. (It's a NACK if the SDA line is high at the end, and an ACK if it ends low at the very end)

Here is the datasheet for the sensor (OV5647) that is used in the camera:
http://cdn.sparkfun.com/datasheets/Dev/RaspberryPi/ov5647_full.pdf

Here is the datasheet for the MSP430FR6989 that is used:
http://www.ti.com/lit/ds/symlink/msp430fr6989.pdf

Here is the user guide for the MSP430FR6989 that is used:
http://www.ti.com/lit/ug/slau367j/slau367j.pdf

We believe the hardware is connected correctly, as it is connected just like this (except the resistors are 8.2k to work, I do not know why but if I go any higher it won't work).
http://www.electroschematics.com/wp-con ... 1/2F-3.png

The only hardware problem that comes to mind is the fact that we are not quite sure what to do with the CAM_GPIO pin. The CAM_CLK only does the camera's LED (strange right?), but the GPIO is perhaps a power on for the sensor? We aren't really sure. We tried both VCC and GROUND, but nothing worked.


Here is the code that we are currently using for it in Code Composer:

//Author: MakerSat
//MSP430FR6989 with Rasberry Pi Camera V1.3 (OV5647 imaging sensor)
//Goal: Get Slave ID from Rasberry Pi Camera with I2C on Oscilliscope
///////////////////////////////////////////////////////////////////
//                MSP430FR6989       OV5647
//                  master           slave
//
//                  P1.7/SCL <--------> SCL0
//                  P1.6/SDA <--------> SDA0
//                  3.3V <--------> 3.3V
//                   GND <--------> GND
///////////////////////////////////////////////////////////////////
#include 
#include "msp430fr6989.h"
#include 
#include 

uint16_t registerAddress;

void init_i2c(uint16_t slaveAddress);

void singleBytewrite(uint16_t slaveAddress, uint16_t registerAddress, uint8_t setBits);

/*****Initalizes I2C*****/
void init_i2c(uint16_t slaveAddress) {                                                            


   UCB0CTLW0 |= UCSWRST;                         // Enable SW reset (it is naturally, but double check)
   UCB0CTLW0 = UCSSEL_2 + UCSWRST;                // Use SMCLK (undoes reset, so telling it to stay on reset)

   UCB0CTLW0 |= UCMST + UCMODE_3 + UCSYNC;    // multi-Master, master mode, I2C, synchronous mode, use SMCLK
   
   UCB0BRW = 10;                                            // fSCL = SMCLK/10 = ~100kHz 
   UCB0BR1 = 0;                                               // UCB1I2COA |= 0x0630;

   UCB0I2CSA = slaveAddress;                          // Where the Master store's the Slaves ID (0x6C for write, 0x6D for read)   
   UCB0CTLW0 &= ~UCSWRST;                // set eUSCI_B to Clear SW reset, resume operation 

   
   UCB0IE |= UCTXIE0 | UCRXIE0 | UCNACKIE;       // Enable Transmit interrupt, receive interrupt, and the NACK interrupt 
   }

void singleBytewrite(uint16_t slaveAddress, uint16_t registerAddress, uint8_t setBits) {

   UCB0CTLW0 |= UCTR + UCTXSTT;         // set eUSCI_B to transmitter mode then create START condition       
   UCB0TXBUF = slaveAddress;                  // sends slave address

   while (0){};                  
   UCB0TXBUF = registerAddress;               // register address in transmission buffer   
   
   while (!(UCB0IE & UCTXIFG0));
   UCB0TXBUF = setBits;                     // setBits in transmission buffer ***write data***               
   UCB0CTLW0 |= UCTXSTP;                     // set eUSCI_B to STOP condition                           
   }


/*****main*****/
int main(void) {
   WDTCTL = WDTPW | WDTHOLD;                  // Stop watchdog timer
   PM5CTL0 &= ~LOCKLPM5;                   // Disables high-impedance mode for FRAM memory

   uint16_t slaveAddress = 0x6C;         // slave address for writing to OV5647 according to datasheet (0x6C for read,  
                                                                                       //0x6D for write)

   registerAddress = 0x3D;               // the last half of register address 0x503D
   uint8_t setBits = 0x01;                        // enable test pattern

   P1SEL0 |= BIT6 + BIT7;                      // init P1.6 and 7, primary not I/O
   P1SEL1 &= ~BIT6 + ~BIT7;

   init_i2c(slaveAddress);                   // starts I2C function with OV5647 slave

   singleBytewrite(slaveAddress, registerAddress, setBits);      // starts function to write 1 byte to slave register

   LPM0;                                 // Ends program in low power mode
}

Any and all help is appreciated.

  • 0
    Genius 5495 points

    Very funny.

    The problem is that NASA usually seeking for partnership with highly skilled groups by paying to NASA licenses for technologies. I wonder why they donate to group who no not even understand how such "very specific" camera operates. Ok. First of all, do you understand guys, that low orbiting satellites cannot keep their orbit longer than a few months, what safe orbits, what type, speed and power transmission to use to communicate to ground, propagation and over specific space features, what frequencies to use not to disturb overs? Secondly, about such "specific" cameras. I2C port is restricted in low transition protocol. It is obvious that video data will not go through it. But MCU will not even communicate to the camera because the camera needs external frequency oscillation.
    Look, this is not an Arduino community, be a little bit more professional in your questions and requests. In respect of TI, NASA and space.

    Alexey

  • 0
    Guru 295230 points

    The oscilloscope would show (if the screenshot were not missing) why larger resistors do not work.
    Please add a safety factor by making them smaller than 8.2 kΩ.

    The actual problem is that you're using the wrong slave address.
    I²C addresses have 7 bits. The first byte of an I²C transaction contains both the address and the read/write bit. This byte might be called "address byte", but its value is not the same as the address. The OV5647 datasheet, of course, uses the wrong name. (This is very common; you always have to look out for this.)

    If you look at the documentation of the I2CSA register, you see that it needs to be set to the actual address, not to the value of the address byte. (Whether to do a read or write transaction is determined by the UCTR bit.)

  • 0
    Genius 5495 points
    A little tip: provide at least 8 MHz SMCLK from MCU to camera module.
  • 0 in reply to Alexey Bagaev
    Guru 11940 points

    Look, this is not an Arduino community, be a little bit more professional in your questions and requests. In respect of TI, NASA and space.

    Perhaps because NASA's Paperclip-boys are all retired, or dead already ... ;-)

    BTW, the I2C interface on the RPI cam is just for config and control, not for data ...

  • 0 in reply to f. m.
    Genius 5495 points

    f. m. said:
    BTW, the I2C interface on the RPI cam is just for config and control, not for data ...

    If you read my post more carefully there were no statements about "data".

  • 0 in reply to f. m.
    Genius 5495 points

    f. m. said:
    Perhaps because NASA's Paperclip-boys are all retired, or dead already ... ;-)

    95% of TI employees is about 35 years or older. There are no too much newcomers in NASA too because people need to be skilled enough. This work is definitely not for baby-boys, baby-toys.

  • 0 in reply to Alexey Bagaev
    Guru 11940 points

    If you read my post more carefully there were no statements about "data".

    You are correct - this comment was more directed toward the OP. Just didn't want to write multiple posts at once for different topics on a single thread.

  • 0 in reply to Alexey Bagaev
    Guru 11940 points

    95% of TI employees is about 35 years or older. There are no too much newcomers in NASA too because people need to be skilled enough. This work is definitely not for baby-boys, baby-toys.

    ...deleted my answer before sending it. Guess that might have got me banned from the forum.
    To drop a hint, I'm not at all impressed by the output of the (Bolognia-Process-aligned) higher education in recent years.

  • 0 in reply to Alexey Bagaev
    Prodigy 130 points
    I am sorry if my earlier post was unclear. We are not NASA engineers, we are an undergraduate research team trying to develop a new CubeSat. NASA has helped fund this project to ensure its success.

    We do know the general background of how satellites work. We also know that an image going through I2C lines would be...problematic. Thankfully, these cameras have dedicated data lines (CAM1_DN0/1 & CAM1_DP0/1) which can be seen here:

    e2e.ti.com/.../1908038

    The camera has its own crystal oscillator on the board, but the MSP430 can be used if that doesn't pan out. Sorry if my question was "unprofessional," I was just looking for a bit of help with the MSP430 from the same community that created it.
  • 0 in reply to Aaron Ewing
    Guru 11940 points

    I am sorry if my earlier post was unclear. We are not NASA engineers, we are an undergraduate research team trying to develop a new CubeSat. NASA has helped fund this project to ensure its success.

    You shouldn't take all thos comments too serious. People here like to digress sometimes ...

    ...with the MSP430 from the same community that created it.

    Not exactly. An "e2e" forum is provided by a company (TI) as a platform to discuss it's products (MSP432). So most posters are not TI employees, but users like you. Some times with a little more experience, though.

    But back to your problem - have you noticed Clemens' suggestion ? The specification of I2C addresses is in fact a little messy in many datasheets, since each device implicitly occupies two addresses. Try shifting the address left by one bit.

    Checking the signal with a scope is a good idea. However, don't forget the check it as close to the slave IC pins as possible. What the master sends might not be what the slave sees ...

    BTW, I have trouble believing that this camera (and the RPi) work at temperatures close to 0°K.

  • 0 in reply to Aaron Ewing
    Genius 5495 points
    You are right. These OmniVision cameras for RPi have intermediate schematics. Sorry for all such posts. I expected direct connection of OV5647 to MSP430FR6989. I had no I2C problems with over OV camera connected to MSP.
  • 0 in reply to f. m.
    Guru 295230 points
    each device implicitly occupies two addresses

    This again uses wrong terminology.

    Each device occupies one address.
    Due to the additional R/W bit, there are two values of the address byte that refer to the same address.

  • 0 in reply to f. m.
    Genius 5495 points

    f. m. said:
    BTW, I have trouble believing that this camera (and the RPi) work at temperatures close to 0°K.

    I also have trouble believing in CubeSat story, despite I saw this video:

    But I probably should not post anything here more. My help is having bad reputation. :)

  • 0 in reply to Alexey Bagaev
    Guru 11940 points

    But I probably should not post anything here more. My help is having bad reputation. :)

    That depends ...

    Superficially, the NASA is a honourable organisation. But digging a bit deeper, o lot of very fishy things come up. How many people know that Walter Dornberger was von Braun's boss (at one time) not only at NASA, but also a few decades earlier, somewhere else ?

    A healthy distrust in tax-founded, governmental organisations is o.k. for me ...

  • 0 in reply to Clemens Ladisch
    Guru 11940 points

    This again uses wrong terminology.

    Each device occupies one address.
    Due to the additional R/W bit, there are two values of the address byte that refer to the same address.

    I guess you are formally correct. But on the bus, this appears as two different values of the address byte, thus "two different addresses".

  • 0 in reply to f. m.
    Genius 5495 points

    I lack expertise in mechanical engineering. The NASA technologies could help in this, but their royalties are too expensive for me :), but it is not an issue for a big company or group. (Just to show that all is quiet rational).

  • 0 in reply to f. m.
    Genius 5495 points

    But in practice there is 99.999% chance that no one will support such initiative. This is a social aspect.

**Attention** This is a public forum