Reply by mastarre May 30, 20102010-05-30
Aaaaaaaaaaaaaaand it works perfectly. Wow.

--- In m..., "mastarre" wrote:
>
> I have been trying to get SPI working to work with an SD card but have had no success after almost a full week. I've gotten 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. According 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
>

Beginning Microcontrollers with the MSP430

Reply by mastarre May 30, 20102010-05-30
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

--- In m..., "mastarre" wrote:
>
> I have been trying to get SPI working to work with an SD card but have had no success after almost a full week. I've gotten 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. According 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
>

Reply by mastarre May 30, 20102010-05-30
I have been trying to get SPI working to work with an SD card but have had no success after almost a full week. I've gotten 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. According 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

Reply by Microbit_Ubuntu May 27, 20102010-05-27
You have to write a tiny bit of test code.
With logic analyser it's a lot easier, but you can make do with CRO.
If your CRO doesn't trigger as well, output a sync pulse of some sort
into 2nd channel. (this could be for example the CS asserting and
de-asserting). Whatever your CRO is happy with....

Just write test code where you sit in a constant loop, wait for SPI
free, TX a byte, back to start of loop (do this eg. right after init)
Make the TX'd byte such that you have a clear bit pattern, eg. (binary)
01001100.
This will allow you to
(i) confirm that SPI is set up properly
(ii) inspect clock phase & polarity

Once that's OK, you can start looking at sending something which will
invoke a response from SPI slave. Then you can check with a breakpoint
(or print it out) that you're RXing the proper byte.

Once that's going, I'm sure your SD card will finally wake UP !! :-)

HTH
Kris

On Fri, 2010-05-28 at 01:28 +0000, mastarre wrote:
> I have never actually debugging a uC with a scope, my problems have always been in the software -- the only external hardware I have used is just the RF daughter board.
>
> I've got it on and running now but with the scope on the clock pin of the experimenters board I am not seeing any meaningful signal (its zero). Checked it on another board and got the same. I am not sure exactly what amplitude the output should be at, assuming vcc, but either way what I have clearly is not right.
>
> However, I do have:
> #define SPI_UCLK 0x08
>
> and
>
> #define MMC_UCLK SPI_UCLK
>
> and I am breaking AFTER this point:
> -------------------
> // Initialize MMC card
> char mmcInit(void)
> {
> //raise CS and MOSI for 80 clock cycles
> //SendByte(0xff) 10 times with CS high
> //RAISE CS
> int i;
>
> // Port x Function Dir On/Off
> // mmcCS Out 0 - Active 1 - none Active
> // Dout Out 0 - off 1 - On -> init in SPI_Init
> // Din Inp 0 - off 1 - On -> init in SPI_Init
> // Clk Out - -> init in SPI_Init
> // mmcCD In 0 - card inserted
>
> // Init Port for MMC (default high)
> MMC_PxOUT |= MMC_SIMO + MMC_UCLK;
> MMC_PxDIR |= MMC_SIMO + MMC_UCLK;
> // Chip Select
> MMC_CS_PxOUT |= MMC_CS;
> MMC_CS_PxDIR |= MMC_CS;
>
> // Card Detect
> MMC_CD_PxDIR &= ~MMC_CD;
>
> // Init SPI Module
> halSPISetup();
>
> // Enable secondary function
> #if SPI_SER_INTF != SER_INTF_BITBANG
> MMC_PxSEL |= MMC_SIMO + MMC_SOMI + MMC_UCLK;
> #endif
>
> //initialization sequence on PowerUp
> CS_HIGH();
> -------------------
> And I am breaking on CS_HIGH();
>
>
Reply by mastarre May 27, 20102010-05-27
I have never actually debugging a uC with a scope, my problems have always been in the software -- the only external hardware I have used is just the RF daughter board.

I've got it on and running now but with the scope on the clock pin of the experimenters board I am not seeing any meaningful signal (its zero). Checked it on another board and got the same. I am not sure exactly what amplitude the output should be at, assuming vcc, but either way what I have clearly is not right.

However, I do have:
#define SPI_UCLK 0x08

and

#define MMC_UCLK SPI_UCLK

and I am breaking AFTER this point:
-------------------
// Initialize MMC card
char mmcInit(void)
{
//raise CS and MOSI for 80 clock cycles
//SendByte(0xff) 10 times with CS high
//RAISE CS
int i;

// Port x Function Dir On/Off
// mmcCS Out 0 - Active 1 - none Active
// Dout Out 0 - off 1 - On -> init in SPI_Init
// Din Inp 0 - off 1 - On -> init in SPI_Init
// Clk Out - -> init in SPI_Init
// mmcCD In 0 - card inserted

// Init Port for MMC (default high)
MMC_PxOUT |= MMC_SIMO + MMC_UCLK;
MMC_PxDIR |= MMC_SIMO + MMC_UCLK;
// Chip Select
MMC_CS_PxOUT |= MMC_CS;
MMC_CS_PxDIR |= MMC_CS;

// Card Detect
MMC_CD_PxDIR &= ~MMC_CD;

// Init SPI Module
halSPISetup();

// Enable secondary function
#if SPI_SER_INTF != SER_INTF_BITBANG
MMC_PxSEL |= MMC_SIMO + MMC_SOMI + MMC_UCLK;
#endif

//initialization sequence on PowerUp
CS_HIGH();
-------------------
And I am breaking on CS_HIGH();

Reply by Dan Bloomquist May 27, 20102010-05-27
I decided not to use TI's example, I think for a very good reason. For
one, it is not pretty to look at, I just looked at my copy. It looks
messy and there are no timeouts.

And the Foust rules for the 430 work. I don't see where you set the
clock to 400khz unless your SMCLK is 800khz. I see you are sending 72
clocks before starting, the doc says > 73. I take it DUMMY_CHAR is 0xff.
I do a:

spi_set_divisor( SD_CLK_SLOW );

//spi_cs_assert( );
SPI_CS_ASSERT;
sd_delay( 100 );

SPI_CS_DEASSERT;
sd_delay( 10 );

// Put the card in the idle state
if( ! sd_send_command( SDCMD_0, 0 ) )
return false;

And sd_delay is a byte of 0xff so I'm sending 800 idle clocks before
even starting, and another 80 after de-assert. It works for me with my
protocal, ask Jack Bauer.

I recall playing around with the card. I do recall you have to give it
room to breath before using it. You have to stay at 400khz until you
have read the ORC. Then you can go full speed.

Best, Dan.

mastarre wrote:
> Okay, this is beginning to get beyond frustrating and I am starting to feel inept after a full year of getting projects done quickly and confidently on this uC.
>
> I still cannot get it to proceed past mmcInit(); because the SD card just will not respond back.
>
> The hardware and pins are configured the same as my original post shows.
>
> The USCI register is configured as follows:
> void halSPISetup(void)
> {
> UCA0CTL0 = UCMST+UCCKPL+UCMSB+UCSYNC; // 3-pin, 8-bit SPI master
> UCA0CTL1 = UCSSEL_2 + UCSWRST; // SMCLK
> UCA0BR0 |= 0x02; // UCLK/2
> UCA0BR1 = 0;
> UCA0MCTL = 0;
> UCA0CTL1&= ~UCSWRST; // **Initialize USCI state machine**
> }
>
> And I have the following:
> #define halSPITXREADY (IFG1&UCA0TXIFG) /* Wait for TX to be ready (UCAxTXIFG = 1) from 19-7 and more of manual*/
> #define halSPITXDONE (!(UCA0STAT&UCBUSY)) /* Wait for TX to finish, UCBUSY = 0 when idle */
> #define halSPIRXREADY (!(IFG1&UCA0RXIFG)) /* Wait for TX to be ready */
>
> HOWEVER, UCA0TXIFG is always 0. It never resets to 1, even as I send data out. So..
>
> in mmcInit() it proceeds all the way to the bottom:
> ----------
> CS_HIGH();
> for(i=0;i<=9;i++)
> spiSendByte(DUMMY_CHAR);
>
> return (mmcGoIdle());
> }
> ------
>
> and in mmcGoIdle:
> --------
> char mmcGoIdle()
> {
> char response=0x01;
> CS_LOW();
>
> //Send Command 0 to put MMC in SPI mode
> mmcSendCmd(MMC_GO_IDLE_STATE,0,0x95);
> //Now wait for READY RESPONSE
> if(mmcGetResponse()!=0x01)
> return MMC_INIT_ERROR;
> ----------
>
> mmcGetResponse always returns 0 because RX buffer is always 0.
>
> mmcGetResponse is follows:
> char mmcGetResponse(void)
> {
> //Response comes 1-8bytes after command
> //the first bit will be a 0
> //followed by an error code
> //data will be 0xff until response
> int i=0;
>
> char response;
>
> while(i > {
> response=spiSendByte(DUMMY_CHAR);
> if(response==0x00)break;
> if(response==0x01)break;
> i++;
> }
> return response;
> }
>
> and I have modified spiSendByte given what I said about the TX buffer IFG:
> unsigned char spiSendByte(const unsigned char data)
> {
> //while (halSPITXREADY == 0); // wait while not ready for TX
> halSPI_SEND(data); // write
> while (halSPIRXREADY == 0); // wait for RX buffer (full)
> return (halSPIRXBUF);
> }
>
> What I can't figure out is why the heck the SD card isn't talking back AND why the TX IFG flag is never set to zero. I crossed the register configuration with the FG4618 manual and it looks just fine.
>
> Are there any ideas? I am so sorry for posting question after question. I can assure you I am working on this on my own time and bang my head against the wall MANY times before posting in here.
>
Reply by Microbit_Ubuntu May 27, 20102010-05-27
Sounds like you're at a stage where lowest level needs to be questioned.
Probe w/ CRO on the clk and miso/mosi lines while repeatedly banging a
familiar byte, iow bit pattern.
Check your clk/phase is correct.

FWIW, I'd be paranoid about simply adding constants (unless I know I can
trust 'em).
To be on the safe side, use | instead of + ::

> UCA0CTL0 = UCMST+UCCKPL+UCMSB+UCSYNC; // 3-pin, 8-bit SPI master
> UCA0CTL1 = UCSSEL_2 + UCSWRST; // SMCLK

UCA0CTL0 = UCMST|UCCKPL|UCMSB|UCSYNC; // 3-pin, 8-bit SPI master
UCA0CTL1 = UCSSEL_2 | UCSWRST; // SMCLK

Normally these vendor headers are checked well. But if there's
overlapping bits, you would end up with nasty carry effects on bits when
you use '+' to build constants.

Just my $0.02...

HTH
Kris
On Thu, 2010-05-27 at 23:53 +0000, mastarre wrote:
> Okay, this is beginning to get beyond frustrating and I am starting to feel inept after a full year of getting projects done quickly and confidently on this uC.
>
> I still cannot get it to proceed past mmcInit(); because the SD card just will not respond back.
>
> The hardware and pins are configured the same as my original post shows.
>
> The USCI register is configured as follows:
> void halSPISetup(void)
> {
> UCA0CTL0 = UCMST+UCCKPL+UCMSB+UCSYNC; // 3-pin, 8-bit SPI master
> UCA0CTL1 = UCSSEL_2 + UCSWRST; // SMCLK
> UCA0BR0 |= 0x02; // UCLK/2
> UCA0BR1 = 0;
> UCA0MCTL = 0;
> UCA0CTL1 &= ~UCSWRST; // **Initialize USCI state machine**
> }
>
> And I have the following:
> #define halSPITXREADY (IFG1&UCA0TXIFG) /* Wait for TX to be ready (UCAxTXIFG = 1) from 19-7 and more of manual*/
> #define halSPITXDONE (!(UCA0STAT&UCBUSY)) /* Wait for TX to finish, UCBUSY = 0 when idle */
> #define halSPIRXREADY (!(IFG1&UCA0RXIFG)) /* Wait for TX to be ready */
>
> HOWEVER, UCA0TXIFG is always 0. It never resets to 1, even as I send data out. So..
>
> in mmcInit() it proceeds all the way to the bottom:
> ----------
> CS_HIGH();
> for(i=0;i<=9;i++)
> spiSendByte(DUMMY_CHAR);
>
> return (mmcGoIdle());
> }
> ------
>
> and in mmcGoIdle:
> --------
> char mmcGoIdle()
> {
> char response=0x01;
> CS_LOW();
>
> //Send Command 0 to put MMC in SPI mode
> mmcSendCmd(MMC_GO_IDLE_STATE,0,0x95);
> //Now wait for READY RESPONSE
> if(mmcGetResponse()!=0x01)
> return MMC_INIT_ERROR;
> ----------
>
> mmcGetResponse always returns 0 because RX buffer is always 0.
>
> mmcGetResponse is follows:
> char mmcGetResponse(void)
> {
> //Response comes 1-8bytes after command
> //the first bit will be a 0
> //followed by an error code
> //data will be 0xff until response
> int i=0;
>
> char response;
>
> while(i > {
> response=spiSendByte(DUMMY_CHAR);
> if(response==0x00)break;
> if(response==0x01)break;
> i++;
> }
> return response;
> }
>
> and I have modified spiSendByte given what I said about the TX buffer IFG:
> unsigned char spiSendByte(const unsigned char data)
> {
> //while (halSPITXREADY == 0); // wait while not ready for TX
> halSPI_SEND(data); // write
> while (halSPIRXREADY == 0); // wait for RX buffer (full)
> return (halSPIRXBUF);
> }
>
> What I can't figure out is why the heck the SD card isn't talking back AND why the TX IFG flag is never set to zero. I crossed the register configuration with the FG4618 manual and it looks just fine.
>
> Are there any ideas? I am so sorry for posting question after question. I can assure you I am working on this on my own time and bang my head against the wall MANY times before posting in here.
>
Reply by mastarre May 27, 20102010-05-27
Okay, this is beginning to get beyond frustrating and I am starting to feel inept after a full year of getting projects done quickly and confidently on this uC.

I still cannot get it to proceed past mmcInit(); because the SD card just will not respond back.

The hardware and pins are configured the same as my original post shows.

The USCI register is configured as follows:
void halSPISetup(void)
{
UCA0CTL0 = UCMST+UCCKPL+UCMSB+UCSYNC; // 3-pin, 8-bit SPI master
UCA0CTL1 = UCSSEL_2 + UCSWRST; // SMCLK
UCA0BR0 |= 0x02; // UCLK/2
UCA0BR1 = 0;
UCA0MCTL = 0;
UCA0CTL1 &= ~UCSWRST; // **Initialize USCI state machine**
}

And I have the following:
#define halSPITXREADY (IFG1&UCA0TXIFG) /* Wait for TX to be ready (UCAxTXIFG = 1) from 19-7 and more of manual*/
#define halSPITXDONE (!(UCA0STAT&UCBUSY)) /* Wait for TX to finish, UCBUSY = 0 when idle */
#define halSPIRXREADY (!(IFG1&UCA0RXIFG)) /* Wait for TX to be ready */

HOWEVER, UCA0TXIFG is always 0. It never resets to 1, even as I send data out. So..

in mmcInit() it proceeds all the way to the bottom:
----------
CS_HIGH();
for(i=0;i<=9;i++)
spiSendByte(DUMMY_CHAR);

return (mmcGoIdle());
}
------

and in mmcGoIdle:
--------
char mmcGoIdle()
{
char response=0x01;
CS_LOW();

//Send Command 0 to put MMC in SPI mode
mmcSendCmd(MMC_GO_IDLE_STATE,0,0x95);
//Now wait for READY RESPONSE
if(mmcGetResponse()!=0x01)
return MMC_INIT_ERROR;
----------

mmcGetResponse always returns 0 because RX buffer is always 0.

mmcGetResponse is follows:
char mmcGetResponse(void)
{
//Response comes 1-8bytes after command
//the first bit will be a 0
//followed by an error code
//data will be 0xff until response
int i=0;

char response;

while(i {
response=spiSendByte(DUMMY_CHAR);
if(response==0x00)break;
if(response==0x01)break;
i++;
}
return response;
}

and I have modified spiSendByte given what I said about the TX buffer IFG:
unsigned char spiSendByte(const unsigned char data)
{
//while (halSPITXREADY == 0); // wait while not ready for TX
halSPI_SEND(data); // write
while (halSPIRXREADY == 0); // wait for RX buffer (full)
return (halSPIRXBUF);
}

What I can't figure out is why the heck the SD card isn't talking back AND why the TX IFG flag is never set to zero. I crossed the register configuration with the FG4618 manual and it looks just fine.

Are there any ideas? I am so sorry for posting question after question. I can assure you I am working on this on my own time and bang my head against the wall MANY times before posting in here.

Reply by "Hayashi, Steve" May 27, 20102010-05-27
The original code was written for the 1xx series processors (the #include header should have given that away), so it's probably better to comment out any unusual line from the original and look up in the family guide on what it does. It's slau049f.pdf, IIRC.

Granted, It's a lot more work, but you will understand better what they're trying to do.

-Steve

From: m... [mailto:m...] On Behalf Of mastarre
Sent: Thursday, May 27, 2010 3:47 PM
To: m...
Subject: [msp430] Re: Having trouble with SPI for SD Card

Ohh! Okay. Jeez!

Is there some way I could have figured that out more quickly on my own? I really appreciate your help but its a bit embarrassing really to have to post so many follow ups :)

--- In m..., "Hayashi, Steve" wrote:
>
> The original flag was U0TCTL & TXEPT.
> Translated into English, it will return 0 if the TX buffer is NOT empty.
>
> USCI changed that functionality to busy, so that the closest equivalent function returns 0 if the USCI IS empty.
>
> -Steve
>
> From: m... [mailto:m...] On Behalf Of mastarre
> Sent: Thursday, May 27, 2010 1:22 PM
> To: m...
> Subject: [msp430] Re: Having trouble with SPI for SD Card
>
> Steve,
>
> I agree. The example is, in my opinion, WAY overly abstracted. I was planning to reduce it when I got something functional going but didn't want to before hand because it is a TI example and *should* work as written.
>
> I see what you are saying but what I can't figure out is why it was written that way in the first place. That is why I feel like I might have read it somewhere in the past but am not able to think of it now, etc. Remember, this is working directly with a TI example so they wrote it to have that behavior. I am not saying that I am taking that for what it is and not trying to understand it - I am trying very hard to figure out why they did that - but I am having some trouble understanding the behavior that they expect to justify that and, thus, why my device is not behaving that way.
>
> --- In m..., "Hayashi, Steve" wrote:
> >
> > You're suffering from too many macros IMHO, and it hides the obvious problem.
> >
> > You have CS_HIGH defined (effectively) as:
> > While (!(UCA0STAT&UCBUSY));
> >
> > So you're looping while USCI A0 is not busy.
> >
> > -Steve
> >
> > From: m... [mailto:m...] On Behalf Of mastarre
> > Sent: Thursday, May 27, 2010 12:12 PM
> > To: m...
> > Subject: [msp430] Re: Having trouble with SPI for SD Card
> >
> >
> >
> > Ah okay, that makes sense. I was wondering about that but didn't have the history to know!
> >
> > I have since made the change and it now compiles fine and runs. However, when running it gets to the initialization:
> > mmcInit()
> >
> > Which calls:
> > CS_HIGH()
> >
> > Which is:
> > #define CS_HIGH() while(!halSPITXDONE); MMC_CS_PxOUT |= MMC_CS
> >
> > Which is:
> > #define halSPITXDONE (UCA0STAT&UCBUSY) /* Wait for TX to finish */
> >
> > However, as I watch the registers in IAR in debug mode,
> > UCA0STAT___SPI = 0x00
> >
> > Thus:
> > UCBUSY = 0
> >
> > However, it will not proceed past CS_HIGH, it just continues to loop there.
> >
> > At this point I feel like I have done so much searching and reading that I am spinning a little bit. This might be simple but I can't get the clarity I need to figure it out.
> >
> > Does anyone have a suggestion?
> >
> > And may I also say that the help here is just tremendous. I really appreciate it.
> >
> >
> >
> >
> >
>



Reply by mastarre May 27, 20102010-05-27
Ohh! Okay. Jeez!

Is there some way I could have figured that out more quickly on my own? I really appreciate your help but its a bit embarrassing really to have to post so many follow ups :)

--- In m..., "Hayashi, Steve" wrote:
>
> The original flag was U0TCTL & TXEPT.
> Translated into English, it will return 0 if the TX buffer is NOT empty.
>
> USCI changed that functionality to busy, so that the closest equivalent function returns 0 if the USCI IS empty.
>
> -Steve
>
> From: m... [mailto:m...] On Behalf Of mastarre
> Sent: Thursday, May 27, 2010 1:22 PM
> To: m...
> Subject: [msp430] Re: Having trouble with SPI for SD Card
>
> Steve,
>
> I agree. The example is, in my opinion, WAY overly abstracted. I was planning to reduce it when I got something functional going but didn't want to before hand because it is a TI example and *should* work as written.
>
> I see what you are saying but what I can't figure out is why it was written that way in the first place. That is why I feel like I might have read it somewhere in the past but am not able to think of it now, etc. Remember, this is working directly with a TI example so they wrote it to have that behavior. I am not saying that I am taking that for what it is and not trying to understand it - I am trying very hard to figure out why they did that - but I am having some trouble understanding the behavior that they expect to justify that and, thus, why my device is not behaving that way.
>
> --- In m..., "Hayashi, Steve" wrote:
> >
> > You're suffering from too many macros IMHO, and it hides the obvious problem.
> >
> > You have CS_HIGH defined (effectively) as:
> > While (!(UCA0STAT&UCBUSY));
> >
> > So you're looping while USCI A0 is not busy.
> >
> > -Steve
> >
> > From: m... [mailto:m...] On Behalf Of mastarre
> > Sent: Thursday, May 27, 2010 12:12 PM
> > To: m...
> > Subject: [msp430] Re: Having trouble with SPI for SD Card
> >
> >
> >
> > Ah okay, that makes sense. I was wondering about that but didn't have the history to know!
> >
> > I have since made the change and it now compiles fine and runs. However, when running it gets to the initialization:
> > mmcInit()
> >
> > Which calls:
> > CS_HIGH()
> >
> > Which is:
> > #define CS_HIGH() while(!halSPITXDONE); MMC_CS_PxOUT |= MMC_CS
> >
> > Which is:
> > #define halSPITXDONE (UCA0STAT&UCBUSY) /* Wait for TX to finish */
> >
> > However, as I watch the registers in IAR in debug mode,
> > UCA0STAT___SPI = 0x00
> >
> > Thus:
> > UCBUSY = 0
> >
> > However, it will not proceed past CS_HIGH, it just continues to loop there.
> >
> > At this point I feel like I have done so much searching and reading that I am spinning a little bit. This might be simple but I can't get the clarity I need to figure it out.
> >
> > Does anyone have a suggestion?
> >
> > And may I also say that the help here is just tremendous. I really appreciate it.
> >
> >
> >
> >
> >
>