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.

TXIFG NEVER sets when using SPI examples (both USCI and USART) -- help please!

I have been trying to get SPI working to work with an SD card but have had no success after almost a full week. So frustrated that I decided to try to back up a bit and use the simple examples provided by the TI website.

I used:

USART:
msp430xG46x_usart1_spi0_09.c

USCI:
msp430xG46x_uscia0_spi_09.c

Regardless of which one I run, the corresponding TXIFG flag is never set. Accordingly to the manual it should be set after SWRST with either USCI or USART however as I watch the register and step through it (or run it to a break point) it is always zero, never, ever, set.

As an example, using msp430xG46x_uscia0_spi_09.c (code below), if I break on any line beginning with P5OUT &= ~0x04;  I find UCA0RXIE is set and if I let it proceed and break at _BIS_SR(LPM0_bits + GIE);    UCA0TXBUF is filled with the correct byte however, no matter what, UCA0TXIFG is zero.


Why is it always zero???


Finally, as a double check, in the USCI example, the initial comments show `Slave reset <-|P5.2` . I was wondering how people are doing this as not only is P5.2 COM1 and not GPIO, it is also not accesible by a header and I am not sure how to connect any pin to slave reset anyhow. Could use some clarity on that as well..

 

Thank you in advance,

Mike

  • Wow..

    I upgraded my version of IAR for another project I was working on. This one switched to simulator for debugger. For whatever reason, SWT in simulator does not work.

    Back to the board and the TXIFG is set. I can't believe it took me that long to figure it out. It is ALWAYS something small with uCs!

    Now, to start actually trying to get the SD card to work.. hah

  • mstarrett said:
    the initial comments show `Slave reset <-|P5.2`

    I'm not completely sure about this (I didn't check the examples) but I think this comment is related to something that's often missed when programming the MSP as an SPI slave:

    The STE pin (if used at all) just enables and disables the I/O pins, so the SOMI pin goes high an the clock is ignored. it does NOT reset the shift logic, clear the input/output registers or reset the protocol state (which is software anyway). So usually, you'll need to check the state of the STE (CS) signal and do a software reset of all this, as deselecting the slave usually means that the slave has to reset its SPI back to start.

    On the opposite direction, it is normally necessary to select the slave with any I/O pin signal before starting the SPI transfer. The SPI hardware does not know whether this has been done or not, since the requirements for this chip select may vary depending on the slave. Sometimes it is jsut used to resynchronize the transfer of single bytes, sometimes it controls the data flow between master and slave (on high-level protocol layer).

    About 5.2, it can be I/O or COM1. If you do not use multiplexed LCD, P5.2 can be used as normal GPIO pin. Even more, P5.2 has to be set to COM1 usage explicitely by setting P5SEL|=4. At power-up it is just normal GPIO.

    There are some other threads here about SPI and even SD/MMC. You should check them.

  • Hi

    I am also trying to implement sd card communication using USCI in SPI mode. I have the same problem as you of that the UCB0TXIFG flag is never set.

    I have a recently new kickstart of IAR (5.40). I do not really understand what you mean by  "SWT". Could you please explain how you solved your problem?

     

  • Hello,

    In my case IAR was not configured to send the firmware to the MCU in the workspace options. When I switched it so that it did the app took right off.

  • Thanks alot!

    It turned out I missed to do the same thing

**Attention** This is a public forum