• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 504 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430F5638 USCI_B1 MSP430Ware Problem

Roger Heil
Prodigy 190 points
Other Parts Discussed in Thread: MSP430F5638, MSP430WARE

Hi,

I have a problem with the USCI_B1 of the MSP430F5638. When I use these Ports (P8.5 and P8.6) as Soft I²C erverything is doing fine. But when I change to hardware I²C, there is no diference between MSP430Ware functions and "by hand" programming. The hardware I²C do not detect the ACK or let the slave set the ACK.

Maybe someone has a solution for it..

THX

R.

  • 0
    Guru 227245 points

    Are the pins selected for module usage by setting BIT5/BIT6 in P8SEL? If not, the pins are still in GPIO mode and the hardware I2C is not connected to the pins.

  • 0 in reply to Jens-Michael Gross
    Prodigy 190 points

    Hi, here my MSP430Ware Sourcecode:

    GPIO_setAsPeripheralModuleFunctionInputPin(__MSP430_BASEADDRESS_PORT8_R__, GPIO_PORT_P8, GPIO_PIN5 + GPIO_PIN6);

    I2C_masterInit(__MSP430_BASEADDRESS_USCI_B1__, I2C_CLOCKSOURCE_SMCLK, UCS_getSMCLK(__MSP430_BASEADDRESS_UCS__), I2C_SET_DATA_RATE_100KBPS);

    I2C_setSlaveAddress(__MSP430_BASEADDRESS_USCI_B1__,0xC8);
    I2C_setMode(__MSP430_BASEADDRESS_USCI_B1__, I2C_TRANSMIT_MODE);
    I2C_enable(__MSP430_BASEADDRESS_USCI_B1__);
    I2C_enableInterrupt(__MSP430_BASEADDRESS_USCI_B1__,I2C_TRANSMIT_INTERRUPT);

    while(1)
    {
    I2C_masterMultiByteSendStart(__MSP430_BASEADDRESS_USCI_B1__,0x15);
    I2C_masterMultiByteSendNext(__MSP430_BASEADDRESS_USCI_B1__,0x00);
    I2C_masterMultiByteSendNext(__MSP430_BASEADDRESS_USCI_B1__,0x30);
    I2C_masterMultiByteSendStop(__MSP430_BASEADDRESS_USCI_B1__);

    I2C_clearInterruptFlag(__MSP430_BASEADDRESS_USCI_B1__, I2C_TRANSMIT_INTERRUPT);

    }

    #pragma vector = USCI_B1_VECTOR
    __interrupt void USCI_B1_ISR (void)
    {
       switch (__even_in_range(UCB1IV,12)){
       case USCI_I2C_UCTXIFG:
       {

          __no_operation();
          break;
       }
    }

    In this ISR, I made a breakpoint, but the µC do not jump into this routine. On the oscilloscope the µC made alle 9 clock pulse for the byte, but the ACK form the slave won't be detected. 

    Also I found out, that when I use the libary, then the slave address woun't be sent right. I will send a 0xC8 and I get an 0x90. When I send a 0x64, then I get a 0xC8. I do not catch on this behavior.

  • 0 in reply to Roger Heil
    Guru 227245 points

    Roger Heil said:
    GPIO_setAsPeripheralModuleFunctionInputPin(__MSP430_BASEADDRESS_PORT8_R__, GPIO_PORT_P8, GPIO_PIN5 + GPIO_PIN6);

    This line looks suspicious. I don't knwo this funciton, but why giving a baseaddress for P8 and another parameter GPIO_PORT_P8? This appears superfluous and maybe it results in BIT5+6 set not in P8SEL but rather somewhere else.

    I really dislike those HAL functions. They are way more complex to write than a simple "P8SEL |= BIT5|BIT6;" and also obfuscate what's really going on.

    Roger Heil said:
    Also I found out, that when I use the libary, then the slave address woun't be sent right. I will send a 0xC8 and I get an 0x90. When I send a 0x64, then I get a 0xC8. I do not catch on this behavior.

    0xc8 is no valid I2C slave address. I2C addresses are 7 bit. Which 0xc8 obviously isn't.
    Your 0xc8 apparently already includes the R/W bit (write, in this case, as the LSB is 0), that is part of the address byte, but not part of the address itself. (Many manufacturers simply combine these two independent things into a read address and a write address. But this is not correct and the original Philips/Valvo (inventor of I2C) I2C device datasheets have never done this too.

**Attention** This is a public forum