• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 79 subscribers
  • Views 340 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.

MSP430FR5994: I2C ACk after Address but not after the first dats byte

Hardy Zissel
Intellectual 500 points
Part Number: MSP430FR5994

Data bytes are to be transmitted from the I2C master to the slave. The slave sends an ACK after the address but not after the data bytes. The RX register is 0x00.

A very slow clock rate is used. Master and slave are located in the same IC (master: UCB1, slave: UCB2).

The resistors at SDA and SCL are 4.7kOhm. The oscilliscope shows the levels of the lines when sending the address (0x48) and a data byte (0xA5).

This is the initialisation of the master:

Fullscreen
1
2
3
4
5
6
7
// Configure USCI_B0 for I2C mode
UCB1CTLW0 |= UCSWRST; // Software reset enabled
UCB1CTLW0 |= UCMODE_3 | UCMST | UCSSEL__SMCLK; // I2C mode, Master mode, sync
UCB1BRW = 0x1388; // baudrate = SMCLK / x
UCB1I2CSA = 0x000A; // Slave address
UCB1CTLW0 &= ~UCSWRST; // clear reset register
UCB1IE |= UCRXIE | UCTXIE | UCNACKIE | UCBCNTIE;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

This is the initialisation of the slave:

Fullscreen
1
2
3
4
5
6
// Configure USCI_B0 for I2C mode
UCB2CTLW0 |= UCSWRST; // Software reset enabled
UCB2CTLW0 |= UCMODE_3 | UCSYNC; // I2C mode, sync mode
UCB2I2COA0 = 0x000A | UCOAEN; // own address is 0x0A + enable
UCB2CTLW0 &= ~UCSWRST; // clear reset register
UCB2IE |= UCTXIE | UCRXIE0 | UCSTPIE;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

This is what the oscilloscope shows:

Please help to eliminate the problem.
Is there anything special to consider when master and slave are in the same IC? What could be the reason if the address is confirmed but the data is not?
Thank you very much for your help!

Regards
Hardy

  • 0
    Guru 94780 points

    My reading of that scope trace is that the slave is stretching the clock (so there's no ACK cycle yet), presumably because it hasn't read RXBUF.

    The main consideration for hosting both sides in a single MCU is to avoid having either lock out the other. 

    Also, be very careful about the priority of UCSTPIFG. I usually try to find a way to avoid using it.

  • 0 in reply to Bruce McKenney
    Intellectual 500 points

    Thank you for the answer.
    I don't understand the stretching of the clock by the slave. Does the slave actually influence the clock? Isn't it just the receiver of the clock pulses? I had understood the oscillogram in such a way that after the transmission of the last 1-bit of 0xA5 there is still one clock edge and assumed that this is for the request of the ACK.
    By the way, no interrupt is called on the slave side. We will experiment with DMA.
    Is reading RXBUF really a condition for generating ACK?
    Many greetings
    Hardy

  • 0 in reply to Hardy Zissel
    Guru 94780 points

    The Slave can stretch (hold low) the SCL line. The stretching criteria are listed in User Guide (SLAU367P) Sec 32.3.7.2. Sec 32.3.5.1.2 mentions that the first (received) data byte is always ACK-ed. 

    If the Slave side isn't seeing any interrupts that might explain why RXBUF isn't being read. What do you see in UCB2IFG? What is the Master side doing at this time?

  • 0 in reply to Bruce McKenney
    Intellectual 500 points

    The master transmits when a transmit interrupt is triggered. The UCB2IFG is 0x04. This is the case when a byte is sent and also when several bytes have been sent. UCB2IE is 0x000B after stop sending.
    I suspect that UCB2 is missing a setting to work.

    Thanks for help.

  • 0 in reply to Hardy Zissel
    Guru 94780 points

    The UCSTTIFG indicates that the I2C unit accepted the SLA byte, so it's generally operational. How do you tell that the Slave side interrupt never triggers? A breakpoint in the ISR?

    As a quick experiment, you might try speeding up the clock. Yes, I know it's supposed to work down to 0Hz, but sometimes it's good to check assumptions.

    Also, what does the Master do with UCBCNTIFG? With UCASTP=0 I expect it will never trigger, but seeing it there suggests there's some other relevant code we haven't seen.

  • +1 in reply to Bruce McKenney
    Intellectual 500 points

    In the meantime, we have seen that a capacitor on the PCB is incorrectly fitted. As a result, the signals do not arrive at the receive pin as a square wave.
    Thank you very much for your help. Nevertheless, we got some interesting facts.
    Greetings
    Hardy Zissel

**Attention** This is a public forum