I am working to communicate with an ATMEL AT45DB081B dataflash in
SPI Mode with a MSP430-149. The opcode sent to the flash should make
it do a continuous read so I should continuously be receiving data
but instead I receive a few bytes and then it stops. The flash needs
SPI Mode 0 or 3 and needs a high to low transition on pin 3.0 before
a opcode is sent. I believe I have the initializations right but I
need some help debugging. I have an 8Mhz crystal on installed on the
XT2CLK. Any problems found, advice, or anything would be of help as
I need to get this going.
void main(void)
{
unsigned int dco_cnt;
BCSCTL1 &= ~XT2OFF; // XT2on
do // wait for MCLK from quartz
{
IFG1 &= ~OFIFG; // Clear OSCFault flag
for (dco_cnt = 0xff; dco_cnt > 0; dco_cnt--); //
Time for flag to set
}
while ((IFG1 & OFIFG) != 0); // OSCFault flag still set?
WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer
BCSCTL1 = 0x07; // LFXT1: XT2on: LF quartz for MCLK
P3SEL |= 0x0E; // P5.1-3 SPI option select
P3DIR |= 0x01; // P5.0 output direction
P3OUT = 0xff;
ME1 |= USPIE0; // Enable USART1 SPI mode
UTCTL0 = CKPH | SSEL1 | SSEL0 | STC; // SMCLK, 3-pin
mode, clock idle low, data valid on rising edge, UCLK delayed
UBR00 = 0x02; // 0x02: UCLK/2 (4 MHz),
works also with 3 and 4
UBR10 = 0x00; // -"-
UMCTL0 = 0x00; // no modulation
UCTL0 = CHAR | SYNC | MM; // 8-bit SPI Master **SWRST**
IE1 |= URXIE0;
_EINT();
P1DIR |= 0x01;
continuous_Read(S1_B1,S1_B2,S1_B3);
for(;;)
{
}
}
#pragma vector=USART0RX_VECTOR
__interrupt void SPI0_RX (void)
{
P1OUT ^= 0x01; //Toggle light to show data is received
{
unsigned int y;
y = 50000; // Delay
do (y--);
while (y != 0);
y = 50000; // Delay
do (y--);
while (y != 0);
}
}
void continuous_Read(int Byte1, int Byte2, int Byte3)
{
CS_LOW();
//P3OUT ^= 0x01; //Reset Memory to
assure proper timing
i = 50000; // Delay
do (i--);
while (i != 0);
//Flash needs opcode +24 bits of start address + 32
don't care bits
U0TXBUF = 0xE8; //opcode for
continous array read
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = Byte1; //First Byte of 24-
bit address sequence
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = Byte2; //Second Byte
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = Byte3; //Third Byte
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = 0xFF; //First byte of 32-
don't care bits
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = 0xFF; //Second Byte
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = 0xFF; //Third Byte
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = 0xFF; //Final Byte
}
SPI Problems
Started by ●March 25, 2005
Reply by ●March 25, 20052005-03-25
Since the Atmel dataflash is a SPI slave device, it doesn't put any
information out on the SPI bus unless you clock it. Just stuff U0TXBUF with a
value like 0x00 (or some other arbitrary value) for every time you want to read
a byte.
HTH,
Matt Sabino
Computer Engineer
Airtronic Services, Inc.
----- Original Message -----
From: bigdog16_83
To: msp430@msp4...
Sent: Friday, March 25, 2005 11:58 AM
Subject: [msp430] SPI Problems
I am working to communicate with an ATMEL AT45DB081B dataflash in
SPI Mode with a MSP430-149. The opcode sent to the flash should make
it do a continuous read so I should continuously be receiving data
but instead I receive a few bytes and then it stops. The flash needs
SPI Mode 0 or 3 and needs a high to low transition on pin 3.0 before
a opcode is sent. I believe I have the initializations right but I
need some help debugging. I have an 8Mhz crystal on installed on the
XT2CLK. Any problems found, advice, or anything would be of help as
I need to get this going.
void main(void)
{
unsigned int dco_cnt;
BCSCTL1 &= ~XT2OFF; // XT2on
do // wait for MCLK from quartz
{
IFG1 &= ~OFIFG; // Clear OSCFault flag
for (dco_cnt = 0xff; dco_cnt > 0; dco_cnt--); //
Time for flag to set
}
while ((IFG1 & OFIFG) != 0); // OSCFault flag still set?
WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer
BCSCTL1 = 0x07; // LFXT1: XT2on: LF quartz for MCLK
P3SEL |= 0x0E; // P5.1-3 SPI option select
P3DIR |= 0x01; // P5.0 output direction
P3OUT = 0xff;
ME1 |= USPIE0; // Enable USART1 SPI mode
UTCTL0 = CKPH | SSEL1 | SSEL0 | STC; // SMCLK, 3-pin
mode, clock idle low, data valid on rising edge, UCLK delayed
UBR00 = 0x02; // 0x02: UCLK/2 (4 MHz),
works also with 3 and 4
UBR10 = 0x00; // -"-
UMCTL0 = 0x00; // no modulation
UCTL0 = CHAR | SYNC | MM; // 8-bit SPI Master **SWRST**
IE1 |= URXIE0;
_EINT();
P1DIR |= 0x01;
continuous_Read(S1_B1,S1_B2,S1_B3);
for(;;)
{
}
}
#pragma vector=USART0RX_VECTOR
__interrupt void SPI0_RX (void)
{
P1OUT ^= 0x01; //Toggle light to show data is received
{
unsigned int y;
y = 50000; // Delay
do (y--);
while (y != 0);
y = 50000; // Delay
do (y--);
while (y != 0);
}
}
void continuous_Read(int Byte1, int Byte2, int Byte3)
{
CS_LOW();
//P3OUT ^= 0x01; //Reset Memory to
assure proper timing
i = 50000; // Delay
do (i--);
while (i != 0);
//Flash needs opcode +24 bits of start address + 32
don't care bits
U0TXBUF = 0xE8; //opcode for
continous array read
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = Byte1; //First Byte of 24-
bit address sequence
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = Byte2; //Second Byte
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = Byte3; //Third Byte
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = 0xFF; //First byte of 32-
don't care bits
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = 0xFF; //Second Byte
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = 0xFF; //Third Byte
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = 0xFF; //Final Byte
}
.
------
.
------
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.2 - Release Date: 3/25/2005
----------
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.2 - Release Date: 3/25/2005
Reply by ●March 26, 20052005-03-26
Does this not defeat the whole advantage of the SPI? I thought the SPI had its own clock line which transfer and receive data was attached to each of the edges? This also defeats my purpose. I'm using this to have the flash (storing a .wav file) send the file back to the MSP which will direct it out to an external DAC. If I am misunderstanding the SPI please explain more. --- In msp430@msp4..., "Matt Sabino" <msabino@a...> wrote: > Since the Atmel dataflash is a SPI slave device, it doesn't put any information out on the SPI bus unless you clock it. Just stuff U0TXBUF with a value like 0x00 (or some other arbitrary value) for every time you want to read a byte. > > HTH, > > > Matt Sabino > Computer Engineer > Airtronic Services, Inc. > > ----- Original Message ----- > From: bigdog16_83 > To: msp430@msp4... > Sent: Friday, March 25, 2005 11:58 AM > Subject: [msp430] SPI Problems > > > > I am working to communicate with an ATMEL AT45DB081B dataflash in > SPI Mode with a MSP430-149. The opcode sent to the flash should make > it do a continuous read so I should continuously be receiving data > but instead I receive a few bytes and then it stops. The flash needs > SPI Mode 0 or 3 and needs a high to low transition on pin 3.0 before > a opcode is sent. I believe I have the initializations right but I > need some help debugging. I have an 8Mhz crystal on installed on the > XT2CLK. Any problems found, advice, or anything would be of help as > I need to get this going. > > void main(void) > { > unsigned int dco_cnt; > BCSCTL1 &= ~XT2OFF; // XT2on > do // wait for MCLK from quartz > { > IFG1 &= ~OFIFG; // Clear OSCFault flag > for (dco_cnt = 0xff; dco_cnt > 0; dco_cnt-- ); // > Time for flag to set > } > while ((IFG1 & OFIFG) != 0); // OSCFault flag still set? > > WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer > > BCSCTL1 = 0x07; // LFXT1: XT2on: LF quartz for MCLK > > P3SEL |= 0x0E; // P5.1-3 SPI option select > P3DIR |= 0x01; // P5.0 output direction > P3OUT = 0xff; > ME1 |= USPIE0; // Enable USART1 SPI mode > UTCTL0 = CKPH | SSEL1 | SSEL0 | STC; // SMCLK, 3- pin > mode, clock idle low, data valid on rising edge, UCLK delayed > UBR00 = 0x02; // 0x02: UCLK/2 (4 MHz), > works also with 3 and 4 > UBR10 = 0x00; // -"- > UMCTL0 = 0x00; // no modulation > UCTL0 = CHAR | SYNC | MM; // 8-bit SPI Master **SWRST** > IE1 |= URXIE0; > _EINT(); > > P1DIR |= 0x01; > > continuous_Read(S1_B1,S1_B2,S1_B3); > > for(;;) > { > } > } > > #pragma vector=USART0RX_VECTOR > __interrupt void SPI0_RX (void) > { > > P1OUT ^= 0x01; //Toggle light to show data is received > { > unsigned int y; > y = 50000; // Delay > do (y--); > while (y != 0); > y = 50000; // Delay > do (y--); > while (y != 0); > } > > > } > void continuous_Read(int Byte1, int Byte2, int Byte3) > { > CS_LOW(); > //P3OUT ^= 0x01; //Reset Memory to > assure proper timing > i = 50000; // Delay > do (i--); > while (i != 0); > > //Flash needs opcode +24 bits of start address + 32 > don't care bits > U0TXBUF = 0xE8; //opcode for > continous array read > while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer > ready? > U0TXBUF = Byte1; //First Byte of 24- > bit address sequence > while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer > ready? > U0TXBUF = Byte2; //Second Byte > while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer > ready? > U0TXBUF = Byte3; //Third Byte > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer > ready? > U0TXBUF = 0xFF; //First byte of 32- > don't care bits > while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer > ready? > U0TXBUF = 0xFF; //Second Byte > while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer > ready? > U0TXBUF = 0xFF; //Third Byte > while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer > ready? > U0TXBUF = 0xFF; //Final Byte > } > > > > > > . > > > > > > > > > > > ------------------------------- ----------- > Yahoo! Groups Links > > a.. To visit your group on the web, go to: > http://groups.yahoo.com/group/msp430/ > > b.. . > > c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > > > > ------------------------------- ----------- > > > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.8.2 - Release Date: 3/25/2005 > > ---------- > > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.8.2 - Release Date: 3/25/2005 > > >
Reply by ●March 26, 20052005-03-26
"...I thought the SPI had its own clock line ..." Nope. There is a master and slave(s). The master provides the clock whenever it wants something to happen on the SPI. Lee --- In msp430@msp4..., "bigdog16_83" <bigdog16_83@y...> wrote: > > Does this not defeat the whole advantage of the SPI? I thought the > SPI had its own clock line which transfer and receive data was > attached to each of the edges? This also defeats my purpose. I'm > using this to have the flash (storing a .wav file) send the file > back to the MSP which will direct it out to an external DAC. If I am > misunderstanding the SPI please explain more. > > --- In msp430@msp4..., "Matt Sabino" <msabino@a...> wrote: > > Since the Atmel dataflash is a SPI slave device, it doesn't put > any information out on the SPI bus unless you clock it. Just stuff > U0TXBUF with a value like 0x00 (or some other arbitrary value) for > every time you want to read a byte. > > > > HTH, > > > > > > Matt Sabino > > Computer Engineer > > Airtronic Services, Inc. > > > > ----- Original Message ----- > > From: bigdog16_83 > > To: msp430@msp4... > > Sent: Friday, March 25, 2005 11:58 AM > > Subject: [msp430] SPI Problems > > > > > > > > I am working to communicate with an ATMEL AT45DB081B dataflash > in > > SPI Mode with a MSP430-149. The opcode sent to the flash should > make > > it do a continuous read so I should continuously be receiving > data > > but instead I receive a few bytes and then it stops. The flash > needs > > SPI Mode 0 or 3 and needs a high to low transition on pin 3.0 > before > > a opcode is sent. I believe I have the initializations right but > I > > need some help debugging. I have an 8Mhz crystal on installed on > the > > XT2CLK. Any problems found, advice, or anything would be of help > as > > I need to get this going. > > > > void main(void) > > { > > unsigned int dco_cnt; > > BCSCTL1 &= ~XT2OFF; // XT2on > > do // wait for MCLK from quartz > > { > > IFG1 &= ~OFIFG; // Clear OSCFault flag > > for (dco_cnt = 0xff; dco_cnt > 0; dco_cnt-- > ); // > > Time for flag to set > > } > > while ((IFG1 & OFIFG) != 0); // OSCFault flag still > set? > > > > WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer > > > > BCSCTL1 = 0x07; // LFXT1: XT2on: LF quartz for > MCLK > > > > P3SEL |= 0x0E; // P5.1-3 SPI option select > > P3DIR |= 0x01; // P5.0 output direction > > P3OUT = 0xff; > > ME1 |= USPIE0; // Enable USART1 SPI mode > > UTCTL0 = CKPH | SSEL1 | SSEL0 | STC; // SMCLK, 3- > pin > > mode, clock idle low, data valid on rising edge, UCLK delayed > > UBR00 = 0x02; // 0x02: UCLK/2 (4 MHz), > > works also with 3 and 4 > > UBR10 = 0x00; // -"- > > UMCTL0 = 0x00; // no modulation > > UCTL0 = CHAR | SYNC | MM; // 8-bit SPI Master > **SWRST** > > IE1 |= URXIE0; > > _EINT(); > > > > P1DIR |= 0x01; > > > > continuous_Read(S1_B1,S1_B2,S1_B3); > > > > for(;;) > > { > > } > > } > > > > #pragma vector=USART0RX_VECTOR > > __interrupt void SPI0_RX (void) > > { > > > > P1OUT ^= 0x01; //Toggle light to show data is > received > > { > > unsigned int y; > > y = 50000; // Delay > > do (y--); > > while (y != 0); > > y = 50000; // Delay > > do (y--); > > while (y != 0); > > } > > > > > > } > > void continuous_Read(int Byte1, int Byte2, int Byte3) > > { > > CS_LOW(); > > //P3OUT ^= 0x01; //Reset Memory to > > assure proper timing > > i = 50000; // Delay > > do (i--); > > while (i != 0); > > > > //Flash needs opcode +24 bits of start address + > 32 > > don't care bits > > U0TXBUF = 0xE8; //opcode for > > continous array read > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer > > ready? > > U0TXBUF = Byte1; //First Byte of > 24- > > bit address sequence > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer > > ready? > > U0TXBUF = Byte2; //Second Byte > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer > > ready? > > U0TXBUF = Byte3; //Third Byte > > > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer > > ready? > > U0TXBUF = 0xFF; //First byte of 32- > > don't care bits > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer > > ready? > > U0TXBUF = 0xFF; //Second Byte > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer > > ready? > > U0TXBUF = 0xFF; //Third Byte > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer > > ready? > > U0TXBUF = 0xFF; //Final Byte > > } > > > > > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > ------------------------------ - > ----------- > > Yahoo! Groups Links > > > > a.. To visit your group on the web, go to: > > http://groups.yahoo.com/group/msp430/ > > > > b.. . > > > > c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms > of Service. > > > > > > > > > > ------------------------------ - > ----------- > > > > > > No virus found in this incoming message. > > Checked by AVG Anti-Virus. > > Version: 7.0.308 / Virus Database: 266.8.2 - Release Date: > 3/25/2005 > > > > ---------- > > > > No virus found in this outgoing message. > > Checked by AVG Anti-Virus. > > Version: 7.0.308 / Virus Database: 266.8.2 - Release Date: > 3/25/2005 > > > > > >
Reply by ●March 26, 20052005-03-26
<top post>
Sounds to me like you both are right, the SPI does have it's own clock
line.
This clock 'line' or wire, has a signal that is generated by the
master SPI
interface.
In this case, this would be the MSP, the Atmel, being the slave device is
connected to the clock signal line. When the MSP wants to read data from the
Atmel, it needs to place some value in the master TX register. This will
trigger clock pulses on the clock line, which the Atmel will see and send out
data to be stored in the MSP RX register.
Now, not being familiar with the Atmel, I assume there's some method for
the
MSP to determine when there's data to be read. But that's another
issue.
-Micah
On Saturday 26 March 2005 07:00 am, budfrog99 wrote:
> "...I thought the SPI had its own clock line ..."
>
> Nope. There is a master and slave(s). The master provides the clock
> whenever it wants something to happen on the SPI.
>
> Lee
>
> --- In msp430@msp4..., "bigdog16_83" <bigdog16_83@y...>
wrote:
> > Does this not defeat the whole advantage of the SPI? I thought the
> > SPI had its own clock line which transfer and receive data was
> > attached to each of the edges? This also defeats my purpose. I'm
> > using this to have the flash (storing a .wav file) send the file
> > back to the MSP which will direct it out to an external DAC. If I
>
> am
>
> > misunderstanding the SPI please explain more.
> >
> > --- In msp430@msp4..., "Matt Sabino" <msabino@a...>
wrote:
> > > Since the Atmel dataflash is a SPI slave device, it doesn't
put
> >
> > any information out on the SPI bus unless you clock it. Just stuff
> > U0TXBUF with a value like 0x00 (or some other arbitrary value) for
> > every time you want to read a byte.
> >
> > > HTH,
> > >
> > >
> > > Matt Sabino
> > > Computer Engineer
> > > Airtronic Services, Inc.
> > >
> > > ----- Original Message -----
> > > From: bigdog16_83
> > > To: msp430@msp4...
> > > Sent: Friday, March 25, 2005 11:58 AM
> > > Subject: [msp430] SPI Problems
> > >
> > >
> > >
> > > I am working to communicate with an ATMEL AT45DB081B dataflash
> >
> > in
> >
> > > SPI Mode with a MSP430-149. The opcode sent to the flash
should
> >
> > make
> >
> > > it do a continuous read so I should continuously be receiving
> >
> > data
> >
> > > but instead I receive a few bytes and then it stops. The flash
> >
> > needs
> >
> > > SPI Mode 0 or 3 and needs a high to low transition on pin 3.0
> >
> > before
> >
> > > a opcode is sent. I believe I have the initializations right
>
> but
>
> > I
> >
> > > need some help debugging. I have an 8Mhz crystal on installed
>
> on
>
> > the
> >
> > > XT2CLK. Any problems found, advice, or anything would be of
>
> help
>
> > as
> >
> > > I need to get this going.
> > >
> > > void main(void)
> > > {
> > > unsigned int dco_cnt;
> > > BCSCTL1 &= ~XT2OFF; // XT2on
> > > do // wait for MCLK from quartz
> > > {
> > > IFG1 &= ~OFIFG; // Clear OSCFault
flag
> > > for (dco_cnt = 0xff; dco_cnt > 0; dco_cnt--
> >
> > ); //
> >
> > > Time for flag to set
> > > }
> > > while ((IFG1 & OFIFG) != 0); // OSCFault flag
>
> still
>
> > set?
> >
> > > WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer
> > >
> > > BCSCTL1 = 0x07; // LFXT1: XT2on: LF quartz
for
> >
> > MCLK
> >
> > > P3SEL |= 0x0E; // P5.1-3 SPI option select
> > > P3DIR |= 0x01; // P5.0 output direction
> > > P3OUT = 0xff;
> > > ME1 |= USPIE0; // Enable USART1 SPI mode
> > > UTCTL0 = CKPH | SSEL1 | SSEL0 | STC; // SMCLK, 3-
> >
> > pin
> >
> > > mode, clock idle low, data valid on rising edge, UCLK delayed
> > > UBR00 = 0x02; // 0x02: UCLK/2 (4
MHz),
> > > works also with 3 and 4
> > > UBR10 = 0x00; // -"-
> > > UMCTL0 = 0x00; // no modulation
> > > UCTL0 = CHAR | SYNC | MM; // 8-bit SPI Master
> >
> > **SWRST**
> >
> > > IE1 |= URXIE0;
> > > _EINT();
> > >
> > > P1DIR |= 0x01;
> > >
> > > continuous_Read(S1_B1,S1_B2,S1_B3);
> > >
> > > for(;;)
> > > {
> > > }
> > > }
> > >
> > > #pragma vector=USART0RX_VECTOR
> > > __interrupt void SPI0_RX (void)
> > > {
> > >
> > > P1OUT ^= 0x01; //Toggle light to show data is
> >
> > received
> >
> > > {
> > > unsigned int y;
> > > y = 50000; // Delay
> > > do (y--);
> > > while (y != 0);
> > > y = 50000; // Delay
> > > do (y--);
> > > while (y != 0);
> > > }
> > >
> > >
> > > }
> > > void continuous_Read(int Byte1, int Byte2, int Byte3)
> > > {
> > > CS_LOW();
> > > //P3OUT ^= 0x01; //Reset Memory
to
> > > assure proper timing
> > > i = 50000; // Delay
> > > do (i--);
> > > while (i != 0);
> > >
> > > //Flash needs opcode +24 bits of start
address
>
> +
>
> > 32
> >
> > > don't care bits
> > > U0TXBUF = 0xE8; //opcode for
> > > continous array read
> > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
>
> buffer
>
> > > ready?
> > > U0TXBUF = Byte1; //First Byte of
> >
> > 24-
> >
> > > bit address sequence
> > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
>
> buffer
>
> > > ready?
> > > U0TXBUF = Byte2; //Second Byte
> > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
>
> buffer
>
> > > ready?
> > > U0TXBUF = Byte3; //Third Byte
> > >
> > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
>
> buffer
>
> > > ready?
> > > U0TXBUF = 0xFF; //First byte of
>
> 32-
>
> > > don't care bits
> > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
>
> buffer
>
> > > ready?
> > > U0TXBUF = 0xFF; //Second Byte
> > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
>
> buffer
>
> > > ready?
> > > U0TXBUF = 0xFF; //Third Byte
> > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
>
> buffer
>
> > > ready?
> > > U0TXBUF = 0xFF; //Final Byte
> > > }
> > >
> > >
> > >
> > >
> > >
> > > .
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------
>
> -
>
> > -----------
> >
> > > .
Reply by ●March 28, 20052005-03-28
Interesting. So your saying for me to continously recieve data from the atmel, which i should be doing once I send it the continuous read command, that I have to keep something in the transfer buffer to keep that clock running? If I have a receive interrupt set, does this mean I need to put something in the transfer buffer every time that the interrupt is called? If this is so does this change the rate data is being sent to me? With this - if I am taking the data I receive and sending it out port 4 to an external DAC, can I use this same clock that I'm receiving on to run the DAC or will this cause other issues? --- In msp430@msp4..., Micah Stevens <micah@9...> wrote: > <top post> > Sounds to me like you both are right, the SPI does have it's own clock line. > This clock 'line' or wire, has a signal that is generated by the master SPI > interface. > > In this case, this would be the MSP, the Atmel, being the slave device is > connected to the clock signal line. When the MSP wants to read data from the > Atmel, it needs to place some value in the master TX register. This will > trigger clock pulses on the clock line, which the Atmel will see and send out > data to be stored in the MSP RX register. > > Now, not being familiar with the Atmel, I assume there's some method for the > MSP to determine when there's data to be read. But that's another issue. > > -Micah > > > On Saturday 26 March 2005 07:00 am, budfrog99 wrote: > > "...I thought the SPI had its own clock line ..." > > > > Nope. There is a master and slave(s). The master provides the clock > > whenever it wants something to happen on the SPI. > > > > Lee > > > > --- In msp430@msp4..., "bigdog16_83" <bigdog16_83@y...> wrote: > > > Does this not defeat the whole advantage of the SPI? I thought the > > > SPI had its own clock line which transfer and receive data was > > > attached to each of the edges? This also defeats my purpose. I'm > > > using this to have the flash (storing a .wav file) send the file > > > back to the MSP which will direct it out to an external DAC. If I > > > > am > > > > > misunderstanding the SPI please explain more. > > > > > > --- In msp430@msp4..., "Matt Sabino" <msabino@a...> wrote: > > > > Since the Atmel dataflash is a SPI slave device, it doesn't put > > > > > > any information out on the SPI bus unless you clock it. Just stuff > > > U0TXBUF with a value like 0x00 (or some other arbitrary value) for > > > every time you want to read a byte. > > > > > > > HTH, > > > > > > > > > > > > Matt Sabino > > > > Computer Engineer > > > > Airtronic Services, Inc. > > > > > > > > ----- Original Message ----- > > > > From: bigdog16_83 > > > > To: msp430@msp4... > > > > Sent: Friday, March 25, 2005 11:58 AM > > > > Subject: [msp430] SPI Problems > > > > > > > > > > > > > > > > I am working to communicate with an ATMEL AT45DB081B dataflash > > > > > > in > > > > > > > SPI Mode with a MSP430-149. The opcode sent to the flash should > > > > > > make > > > > > > > it do a continuous read so I should continuously be receiving > > > > > > data > > > > > > > but instead I receive a few bytes and then it stops. The flash > > > > > > needs > > > > > > > SPI Mode 0 or 3 and needs a high to low transition on pin 3.0 > > > > > > before > > > > > > > a opcode is sent. I believe I have the initializations right > > > > but > > > > > I > > > > > > > need some help debugging. I have an 8Mhz crystal on installed > > > > on > > > > > the > > > > > > > XT2CLK. Any problems found, advice, or anything would be of > > > > help > > > > > as > > > > > > > I need to get this going. > > > > > > > > void main(void) > > > > { > > > > unsigned int dco_cnt; > > > > BCSCTL1 &= ~XT2OFF; // XT2on > > > > do // wait for MCLK from quartz > > > > { > > > > IFG1 &= ~OFIFG; // Clear OSCFault flag > > > > for (dco_cnt = 0xff; dco_cnt > 0; dco_cnt-- > > > > > > ); // > > > > > > > Time for flag to set > > > > } > > > > while ((IFG1 & OFIFG) != 0); // OSCFault flag > > > > still > > > > > set? > > > > > > > WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer > > > > > > > > BCSCTL1 = 0x07; // LFXT1: XT2on: LF quartz for > > > > > > MCLK > > > > > > > P3SEL |= 0x0E; // P5.1-3 SPI option select > > > > P3DIR |= 0x01; // P5.0 output direction > > > > P3OUT = 0xff; > > > > ME1 |= USPIE0; // Enable USART1 SPI mode > > > > UTCTL0 = CKPH | SSEL1 | SSEL0 | STC; // SMCLK, 3- > > > > > > pin > > > > > > > mode, clock idle low, data valid on rising edge, UCLK delayed > > > > UBR00 = 0x02; // 0x02: UCLK/2 (4 MHz), > > > > works also with 3 and 4 > > > > UBR10 = 0x00; // -"- > > > > UMCTL0 = 0x00; // no modulation > > > > UCTL0 = CHAR | SYNC | MM; // 8-bit SPI Master > > > > > > **SWRST** > > > > > > > IE1 |= URXIE0; > > > > _EINT(); > > > > > > > > P1DIR |= 0x01; > > > > > > > > continuous_Read(S1_B1,S1_B2,S1_B3); > > > > > > > > for(;;) > > > > { > > > > } > > > > } > > > > > > > > #pragma vector=USART0RX_VECTOR > > > > __interrupt void SPI0_RX (void) > > > > { > > > > > > > > P1OUT ^= 0x01; //Toggle light to show data is > > > > > > received > > > > > > > { > > > > unsigned int y; > > > > y = 50000; // Delay > > > > do (y--); > > > > while (y != 0); > > > > y = 50000; // Delay > > > > do (y--); > > > > while (y != 0); > > > > } > > > > > > > > > > > > } > > > > void continuous_Read(int Byte1, int Byte2, int Byte3) > > > > { > > > > CS_LOW(); > > > > //P3OUT ^= 0x01; //Reset Memory to > > > > assure proper timing > > > > i = 50000; // Delay > > > > do (i--); > > > > while (i != 0); > > > > > > > > //Flash needs opcode +24 bits of start address > > > > + > > > > > 32 > > > > > > > don't care bits > > > > U0TXBUF = 0xE8; //opcode for > > > > continous array read > > > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX > > > > buffer > > > > > > ready? > > > > U0TXBUF = Byte1; //First Byte of > > > > > > 24- > > > > > > > bit address sequence > > > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX > > > > buffer > > > > > > ready? > > > > U0TXBUF = Byte2; //Second Byte > > > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX > > > > buffer > > > > > > ready? > > > > U0TXBUF = Byte3; //Third Byte > > > > > > > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX > > > > buffer > > > > > > ready? > > > > U0TXBUF = 0xFF; //First byte of > > > > 32- > > > > > > don't care bits > > > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX > > > > buffer > > > > > > ready? > > > > U0TXBUF = 0xFF; //Second Byte > > > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX > > > > buffer > > > > > > ready? > > > > U0TXBUF = 0xFF; //Third Byte > > > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX > > > > buffer > > > > > > ready? > > > > U0TXBUF = 0xFF; //Final Byte > > > > } > > > > > > > > > > > > > > > > > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------ ------ > > > > - > > > > > ----------- > > > > > > > Yahoo! Groups Links > > > > > > > > a.. To visit your group on the web, go to: > > > > http://groups.yahoo.com/group/msp430/ > > > > > > > > b.. . > > > > > > > > c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms > > > > > > of Service. > > > > > > > ------------------------ ------ > > > > - > > > > > ----------- > > > > > > > No virus found in this incoming message. > > > > Checked by AVG Anti-Virus. > > > > Version: 7.0.308 / Virus Database: 266.8.2 - Release Date: > > > > > > 3/25/2005 > > > > > > > ---------- > > > > > > > > No virus found in this outgoing message. > > > > Checked by AVG Anti-Virus. > > > > Version: 7.0.308 / Virus Database: 266.8.2 - Release Date: > > > > > > 3/25/2005 > > > > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > To visit your group on the web, go to: > > http://groups.yahoo.com/group/msp430/ > > > > . > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Reply by ●March 28, 20052005-03-28
Yes, once you recieve a byte, the interrupt will be called, then you need to
get the byte from the buffer, then send another byte to the TX buffer to kick
the clock for the next byte to be recieved. (Keep in mind the first RX
interrupt will never happen unless you kickstart the whole process with a
TXBUF write. )
Now, in regards to the external DAC, this clock signal will not be regular. It
will have 8 cycles, then a small pause then 8 more, etc.. This is due to the
time it takes the processor to service the RX interrupt. What is the DAC
clock for? Communication? Is it a parralel connection with a strobe pin? IF
this is so, then you should be okay, although you'll be updating the DAC 8
times for each update of the Atmel. That may be okay, or it may not.
If you need a constant clock signal for the DAC, setup a timer to output one
of the timer ports. That would be a better choice IMHO..
The SPI setup seemed strange to me at first too, but a constant clock signal
would result in framing issues. There's likely other reasons for it too,
but
it does allow more control over the data stream.
-Micah
On Monday 28 March 2005 05:27 pm, bigdog16_83 wrote:
> Interesting. So your saying for me to continously recieve data from
> the atmel, which i should be doing once I send it the continuous
> read command, that I have to keep something in the transfer buffer
> to keep that clock running? If I have a receive interrupt set, does
> this mean I need to put something in the transfer buffer every time
> that the interrupt is called? If this is so does this change the
> rate data is being sent to me?
>
> With this - if I am taking the data I receive and sending it out
> port 4 to an external DAC, can I use this same clock that I'm
> receiving on to run the DAC or will this cause other issues?
>
> --- In msp430@msp4..., Micah Stevens <micah@9...> wrote:
> > <top post>
> > Sounds to me like you both are right, the SPI does have it's own
>
> clock line.
>
> > This clock 'line' or wire, has a signal that is generated
by the
>
> master SPI
>
> > interface.
> >
> > In this case, this would be the MSP, the Atmel, being the slave
>
> device is
>
> > connected to the clock signal line. When the MSP wants to read
>
> data from the
>
> > Atmel, it needs to place some value in the master TX register.
>
> This will
>
> > trigger clock pulses on the clock line, which the Atmel will see
>
> and send out
>
> > data to be stored in the MSP RX register.
> >
> > Now, not being familiar with the Atmel, I assume there's some
>
> method for the
>
> > MSP to determine when there's data to be read. But that's
another
>
> issue.
>
> > -Micah
> >
> > On Saturday 26 March 2005 07:00 am, budfrog99 wrote:
> > > "...I thought the SPI had its own clock line ..."
> > >
> > > Nope. There is a master and slave(s). The master provides the
>
> clock
>
> > > whenever it wants something to happen on the SPI.
> > >
> > > Lee
> > >
> > > --- In msp430@msp4..., "bigdog16_83"
<bigdog16_83@y...>
>
> wrote:
> > > > Does this not defeat the whole advantage of the SPI? I
>
> thought the
>
> > > > SPI had its own clock line which transfer and receive data
was
> > > > attached to each of the edges? This also defeats my
purpose.
>
> I'm
>
> > > > using this to have the flash (storing a .wav file) send
the
>
> file
>
> > > > back to the MSP which will direct it out to an external
DAC.
>
> If I
>
> > > am
> > >
> > > > misunderstanding the SPI please explain more.
> > > >
> > > > --- In msp430@msp4..., "Matt Sabino"
<msabino@a...>
>
> wrote:
> > > > > Since the Atmel dataflash is a SPI slave device, it
doesn't
>
> put
>
> > > >
> > > > any information out on the SPI bus unless you clock it.
Just
>
> stuff
>
> > > > U0TXBUF with a value like 0x00 (or some other arbitrary
>
> value) for
>
> > > > every time you want to read a byte.
> > > >
> > > > > HTH,
> > > > >
> > > > >
> > > > > Matt Sabino
> > > > > Computer Engineer
> > > > > Airtronic Services, Inc.
> > > > >
> > > > > ----- Original Message -----
> > > > > From: bigdog16_83
> > > > > To: msp430@msp4...
> > > > > Sent: Friday, March 25, 2005 11:58 AM
> > > > > Subject: [msp430] SPI Problems
> > > > >
> > > > >
> > > > >
> > > > > I am working to communicate with an ATMEL
AT45DB081B
>
> dataflash
>
> > > >
> > > > in
> > > >
> > > > > SPI Mode with a MSP430-149. The opcode sent to the
flash
>
> should
>
> > > >
> > > > make
> > > >
> > > > > it do a continuous read so I should continuously be
>
> receiving
>
> > > >
> > > > data
> > > >
> > > > > but instead I receive a few bytes and then it
stops. The
>
> flash
>
> > > >
> > > > needs
> > > >
> > > > > SPI Mode 0 or 3 and needs a high to low transition
on pin
>
> 3.0
>
> > > >
> > > > before
> > > >
> > > > > a opcode is sent. I believe I have the
initializations
>
> right
>
> > > but
> > >
> > > > I
> > > >
> > > > > need some help debugging. I have an 8Mhz crystal on
>
> installed
>
> > > on
> > >
> > > > the
> > > >
> > > > > XT2CLK. Any problems found, advice, or anything
would be
>
> of
>
> > > help
> > >
> > > > as
> > > >
> > > > > I need to get this going.
> > > > >
> > > > > void main(void)
> > > > > {
> > > > > unsigned int dco_cnt;
> > > > > BCSCTL1 &= ~XT2OFF; // XT2on
> > > > > do // wait for MCLK
from
>
> quartz
>
> > > > > {
> > > > > IFG1 &= ~OFIFG; // Clear
OSCFault
>
> flag
>
> > > > > for (dco_cnt = 0xff; dco_cnt > 0;
dco_cnt--
> > > >
> > > > ); //
> > > >
> > > > > Time for flag to set
> > > > > }
> > > > > while ((IFG1 & OFIFG) != 0); //
OSCFault flag
> > >
> > > still
> > >
> > > > set?
> > > >
> > > > > WDTCTL = WDTPW + WDTHOLD; // Stop watchdog
timer
> > > > >
> > > > > BCSCTL1 = 0x07; // LFXT1: XT2on:
LF
>
> quartz for
>
> > > >
> > > > MCLK
> > > >
> > > > > P3SEL |= 0x0E; // P5.1-3 SPI
option
>
> select
>
> > > > > P3DIR |= 0x01; // P5.0 output
direction
> > > > > P3OUT = 0xff;
> > > > > ME1 |= USPIE0; // Enable USART1
SPI mode
> > > > > UTCTL0 = CKPH | SSEL1 | SSEL0 | STC;
//
>
> SMCLK, 3-
>
> > > >
> > > > pin
> > > >
> > > > > mode, clock idle low, data valid on rising edge,
UCLK
>
> delayed
>
> > > > > UBR00 = 0x02; // 0x02:
UCLK/2 (4
>
> MHz),
>
> > > > > works also with 3 and 4
> > > > > UBR10 = 0x00; // -"-
> > > > > UMCTL0 = 0x00; // no modulation
> > > > > UCTL0 = CHAR | SYNC | MM; // 8-bit SPI
Master
> > > >
> > > > **SWRST**
> > > >
> > > > > IE1 |= URXIE0;
> > > > > _EINT();
> > > > >
> > > > > P1DIR |= 0x01;
> > > > >
> > > > > continuous_Read(S1_B1,S1_B2,S1_B3);
> > > > >
> > > > > for(;;)
> > > > > {
> > > > > }
> > > > > }
> > > > >
> > > > > #pragma vector=USART0RX_VECTOR
> > > > > __interrupt void SPI0_RX (void)
> > > > > {
> > > > >
> > > > > P1OUT ^= 0x01; //Toggle light to show
data is
> > > >
> > > > received
> > > >
> > > > > {
> > > > > unsigned int y;
> > > > > y = 50000; //
Delay
> > > > > do (y--);
> > > > > while (y != 0);
> > > > > y = 50000;
//
>
> Delay
>
> > > > > do (y--);
> > > > > while (y != 0);
> > > > > }
> > > > >
> > > > >
> > > > > }
> > > > > void continuous_Read(int Byte1, int Byte2, int
Byte3)
> > > > > {
> > > > > CS_LOW();
> > > > > //P3OUT ^= 0x01;
//Reset
>
> Memory to
>
> > > > > assure proper timing
> > > > > i = 50000; //
Delay
> > > > > do (i--);
> > > > > while (i != 0);
> > > > >
> > > > > //Flash needs opcode +24 bits
of start
>
> address
>
> > > +
> > >
> > > > 32
> > > >
> > > > > don't care bits
> > > > > U0TXBUF = 0xE8;
//opcode for
> > > > > continous array read
> > > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> > >
> > > buffer
> > >
> > > > > ready?
> > > > > U0TXBUF = Byte1;
//First
>
> Byte of
>
> > > >
> > > > 24-
> > > >
> > > > > bit address sequence
> > > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> > >
> > > buffer
> > >
> > > > > ready?
> > > > > U0TXBUF = Byte2;
//Second
>
> Byte
>
> > > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> > >
> > > buffer
> > >
> > > > > ready?
> > > > > U0TXBUF = Byte3;
//Third
>
> Byte
>
> > > > >
> > > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> > >
> > > buffer
> > >
> > > > > ready?
> > > > > U0TXBUF = 0xFF;
//First
>
> byte of
>
> > > 32-
> > >
> > > > > don't care bits
> > > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> > >
> > > buffer
> > >
> > > > > ready?
> > > > > U0TXBUF = 0xFF;
//Second
>
> Byte
>
> > > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> > >
> > > buffer
> > >
> > > > > ready?
> > > > > U0TXBUF = 0xFF;
//Third Byte
> > > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> > >
> > > buffer
> > >
> > > > > ready?
> > > > > U0TXBUF = 0xFF;
//Final Byte
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > .
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ------------------------
>
> ------
>
> > > -
> > >
> > > > -----------
> > > >
> > > > > .
Reply by ●March 28, 20052005-03-28
OK - that makes more sense now. The DAC is the TI DAC 908 - we are using it to change digital data coming from pins 4.0-4.7 into analog data that can be run to an amplifier and then to a speaker. The DAC needs the clock to run data into the device. I set up a clk on timer A but I am unsure as to how to time the the clock with the data coming in on the SPI (RX interrupt). Does this timing matter? I am receiveing data in the interrupt and sending it to the P4 ports where it is clocked into the DAC based on the timer. I would figure that the timing of the DAC clock would have to somewhat be in conjunction with the timing of the SPI. Correct? --- In msp430@msp4..., Micah Stevens <micah@9...> wrote: > > > Yes, once you recieve a byte, the interrupt will be called, then you need to > get the byte from the buffer, then send another byte to the TX buffer to kick > the clock for the next byte to be recieved. (Keep in mind the first RX > interrupt will never happen unless you kickstart the whole process with a > TXBUF write. ) > > Now, in regards to the external DAC, this clock signal will not be regular. It > will have 8 cycles, then a small pause then 8 more, etc.. This is due to the > time it takes the processor to service the RX interrupt. What is the DAC > clock for? Communication? Is it a parralel connection with a strobe pin? IF > this is so, then you should be okay, although you'll be updating the DAC 8 > times for each update of the Atmel. That may be okay, or it may not. > > If you need a constant clock signal for the DAC, setup a timer to output one > of the timer ports. That would be a better choice IMHO.. > > The SPI setup seemed strange to me at first too, but a constant clock signal > would result in framing issues. There's likely other reasons for it too, but > it does allow more control over the data stream. > > -Micah > > > On Monday 28 March 2005 05:27 pm, bigdog16_83 wrote: > > Interesting. So your saying for me to continously recieve data from > > the atmel, which i should be doing once I send it the continuous > > read command, that I have to keep something in the transfer buffer > > to keep that clock running? If I have a receive interrupt set, does > > this mean I need to put something in the transfer buffer every time > > that the interrupt is called? If this is so does this change the > > rate data is being sent to me? > > > > With this - if I am taking the data I receive and sending it out > > port 4 to an external DAC, can I use this same clock that I'm > > receiving on to run the DAC or will this cause other issues? > > > > --- In msp430@msp4..., Micah Stevens <micah@9...> wrote: > > > <top post> > > > Sounds to me like you both are right, the SPI does have it's own > > > > clock line. > > > > > This clock 'line' or wire, has a signal that is generated by the > > > > master SPI > > > > > interface. > > > > > > In this case, this would be the MSP, the Atmel, being the slave > > > > device is > > > > > connected to the clock signal line. When the MSP wants to read > > > > data from the > > > > > Atmel, it needs to place some value in the master TX register. > > > > This will > > > > > trigger clock pulses on the clock line, which the Atmel will see > > > > and send out > > > > > data to be stored in the MSP RX register. > > > > > > Now, not being familiar with the Atmel, I assume there's some > > > > method for the > > > > > MSP to determine when there's data to be read. But that's another > > > > issue. > > > > > -Micah > > > > > > On Saturday 26 March 2005 07:00 am, budfrog99 wrote: > > > > "...I thought the SPI had its own clock line ..." > > > > > > > > Nope. There is a master and slave(s). The master provides the > > > > clock > > > > > > whenever it wants something to happen on the SPI. > > > > > > > > Lee > > > > > > > > --- In msp430@msp4..., "bigdog16_83" <bigdog16_83@y...> > > > > wrote: > > > > > Does this not defeat the whole advantage of the SPI? I > > > > thought the > > > > > > > SPI had its own clock line which transfer and receive data was > > > > > attached to each of the edges? This also defeats my purpose. > > > > I'm > > > > > > > using this to have the flash (storing a .wav file) send the > > > > file > > > > > > > back to the MSP which will direct it out to an external DAC. > > > > If I > > > > > > am > > > > > > > > > misunderstanding the SPI please explain more. > > > > > > > > > > --- In msp430@msp4..., "Matt Sabino" <msabino@a...> > > > > wrote: > > > > > > Since the Atmel dataflash is a SPI slave device, it doesn't > > > > put > > > > > > > > > > > > any information out on the SPI bus unless you clock it. Just > > > > stuff > > > > > > > U0TXBUF with a value like 0x00 (or some other arbitrary > > > > value) for > > > > > > > every time you want to read a byte. > > > > > > > > > > > HTH, > > > > > > > > > > > > > > > > > > Matt Sabino > > > > > > Computer Engineer > > > > > > Airtronic Services, Inc. > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: bigdog16_83 > > > > > > To: msp430@msp4... > > > > > > Sent: Friday, March 25, 2005 11:58 AM > > > > > > Subject: [msp430] SPI Problems > > > > > > > > > > > > > > > > > > > > > > > > I am working to communicate with an ATMEL AT45DB081B > > > > dataflash > > > > > > > > > > > > in > > > > > > > > > > > SPI Mode with a MSP430-149. The opcode sent to the flash > > > > should > > > > > > > > > > > > make > > > > > > > > > > > it do a continuous read so I should continuously be > > > > receiving > > > > > > > > > > > > data > > > > > > > > > > > but instead I receive a few bytes and then it stops. The > > > > flash > > > > > > > > > > > > needs > > > > > > > > > > > SPI Mode 0 or 3 and needs a high to low transition on pin > > > > 3.0 > > > > > > > > > > > > before > > > > > > > > > > > a opcode is sent. I believe I have the initializations > > > > right > > > > > > but > > > > > > > > > I > > > > > > > > > > > need some help debugging. I have an 8Mhz crystal on > > > > installed > > > > > > on > > > > > > > > > the > > > > > > > > > > > XT2CLK. Any problems found, advice, or anything would be > > > > of > > > > > > help > > > > > > > > > as > > > > > > > > > > > I need to get this going. > > > > > > > > > > > > void main(void) > > > > > > { > > > > > > unsigned int dco_cnt; > > > > > > BCSCTL1 &= ~XT2OFF; // XT2on > > > > > > do // wait for MCLK from > > > > quartz > > > > > > > > { > > > > > > IFG1 &= ~OFIFG; // Clear OSCFault > > > > flag > > > > > > > > for (dco_cnt = 0xff; dco_cnt > 0; dco_cnt-- > > > > > > > > > > ); // > > > > > > > > > > > Time for flag to set > > > > > > } > > > > > > while ((IFG1 & OFIFG) != 0); // OSCFault flag > > > > > > > > still > > > > > > > > > set? > > > > > > > > > > > WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer > > > > > > > > > > > > BCSCTL1 = 0x07; // LFXT1: XT2on: LF > > > > quartz for > > > > > > > > > > > > MCLK > > > > > > > > > > > P3SEL |= 0x0E; // P5.1-3 SPI option > > > > select > > > > > > > > P3DIR |= 0x01; // P5.0 output direction > > > > > > P3OUT = 0xff; > > > > > > ME1 |= USPIE0; // Enable USART1 SPI mode > > > > > > UTCTL0 = CKPH | SSEL1 | SSEL0 | STC; // > > > > SMCLK, 3- > > > > > > > > > > > > pin > > > > > > > > > > > mode, clock idle low, data valid on rising edge, UCLK > > > > delayed > > > > > > > > UBR00 = 0x02; // 0x02: UCLK/2 (4 > > > > MHz), > > > > > > > > works also with 3 and 4 > > > > > > UBR10 = 0x00; // -"- > > > > > > UMCTL0 = 0x00; // no modulation > > > > > > UCTL0 = CHAR | SYNC | MM; // 8-bit SPI Master > > > > > > > > > > **SWRST** > > > > > > > > > > > IE1 |= URXIE0; > > > > > > _EINT(); > > > > > > > > > > > > P1DIR |= 0x01; > > > > > > > > > > > > continuous_Read(S1_B1,S1_B2,S1_B3); > > > > > > > > > > > > for(;;) > > > > > > { > > > > > > } > > > > > > } > > > > > > > > > > > > #pragma vector=USART0RX_VECTOR > > > > > > __interrupt void SPI0_RX (void) > > > > > > { > > > > > > > > > > > > P1OUT ^= 0x01; //Toggle light to show data is > > > > > > > > > > received > > > > > > > > > > > { > > > > > > unsigned int y; > > > > > > y = 50000; // Delay > > > > > > do (y--); > > > > > > while (y != 0); > > > > > > y = 50000; // > > > > Delay > > > > > > > > do (y--); > > > > > > while (y != 0); > > > > > > } > > > > > > > > > > > > > > > > > > } > > > > > > void continuous_Read(int Byte1, int Byte2, int Byte3) > > > > > > { > > > > > > CS_LOW(); > > > > > > //P3OUT ^= 0x01; //Reset > > > > Memory to > > > > > > > > assure proper timing > > > > > > i = 50000; // Delay > > > > > > do (i--); > > > > > > while (i != 0); > > > > > > > > > > > > //Flash needs opcode +24 bits of start > > > > address > > > > > > + > > > > > > > > > 32 > > > > > > > > > > > don't care bits > > > > > > U0TXBUF 0xE8; //opcode for > > > > > > continous array read > > > > > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX > > > > > > > > buffer > > > > > > > > > > ready? > > > > > > U0TXBUF Byte1; //First > > > > Byte of > > > > > > > > > > > > 24- > > > > > > > > > > > bit address sequence > > > > > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX > > > > > > > > buffer > > > > > > > > > > ready? > > > > > > U0TXBUF Byte2; //Second > > > > Byte > > > > > > > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX > > > > > > > > buffer > > > > > > > > > > ready? > > > > > > U0TXBUF Byte3; //Third > > > > Byte > > > > > > > > > > > > > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX > > > > > > > > buffer > > > > > > > > > > ready? > > > > > > U0TXBUF = 0xFF; //First > > > > byte of > > > > > > 32- > > > > > > > > > > don't care bits > > > > > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX > > > > > > > > buffer > > > > > > > > > > ready? > > > > > > U0TXBUF 0xFF; //Second > > > > Byte > > > > > > > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX > > > > > > > > buffer > > > > > > > > > > ready? > > > > > > U0TXBUF 0xFF; //Third Byte > > > > > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX > > > > > > > > buffer > > > > > > > > > > ready? > > > > > > U0TXBUF 0xFF; //Final Byte > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------- ----- > > > > ------ > > > > > > - > > > > > > > > > ----------- > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > a.. To visit your group on the web, go to: > > > > > > http://groups.yahoo.com/group/msp430/ > > > > > > > > > > > > b.. . > > > > > > > > > > > > c.. Your use of Yahoo! Groups is subject to the Yahoo! > > > > Terms > > > > > > > > > > > > of Service. > > > > > > > > > > > ------------------- ----- > > > > ------ > > > > > > - > > > > > > > > > ----------- > > > > > > > > > > > No virus found in this incoming message. > > > > > > Checked by AVG Anti-Virus. > > > > > > Version: 7.0.308 / Virus Database: 266.8.2 - Release Date: > > > > > > > > > > 3/25/2005 > > > > > > > > > > > ---------- > > > > > > > > > > > > No virus found in this outgoing message. > > > > > > Checked by AVG Anti-Virus. > > > > > > Version: 7.0.308 / Virus Database: 266.8.2 - Release Date: > > > > > > > > > > 3/25/2005 > > > > > > > > > > > > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > To visit your group on the web, go to: > > > > http://groups.yahoo.com/group/msp430/ > > > > > > > > . > > > > > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of > > > > Service. > > > > > > > > > > > > . > > > > > > > > > > > > > > click here > > > > Yahoo! Groups Links > > > > To visit your group on the web, go to: > > http://groups.yahoo.com/group/msp430/ > > > > . > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Reply by ●March 28, 20052005-03-28
Actually, just bit banging may make more sense. i.e.
(assumes Pin 3.7 is your DAC Clock line)
UART_RX_VECTOR ( void ) {
/* first get your value from the atmel */
P4OUT = RXBUF0; // send it to port 4.
/* toggle DAC Clock */
P3OUT |= BIT7; // bring clk high
P3OUT ^= ~BIT7; // bring clk low again.
/* get your next value going */
TXBUF0 = 0x0; // kickstart the next receive
}
That would probably do the trick, that's without knowing anything about any
timing issues that the DAC needs, but it sounds like it's just a strobe. If
it needs the Clock high for a period, just toss in a timing loop..
HTH
-Micah
On Monday 28 March 2005 06:51 pm, bigdog16_83 wrote:
> OK - that makes more sense now. The DAC is the TI DAC 908 - we are
> using it to change digital data coming from pins 4.0-4.7 into analog
> data that can be run to an amplifier and then to a speaker. The DAC
> needs the clock to run data into the device. I set up a clk on timer
> A but I am unsure as to how to time the the clock with the data
> coming in on the SPI (RX interrupt). Does this timing matter? I am
> receiveing data in the interrupt and sending it to the P4 ports
> where it is clocked into the DAC based on the timer. I would figure
> that the timing of the DAC clock would have to somewhat be in
> conjunction with the timing of the SPI. Correct?
>
> --- In msp430@msp4..., Micah Stevens <micah@9...> wrote:
> > Yes, once you recieve a byte, the interrupt will be called, then
>
> you need to
>
> > get the byte from the buffer, then send another byte to the TX
>
> buffer to kick
>
> > the clock for the next byte to be recieved. (Keep in mind the
>
> first RX
>
> > interrupt will never happen unless you kickstart the whole process
>
> with a
>
> > TXBUF write. )
> >
> > Now, in regards to the external DAC, this clock signal will not be
>
> regular. It
>
> > will have 8 cycles, then a small pause then 8 more, etc.. This is
>
> due to the
>
> > time it takes the processor to service the RX interrupt. What is
>
> the DAC
>
> > clock for? Communication? Is it a parralel connection with a
>
> strobe pin? IF
>
> > this is so, then you should be okay, although you'll be updating
>
> the DAC 8
>
> > times for each update of the Atmel. That may be okay, or it may
>
> not.
>
> > If you need a constant clock signal for the DAC, setup a timer to
>
> output one
>
> > of the timer ports. That would be a better choice IMHO..
> >
> > The SPI setup seemed strange to me at first too, but a constant
>
> clock signal
>
> > would result in framing issues. There's likely other reasons for
>
> it too, but
>
> > it does allow more control over the data stream.
> >
> > -Micah
> >
> > On Monday 28 March 2005 05:27 pm, bigdog16_83 wrote:
> > > Interesting. So your saying for me to continously recieve data
>
> from
>
> > > the atmel, which i should be doing once I send it the
continuous
> > > read command, that I have to keep something in the transfer
>
> buffer
>
> > > to keep that clock running? If I have a receive interrupt set,
>
> does
>
> > > this mean I need to put something in the transfer buffer every
>
> time
>
> > > that the interrupt is called? If this is so does this change
the
> > > rate data is being sent to me?
> > >
> > > With this - if I am taking the data I receive and sending it
out
> > > port 4 to an external DAC, can I use this same clock that
I'm
> > > receiving on to run the DAC or will this cause other issues?
> > >
> > > --- In msp430@msp4..., Micah Stevens <micah@9...> wrote:
> > > > <top post>
> > > > Sounds to me like you both are right, the SPI does have
it's
>
> own
>
> > > clock line.
> > >
> > > > This clock 'line' or wire, has a signal that is
generated by
>
> the
>
> > > master SPI
> > >
> > > > interface.
> > > >
> > > > In this case, this would be the MSP, the Atmel, being the
>
> slave
>
> > > device is
> > >
> > > > connected to the clock signal line. When the MSP wants to
read
> > >
> > > data from the
> > >
> > > > Atmel, it needs to place some value in the master TX
register.
> > >
> > > This will
> > >
> > > > trigger clock pulses on the clock line, which the Atmel
will
>
> see
>
> > > and send out
> > >
> > > > data to be stored in the MSP RX register.
> > > >
> > > > Now, not being familiar with the Atmel, I assume
there's some
> > >
> > > method for the
> > >
> > > > MSP to determine when there's data to be read. But
that's
>
> another
>
> > > issue.
> > >
> > > > -Micah
> > > >
> > > > On Saturday 26 March 2005 07:00 am, budfrog99 wrote:
> > > > > "...I thought the SPI had its own clock line
..."
> > > > >
> > > > > Nope. There is a master and slave(s). The master
>
> provides the
>
> > > clock
> > >
> > > > > whenever it wants something to happen on the SPI.
> > > > >
> > > > > Lee
> > > > >
> > > > > --- In msp430@msp4..., "bigdog16_83"
>
> <bigdog16_83@y...>
>
> > > wrote:
> > > > > > Does this not defeat the whole advantage of the
SPI? I
> > >
> > > thought the
> > >
> > > > > > SPI had its own clock line which transfer and
receive
>
> data was
>
> > > > > > attached to each of the edges? This also
defeats my
>
> purpose.
>
> > > I'm
> > >
> > > > > > using this to have the flash (storing a .wav
file) send
>
> the
>
> > > file
> > >
> > > > > > back to the MSP which will direct it out to an
external
>
> DAC.
>
> > > If I
> > >
> > > > > am
> > > > >
> > > > > > misunderstanding the SPI please explain more.
> > > > > >
> > > > > > --- In msp430@msp4..., "Matt Sabino"
>
> <msabino@a...>
>
> > > wrote:
> > > > > > > Since the Atmel dataflash is a SPI slave
device, it
>
> doesn't
>
> > > put
> > >
> > > > > >
> > > > > > any information out on the SPI bus unless you
clock it.
>
> Just
>
> > > stuff
> > >
> > > > > > U0TXBUF with a value like 0x00 (or some other
arbitrary
> > >
> > > value) for
> > >
> > > > > > every time you want to read a byte.
> > > > > >
> > > > > > > HTH,
> > > > > > >
> > > > > > >
> > > > > > > Matt Sabino
> > > > > > > Computer Engineer
> > > > > > > Airtronic Services, Inc.
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > From: bigdog16_83
> > > > > > > To: msp430@msp4...
> > > > > > > Sent: Friday, March 25, 2005 11:58 AM
> > > > > > > Subject: [msp430] SPI Problems
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I am working to communicate with an
ATMEL AT45DB081B
> > >
> > > dataflash
> > >
> > > > > >
> > > > > > in
> > > > > >
> > > > > > > SPI Mode with a MSP430-149. The opcode
sent to the
>
> flash
>
> > > should
> > >
> > > > > >
> > > > > > make
> > > > > >
> > > > > > > it do a continuous read so I should
continuously be
> > >
> > > receiving
> > >
> > > > > >
> > > > > > data
> > > > > >
> > > > > > > but instead I receive a few bytes and
then it stops.
>
> The
>
> > > flash
> > >
> > > > > >
> > > > > > needs
> > > > > >
> > > > > > > SPI Mode 0 or 3 and needs a high to low
transition
>
> on pin
>
> > > 3.0
> > >
> > > > > >
> > > > > > before
> > > > > >
> > > > > > > a opcode is sent. I believe I have the
>
> initializations
>
> > > right
> > >
> > > > > but
> > > > >
> > > > > > I
> > > > > >
> > > > > > > need some help debugging. I have an 8Mhz
crystal on
> > >
> > > installed
> > >
> > > > > on
> > > > >
> > > > > > the
> > > > > >
> > > > > > > XT2CLK. Any problems found, advice, or
anything
>
> would be
>
> > > of
> > >
> > > > > help
> > > > >
> > > > > > as
> > > > > >
> > > > > > > I need to get this going.
> > > > > > >
> > > > > > > void main(void)
> > > > > > > {
> > > > > > > unsigned int dco_cnt;
> > > > > > > BCSCTL1 &= ~XT2OFF;
// XT2on
> > > > > > > do //
wait for MCLK
>
> from
>
> > > quartz
> > >
> > > > > > > {
> > > > > > > IFG1 &=
~OFIFG; // Clear
>
> OSCFault
>
> > > flag
> > >
> > > > > > > for (dco_cnt = 0xff; dco_cnt
> 0;
>
> dco_cnt--
>
> > > > > >
> > > > > > ); //
> > > > > >
> > > > > > > Time for flag to set
> > > > > > > }
> > > > > > > while ((IFG1 & OFIFG) !=
0); //
>
> OSCFault flag
>
> > > > >
> > > > > still
> > > > >
> > > > > > set?
> > > > > >
> > > > > > > WDTCTL = WDTPW + WDTHOLD; // Stop
watchdog
>
> timer
>
> > > > > > >
> > > > > > > BCSCTL1 = 0x07; //
LFXT1: XT2on: LF
> > >
> > > quartz for
> > >
> > > > > >
> > > > > > MCLK
> > > > > >
> > > > > > > P3SEL |= 0x0E; //
P5.1-3 SPI option
> > >
> > > select
> > >
> > > > > > > P3DIR |= 0x01; //
P5.0 output
>
> direction
>
> > > > > > > P3OUT = 0xff;
> > > > > > > ME1 |= USPIE0; //
Enable USART1 SPI
>
> mode
>
> > > > > > > UTCTL0 = CKPH | SSEL1 | SSEL0 |
STC; //
> > >
> > > SMCLK, 3-
> > >
> > > > > >
> > > > > > pin
> > > > > >
> > > > > > > mode, clock idle low, data valid on
rising edge, UCLK
> > >
> > > delayed
> > >
> > > > > > > UBR00 = 0x02;
// 0x02:
>
> UCLK/2 (4
>
> > > MHz),
> > >
> > > > > > > works also with 3 and 4
> > > > > > > UBR10 = 0x00;
// -"-
> > > > > > > UMCTL0 = 0x00; // no
modulation
> > > > > > > UCTL0 = CHAR | SYNC | MM;
// 8-bit SPI
>
> Master
>
> > > > > >
> > > > > > **SWRST**
> > > > > >
> > > > > > > IE1 |= URXIE0;
> > > > > > > _EINT();
> > > > > > >
> > > > > > > P1DIR |= 0x01;
> > > > > > >
> > > > > > >
continuous_Read(S1_B1,S1_B2,S1_B3);
> > > > > > >
> > > > > > > for(;;)
> > > > > > > {
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > > #pragma vector=USART0RX_VECTOR
> > > > > > > __interrupt void SPI0_RX (void)
> > > > > > > {
> > > > > > >
> > > > > > > P1OUT ^= 0x01; //Toggle
light to show
>
> data is
>
> > > > > >
> > > > > > received
> > > > > >
> > > > > > > {
> > > > > > > unsigned int y;
> > > > > > > y =
50000; //
>
> Delay
>
> > > > > > > do (y--);
> > > > > > > while (y != 0);
> > > > > > > y =
50000; //
> > >
> > > Delay
> > >
> > > > > > > do (y--);
> > > > > > > while (y != 0);
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > > }
> > > > > > > void continuous_Read(int Byte1, int
Byte2, int Byte3)
> > > > > > > {
> > > > > > > CS_LOW();
> > > > > > > //P3OUT ^=
0x01; //Reset
> > >
> > > Memory to
> > >
> > > > > > > assure proper timing
> > > > > > > i =
50000; // Delay
> > > > > > > do (i--);
> > > > > > > while (i != 0);
> > > > > > >
> > > > > > > //Flash needs opcode
+24 bits of
>
> start
>
> > > address
> > >
> > > > > +
> > > > >
> > > > > > 32
> > > > > >
> > > > > > > don't care bits
> > > > > > > U0TXBUF >
> 0xE8; //opcode for
>
> > > > > > > continous array read
> > > > > > > while ((IFG1 & UTXIFG0) ==
0); //
>
> USART0 TX
>
> > > > >
> > > > > buffer
> > > > >
> > > > > > > ready?
> > > > > > > U0TXBUF >
> Byte1; //First
>
> > > Byte of
> > >
> > > > > >
> > > > > > 24-
> > > > > >
> > > > > > > bit address sequence
> > > > > > > while ((IFG1 & UTXIFG0) ==
0); //
>
> USART0 TX
>
> > > > >
> > > > > buffer
> > > > >
> > > > > > > ready?
> > > > > > > U0TXBUF >
> Byte2; //Second
>
> > > Byte
> > >
> > > > > > > while ((IFG1 & UTXIFG0) ==
0); //
>
> USART0 TX
>
> > > > >
> > > > > buffer
> > > > >
> > > > > > > ready?
> > > > > > > U0TXBUF >
> Byte3; //Third
>
> > > Byte
> > >
> > > > > > >
> > > > > > > while ((IFG1 & UTXIFG0) ==
0); //
>
> USART0 TX
>
> > > > >
> > > > > buffer
> > > > >
> > > > > > > ready?
> > > > > > > U0TXBUF =
0xFF; //First
> > >
> > > byte of
> > >
> > > > > 32-
> > > > >
> > > > > > > don't care bits
> > > > > > > while ((IFG1 & UTXIFG0) ==
0); //
>
> USART0 TX
>
> > > > >
> > > > > buffer
> > > > >
> > > > > > > ready?
> > > > > > > U0TXBUF >
> 0xFF; //Second
>
> > > Byte
> > >
> > > > > > > while ((IFG1 & UTXIFG0) ==
0); //
>
> USART0 TX
>
> > > > >
> > > > > buffer
> > > > >
> > > > > > > ready?
> > > > > > > U0TXBUF >
> 0xFF; //Third Byte
>
> > > > > > > while ((IFG1 & UTXIFG0) ==
0); //
>
> USART0 TX
>
> > > > >
> > > > > buffer
> > > > >
> > > > > > > ready?
> > > > > > > U0TXBUF >
> 0xFF; //Final Byte
>
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > .
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -------------------
>
> -----
>
> > > ------
> > >
> > > > > -
> > > > >
> > > > > > -----------
> > > > > >
> > > > > > > .
Reply by ●March 30, 20052005-03-30
micah, I don't think there would necessarily be a pause in the clock - firstly I'd, personally, do the TX when the tx buffer reports itself empty. You might need a few flags to tell it when to stop doing so... but if you do it that way you will get a regular pulse train. even if you did do the TX from the receive routine, you may be half a bit -time ahead of the end of the char when you get the data, which is quite long enough to do the TX and not break the chain.... David
