• Not Answered

DAC7564 with MSP5438

Hi all.....

Please help in below matter regarding usage of SPI interface.

 

I was writing code for DAC7564 interface with MSP using 3 wire SPI. Is there any need to set the CCKPL and CCKPH bits here in case of DAC7564. When should one decide to set the clock polarity bits based on the slave timing diagram.

I am using XT2 crystal 16Mhz and MCLK = 16Mhz followed by SMCLK at 8MHZ .

As per hardware is concerned i am uisng internal reference. I am sometimes able to power down the internal reference using the code below and update channel A sometimes by changing just the bytes to be sent it dos not function properly. Also i observed the UCOE flag sets after I transmit the first byte alongwith TXIFG andRXIFg flags. As per in user guide as soon as we write in UCB2TXBUF the UTXIFG flag clears automatically but it does not happen so when i debugged the code step by step.

Also when i measured the UCLK it shows 1.56Mhz. What is the role of UCB2BR0  register here.

 

void SPI_INIT(void)

{

_P9SEL.bit.P9SEL_0 = 0;   // configure as chip select pin

_P9DIR.bit.P9DIR_0 = 1;      // configure as output pin

_P9SEL.bit.P9SEL_3 = 1;  

_P9SEL.bit.P9SEL_1 = 1;  

UCB2CTL0 |= (UCMSB + UCMST + UCSYNC + UCCKPH); // 3-pin, 8-bit SPI mstr, MSB 1st,CPHA =1,CPOL=0

UCB2CTL1 |= UCSSEL_2;    // SPI clk source----> SMCLK 8Mhz

UCB2BR0 = 0x02;

UCB2BR1 = 0;

UCB2CTL1 &= ~UCSWRST; //**Initialize USCI state machine**

// IE2 |= UCB0TXIE; //Enable SPI transmit interrupt

}

 

Considering that I have initialized the SPI module as per the sample code. My transmit routine is as follows:-

 

void SPI_TRANSMIT(unsigned char byte)

{

while (!(UCB2IFG & UCTXIFG));

UCB2TXBUF = byte;

}

i am calling the above function as shown below in main.c

SPI_START(); //pull sync line low (simple port pin)

SPI_TRANSMIT(0x01);

 SPI_TRANSMIT(0x12);

SPI_TRANSMIT(0x00);

SPI_STOP();  //pull sync line high

 

 

regards,

harshit

3 Replies

  • harshit

    When should one decide to set the clock polarity bits based on the slave timing diagram.

    The slave diagram will show whether the slave requires the clock to "idle" high or low.  The slave diagram will also show whether the slave uses the first clock edge as a latching edge or as a output-changing edge.  You must configure the MSP430 clock-phase and clock-polarity bits accordingly to match the slave.  Slaves are often compatible with two of the four possible settings.

    harshit

    Also i observed the UCOE flag sets after ...

    That's OK.  That happens because you are not reading the RXBUF.  It therefore overruns after you transmit (exchange) more than one byte.  No problem.

    harshit

    as soon as we write in UCB2TXBUF the UTXIFG flag clears automatically but it does not happen so

    You might never see UTXIFG flag clear in your code.  The first TX byte goes almost immediately into the shift register which frees TXBUF again (keeping UTXIFG set).  Only if you put another byte into TXBUF right away would you have any chance of seeing that the TXBUF is full (UTXIFG clear).  Your SMCLK is so fast that you would likely still never see UTXIFG clear.  However, if you use the debugger to stop SMCLK during emulation stops, then you might see UTXIFG clear sometimes.  In short, don't worry about this.

    harshit

    Also when i measured the UCLK it shows 1.56Mhz. What is the role of UCB2BR0  register here.

    It's a divider.  So your UCLK rate is nominally 8MHz / 2 = 4MHz.  Maybe you are not keeping the SPI bus busy.  If you look at UCLK on a scope, you will probably see bursts of 8 clock cycles separated by some idle time.  Plus maybe bursts of 8-8-8 then a larger idle time.  Maybe that's why you're measuring only 1.56 MHz?  How are you measuring 1.56 MHz?  Scope?  Frequency counter?

    Jeff

  • In reply to Jeff Tenney:

    Jeff Tenney
    How are you measuring 1.56 MHz?  Scope?  Frequency counter?

    Its a multi function scope which directly gives the frequency readout.

    So as such the software seems to be ok??????

     

    But what might be causing the problem for the reference not getting power down even though i am sending the apparopriate commands to the DAC register.

    Jeff Tenney
    If you look at UCLK on a scope, you will probably see bursts of 8 clock cycles separated by some idle time.

    also yes i could see bursts of 24 clock pulses of duration of 6us and also my sync signal remains low for 6us. Is it the timing problem????

     

     

    regards,

    Harshit

     

  • In reply to harshit:

    harshit

    also yes i could see bursts of 24 clock pulses of duration of 6us and also my sync signal remains low for 6us. Is it the timing problem????

    Your timing seems OK.  24 clock pulses in 6us is the expected 4 MHz.

    A quick look at the DAC data sheet shows that it doesn't care whether the clock idles high or low, but it latches data on the falling edge.  So that means it's compatible with MSP430 settings CKPH=CKPL=1 and also CKPH=CKPL=0.

    However, your code isn't setting these bits correctly.  Once you fix these settings, you'll probably see more consistent behavior.

    I noticed that your comments refer to Motorola SPI settings by name (CPHA and CPOL).  TI inverted the meaning of the CPHA bit from the Motorola standard. TI calls it CKPH, and it is the opposite of CPHA.  (Thanks TI!)  The other bit (CPOL, which TI calls CKPL) is the same as Motorola.  That weirdness may have contributed to your configuration error.

    Jeff