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.

CAPTIVATE-PHONE: CAPTIVATE sample program does not work (Technology Guide1.83.00.08.)

Part Number: CAPTIVATE-PHONE
Other Parts Discussed in Thread: MSP-EXP430FR2311, CAPTIVATE-PGMR, MSP430FR2633

Tool/software:

It doesn't work as the sample software suggests. Please tell me how to get it to work.

1: I'm using CAPTIVATE-PHONE. (Not BSWP. This is different from the sample.)

2: I'm looking at CapTIvateTm Technology Guide1.83.00.08.

3: I'm trying Software Library -> Advanced Module -> Hostprocessor Communication Examples.

4: When I sent 0x0Ah, 0x0h, 0x0h from MSP-EXP430FR2311, there was no ACK signal for the second 0x0h.

4-1: There is an ACK signal for 0x0Ah and 0x0h from the start.

4-2: It's the same before the last ACK in Fig.246.

5: I assume there is some kind of abnormality on the CAPTIVATE-PGMR HID side, which is why there is no ACK.

6: Please tell me how to satisfy Fig.247 REGISTER_I2C Logic Read(Zoom).

  • I would suggest you refer to this doc. It will tell you how to customize the communication:

    https://www.ti.com/lit/ug/slau857a/slau857a.pdf?ts=1695102906651&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FMSP430FR2633

    Can you double check if the problem lies on FR2311, not the MSP430FR2633? It seems that the I2C is breaked. No ACK from the master. Can you remove the FR2633 to check if the I2C will return to 3.3V? If not, the problem is mostly lies on the master side.

  • Thank you for your reply. I will read the documentation.
    I have done the following to check.
    1: To check the hardware, I used two MSP-EXP430FR2311 cards to communicate as MASTER<->SLAVE via I2C and confirmed that there were no problems.
    2: On the FR2633 side, I have confirmed that BULK_I2C works without problems. Since BULK_I2C works without problems, I believe that REGISTER_I2C, which uses the same I2C port, will also work without problems.
    3: In both cases, I have observed with an oscilloscope and confirmed that there are no problems.
    4: According to the I2C communication standard, when sending from MASTER to slave, ACK is returned from the slave to MASTER.
    4-1: If the hardware is faulty, I believe that the ACKs for the first address and the second data will not work either.
    5: From the above, I believe that it is not the hardware but the software on the slave side that is the problem.

  • Thank you for your advice.
    I confirmed that after the master finished sending the message, the timing to switch to receiving was delayed, which caused the processing of the last bit to be delayed, and I was able to fix it and solve the problem.

**Attention** This is a public forum