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.

IC2 MSP430 G2553 and G2432

Other Parts Discussed in Thread: MSP430WARE, MSP430G2553, MSP430G2432

Hi all,

I am making my first steps into using IC2 on the MSP430 value line devices, using code examples supplied in the latest MSP430Ware.  The examples are as follows:

MSP430G2553 has msp430g2xx3_uscib_i2c_04  - This is the Master using the USCI and should receive a single byte from the MSP430 slave.

MSP430G2432 has msp430g2xx2_usi_09 - This is the Slave using the USI and should transmit a single byte to the MSP430 master.

I have the devices connected via a breadboard, with Vcc from one board connected via 10k resistors to the SDA and SCL lines (P1.6 SDA and P1.7 SCL) as per the code example.  I have given them a common ground as well, as attempting to run them off 2 computers.

So at the moment not a lot appears to happen, when I run the master, the slave reacts and jumps into the interrupt and the red LED is illuminated.  But the code then jumps to the end not executing the state machine code.  I suspect this is due to the process timing out as I step through the code, however if I just run both devices and press reset on the master the red LED is again illuminated (staying on) on the slave as when I stepped through the code.

I don't have access to an oscilloscope at the moment, but not 100% aufait with IC2.

So really after some advice and if I am going the wrong way about this, any suggestions appreciated.

Thanks in advance,

Ant

0728.msp430g2xx3_uscib0_i2c_04.c
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/* --COPYRIGHT--,BSD_EX
* Copyright (c) 2012, Texas Instruments Incorporated
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* * Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* * Neither the name of Texas Instruments Incorporated nor the names of
* its contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0160.msp430g2xx2_usi_09.c
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/* --COPYRIGHT--,BSD_EX
* Copyright (c) 2012, Texas Instruments Incorporated
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* * Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* * Neither the name of Texas Instruments Incorporated nor the names of
* its contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • I think that the steps you have outlined are a reasonable start to getting your system working. Common ground and pullups on the line are correct (although I tend to use 47K-ish pullups).

  • Brian,

    Thanks for confirming that, I will try a higher value for the pullups as well.

    Not sure if you have had a chance to look at the code, but is there anyway to slow the process down so I can try and identify what is happen?

    Regards,

    Ant

  • Really the best way to see what's happening at the physical layer is to probe the lines with an oscilloscope and decode the I2C transaction to make sure it looks correct.

    Barring that, another option is to connect some LEDs to unused port pins and turn them on/off at specific points in the program, but even then they might be too fast to get a good understanding.

  • Brian Boorman said:
    although I tend to use 47K-ish pullups

    Being used to digital electronics, I tend to do high-value pullups as well. But on I2C, there often is a rather high line capacitance and mroe than just one input. With 47k pullup you won't see nice signals when going to 400kBd bus speed.
    I'd recommend going for 47k to 10k fo rth eold 10kBd to 100kBd bus speed, and further down to 4k7 when using 400kBd. We had lots of forum topics where 10k wasn't enough. Even without lengthy connections and many slaves.

    After all, when the bus is in idle state, the pullup doesn't draw any current, no matter how low it is.

  • Hi Jens,

    Thanks for the information I have read on other sites 33k is a good half way value to consider.  I am still still struggling to see what is happening though with the TI code, and wondering if there is an easy way to amend the code and implement a loop in the hand shaking and data transfer, so that the Master requests the information continuously from the Slave.  Therefore the Slave should react and send the data back and I should be able to see the variables change with a breakpoint and refresh values in Code Composer.

    Best regards,

    Ant

  • Ant Scranney said:
    Thanks for the information I have read on other sites 33k is a good half way value to consider.

    It really depends on clock speed, line length and number of peers.

    As for the application, many slaves offer a' new data ready' signal which is checked by the master and then data is read.
    You may as well initiate a transfer and continuously read data, while the slave updates it when available. But this will waste quite some CPU power and also keeps the bus busy.

    However, with the USCI, you cannot simply stop polling data and continue later, as the USCI uses double-buffering, continuing to read data while you haven't even read the last one. So stopping a read transfer by jsut holding the clock, and continuing later, is a bit difficult on I2C.

**Attention** This is a public forum