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.

troubles with I2S (TLV320AIC3254) СС430F5137

Other Parts Discussed in Thread: TLV320AIC3254

In my project I have:

- SPI (for the work with SD card): configured for USCI_A0;

- I2C (CC430 - how master, it configures TLV320AIC3254): configured for USCI_B0;

- I2S(through SPI mode) (CC430 - how slave of the TLV320AIC3254 for receiving audio): configured for USCI_B0 (after work with I2C).

This configuration is wrong, because "UCA0CLK function takes precedence over UCB0STE function".

I am going to configure I2S in "ASI Hybrid Modes" (BCLK is input and WCLK is output). Do anyone that?

But now, I simply try to receive any data from the codec with help of USCI_B0:

//================================== code ===========================================//

__disable_interrupt();
PMAPPWD = 0x02D52; // Get write-access to port mapping regs
PMAPCTL |= PMAPRECFG; //Enable reconfig during runtime
P3MAP5 = PM_UCB0SOMI; // Map UCB0SIMO output to P2.0
P3MAP4 = PM_UCB0SIMO; // Map UCB0SOMI output to P2.2
P3MAP3 = PM_UCB0CLK; // Map UCB0CLK output to P2.4
P3MAP2 = PM_UCB0STE; // Map UCB0CLK output to P2.4
PMAPPWD = 0; // Lock port mapping registers

P3DIR |= BIT2;
P3DIR |= BIT3;
P3DIR |= BIT4; // ACLK, MCLK, SMCLK set out to pins
P3DIR |= BIT5; // ACLK, MCLK, SMCLK set out to pins

P3SEL |= BIT2;
P3SEL |= BIT3;
P3SEL |= BIT4; // P2.0,2,4 for debugging purposes.
P3SEL |= BIT5; // P2.0,2,4 for debugging purposes.

UCB0CTL1 |= UCSWRST; // **Put state machine in reset**
UCB0CTL0 = UCSYNC | UCCKPL | UCMSB | CS; // 4-pin, 8-bit SPI slave, CS = 0 - active;
// Clock polarity high, MSB

UCB0BR0 = 0x02; // /2 (for slave doesn't mean anything)
UCB0BR1 = 0; //

UCB0CTL1 &= ~UCSWRST; // **Initialize USCI state machine**
UCB0IE |= UCRXIE;
__bis_SR_register(GIE);

//================================== code ===========================================//

In the interrupt I receive only 0xFF values, but when I reconfigure I2S for USCI_A0:

//================================== code ===========================================//

__disable_interrupt();
PMAPPWD = 0x02D52; // Get write-access to port mapping regs
PMAPCTL |= PMAPRECFG; //Enable reconfig during runtime
P3MAP5 = PM_UCA0SOMI; // Map UCA0SIMO output to P2.0
P3MAP4 = PM_UCA0SIMO; // Map UCA0SOMI output to P2.2
P3MAP3 = PM_UCA0CLK; // Map UCA0CLK output to P2.4
P3MAP2 = PM_UCA0STE; // Map UCA0CLK output to P2.4
PMAPPWD = 0; // Lock port mapping registers

P3DIR |= BIT2;
P3DIR |= BIT3;
P3DIR |= BIT4; // ACLK, MCLK, SMCLK set out to pins
P3DIR |= BIT5; // ACLK, MCLK, SMCLK set out to pins

P3SEL |= BIT2;
P3SEL |= BIT3;
P3SEL |= BIT4; // P2.0,2,4 for debugging purposes.
P3SEL |= BIT5; // P2.0,2,4 for debugging purposes.

UCA0CTL1 |= UCSWRST; // **Put state machine in reset**
UCA0CTL0 = UCSYNC | UCCKPL | UCMSB | CS; // 4-pin, 8-bit SPI slave, CS = 0 - active;
// Clock polarity high, MSB

UCA0BR0 = 0x02; // /2 (for slave doesn't mean anything)
UCA0BR1 = 0; //

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

__delay_cycles(100); // Wait for slave to initialize

UCA0IE |= UCRXIE;
__bis_SR_register(GIE);

//================================== code ===========================================//

After that codec send to me some data properly. 

What are the differences between USCI_A0 and USCI_B0?

Why they work differently?

  • Oleg Yurchenko said:
    - SPI (for the work with SD card): configured for USCI_A0;
    This configuration is wrong, because "UCA0CLK function takes precedence over UCB0STE function".

    So the SD card is SPI master and controls the data transfer to the MSP? I fnot, then you don't need or have to use STE, because STE is for controlling the MSP clock input and MISO output when the MSP is slave, or master/slave ina multi-master environment.

    If the MSP is mSPI master, as it likely is when the slave is an SD card, then you need 3-wire SPi mode (without STE). The chip select, that is needed for each SPi slave individually, is provided by a simple, software controlled GPIO pin. One per slave.
    Your software is responsible to select and deselect teh slave before and after a transfer. The SPI hardware doesn't know how many bytes you want to read or write, whether the high-level protocol requires CS toggled between each two bytes or once for a whole high-level communication. In othe rwords: the USCI SPI doesn't care for chip-selecting your slave.

    Oleg Yurchenko said:
    What are the differences between USCI_A0 and USCI_B0?

    USCI_A0 has UART fucntionality while USCI_B0 has I2C funcitonality and both have SPI.
    And USCI_x0 and USCI_x1 (or 2 or 3) are multiple independent instances of an USCI module and work independently.

  • Thanks for answer, Jens-Michael

    I'm sorry, probably, I explained my trouble badly. Of course, SPI for SD is configured how master and work fine alone. But when I try to configure it with I2S together, I have the problem: UCA0CLK (for SPI(msp-master) for SD) function takes precedence over UCB0STE (for I2S(msp-slave), audio codec uses it for sync with msp), so audio codec cannot work with msp (in "master(codec) - slave(msp)" mode).

    When I use I2S only (without configure SPI for SD), it works fine, but if I use USCI_A0(msp-slave) - it works, if I use USCI_B0(msp-slave) - it don't work at all. And I don't understand - why? I configure USCI_B0 how I2C so that configure audio codec, after that I reconfigure USCI_B0 how I2S (it don't work) or I reconfigure USCI_A0 how I2S(it works).

    Excuse me, my English leaves much to be desired

  • Oleg Yurchenko said:
    But when I try to configure it with I2S together, I have the problem: UCA0CLK (for SPI(msp-master) for SD) function takes precedence over UCB0STE (for I2S(msp-slave),


    Well, since both signal share the same physical pin and therefore the same line, you cannot have both functions active at the same time. Else the I2S STE signal would be taken as clock for the SD card SPI and v.v.
    But usually, you don't need STE at all. You only need it if you are slave in a system with multiple slaves, or master on a multiple master bus.
    STE just deactivates the clock input and the slave output. It doesn't do any synchronizing or whatever. This must be done by software anyway, so you can as well go without STE and do it manually based on the chip select signal on any I/O pin (preferably one with interrupt capabilities).

  • Thank you very much! I will try to do what you advised to me.

    And second question is resolved: after using USCI_B(how I2C), you need to remap ports I2C so that USCI_B (how I2S(SPI)) work properly:

    //==================code=========================//

    //.........init USCI_B how I2C:

    //....

    PMAPPWD = 0x02D52; 
    PMAPCTL |= PMAPRECFG;         // Enable reconfig during runtime

    P3MAP6 = PM_UCB0SDA;           //  Map UCB0SDA output to P3.6
    P3MAP7 = PM_UCB0SCL;           //  Map UCB0SCL output to P3.7

    PMAPPWD = 0;

    P3SEL |= BIT6 | BIT7;              // Select P3.6 & P3.7 to I2C function


    //.........init USCI_B how I2S(SPI):

    //....

    PMAPPWD = 0x02D52; 
    PMAPCTL |= PMAPRECFG;         //Enable reconfig during runtime

    P3MAP6 = PM_NONE;                 // remap ports for I2C
    P3MAP7 = PM_NONE;

    P3MAP5 = PM_UCB0SOMI;
    P3MAP4 = PM_UCB0SIMO; 
    P3MAP3 = PM_UCB0CLK; 
    P3MAP2 = PM_UCB0STE; 
    PMAPPWD = 0;

    P3SEL &= ~(BIT6 | BIT7);             // DeSelect P3.6 & P3.7 to I2C function

    //==================code=========================//

  • Oleg Yurchenko said:
    after using USCI_B(how I2C), you need to remap ports I2C so that USCI_B (how I2S(SPI)) work properly:

    AFAIK, the port mapping controller can only be accesse donce. After locking it (or self-lockign due to access timeout) it remains locked and doesn't accept any further remapping.

    It is totally valid to map the same output signal to multiple pins. And if you map the same input signal to multiple pins, then the two inputs are ORed.

    So teh important part (even though I don't see why) is probably the P3SEL line.

  • Jens-Michael Gross said:

    So teh important part (even though I don't see why) is probably the P3SEL line.

    Yes, this is the first thing, what I've tried to fix. Because I found out the unknown activity on the line SDA, when I tried to use USCI_B how I2S (I2C didn't work in this time). This fix lets me stop activity on the SDA line, but it didn't resolve the main problem - from UCB0SIMO I received 0xFF only. When I tried to remap ports for SDA and SCL - it started to work properly!
  • Oh, yes, I see.
    I have now checked this MSPs mapping configs in detail, and PM_UCB0SIMO and PM_UCB0SDA are an alias of the same setting. So of course when mapping the same function (despite of the two different symbol names) to two (or more) pins, you get the two port signals OR'd, which results (due to the pullup on the inactive SDA line) in 0xff. And the de-selecting of the other pin will disconnect it form the physical pin, but internally, the port mapping controller will still OR the two signals, one of them now a fixed '1'.
    So re-mapping is indeed the required step, and the PM controller allows continued re-mapping because you set the PMAPRECFG bit (many of the demo codes don't do it, causing the first mapping to be final.)

**Attention** This is a public forum