Thank you for your answers. I know the slave is taking the clock from the
master, but TI specifies that both the master and the slave have a maximum SPI
baud rate that can be generated (given by BRCLK/2 for the master and BRCLK for
the slave). This is why I mentioned these settings in my program. SPI0RXREADY
checks for the URXIFG0 flag. I found the problem to be actually the
debug_putchar instruction. This makes the slave to miss some characters. I
solved it by using an Rx interrupt on the slave to load a buffer. Thanks again
for your answers. They allowed me to discard the idea that the bug could be
clock related.
> > I am setting the master for ACLK/2 and the slave
for ACLK/2
> > or ACLK/1.
The SPI slave gets its SPI clock from the master, there is no setting ACLK in
the slave. Or do you mean you're setting the MCLK in that way?
Second, the code around your "procedure" matters a lot if you want any answers.
More importantly, what is the definition of SPI0RXREADY?
Keep in mind it is also possible that the master is not sending some bytes
instead of the slave not receiving. This would happen if the TX BUFFER is
(over-)written while it is still full, before the byte has been moved to the
shift register. This is likely your problem. Always check TXIFG before writing
to TXBUF.
You should also setup a #CS bit to synchronize the master and slave. If any
device resets or retarts during a transfer, ALL following bytes will be received
out of sync.
And don't forget the time it takes from transfer completion until the slave
has detected completion and stored the byte. There is a flag that indicates if
the RX buffer has been overwritten before being read (missed bytes). Check that
flag to find out if that is your problem.
Reply by micr...@virginbroadband.com.au●April 2, 20092009-04-02
What is the clock to the CPU ? Is it much higher speed than ACLK ?
If it is, then you might be having asynchronous problems, it would also
explain why you're missing chars.
(you're probably more skewed by half cycles and the likes).
If ACLK is merely the typ. 32 kHz clock, try using a higher speed clock on
SPI. Or conversely,
clock the CPU with ACLK *somehow*. (I myself would prefer to use SMCLK).
Also, what do you mean with "ACLK/2 for slave" ?
The slave is clocked from the master's CLK line - it does not have its
own
clock (or at least it should NOT have)
I am experiencing a similar problem with my MSP430 F1612. I'm trying to
send a string through the SPI module, but unless I use huge delays (20000 delay
cycles or more), the slave doesn't receive some of the characters.
I am setting the master for ACLK/2 and the slave for ACLK/2 or ACLK/1. I use
3-pin SPI. Any help is more than appreciated.
Best wishes,
Alex
--- In m..., mm bb wrote: >
> Michael: Thanks for your patient answer, the thing is now working properly, as
you stated the Rx flag set=1 means that all bits in the shift register were
transferred because RX buffer has receive a complete character .I was confused
because I Think that the RX and TX were set at the same time, but this is wrong
because the shift register is in the middle.
> With this concept in mind I arranged the program like this and its work fine.
The zero was just for a prove.
>
> UCB0IFG &= ~UCRXIFG;
> UCB0TXBUF = value; // Send value
> while (!(UCB0IFG&UCRXIFG) ); // USCI_B0 RX buffer ready?
> // while (!(UCB0STAT& UCBUSY));
>
>
> // TI_CC_Wait(10);
> TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
>
>
>
>
> ________________________________
> De: tintronic
> Para: m...
> Enviado: micoles 1 de abril de 2009, 16:26:37
> Asunto: [msp430] Re: Spi simple question
>
>
> The first problem is it seams you don't understand what the TX flag
indicates:
> 0: means the TX buffer is full
> 1: means the TX buffer is empty. There may still be data in the shift
register.
>
> You need to check for the RX flag to know if the byte transmission has
finished, not the TX flag. But that will only work for 1 byte.
>
> The TX falg goes from 0 to 1 when the byte is transferred to the shift
register. After that the SPI clock starts and the byte is shifted out. You are
deselecting the slave right after the shift register has been loaded with the
byte from TXBUF and is starting to be shifted out.
>
> Seriously, changing RX for TX and hoping it will somehow work is not the
answer.
>
> I think the problem is that you're not posting the complete routine.
Since RX should have worked, I'm guessing a transfer is already in progress
when you write 'value' into UCBOTXBUF. So, when you see UCRXIFG going
up to one, it is because the previous byte has been sent and not the last one.
Try the following, just to see if that is the reason. And please don't ever
use register=0 to clear a single flag, or else you're asking for
headaches.
>
> * while (!(UCB0STAT& UCBUSY));
> * UCB0IFG &= ~UCRXIFG;
> > UCB0TXBUF = value; // Send value
> > while (!(UCB0IFG&UCRXIFG) ); // USCI_B0 TX buffer ready?
> >
> > // TI_CC_Wait(10) ;
> > TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
>
> But anyway, you're using the USCI module, right? The why don't you
use the UCBUSY flag to know when the SPI has finished all transmissions? That is
what you should look at before deselecting #CS.
> The RX flag is only used in the USART module because there is no flag that
indicates if the SPI has finished transmission (TXEPT flag seams to have been a
failed attempt at that).
>
> Let us know how it goes.
>
> Michael K.
>
> --- In msp430@yahoogroups. com, mm bb wrote:
> >
> > I will try to be more clear, but you get the problem, is exactly what you
undestand.
> > I also try this way
> >
> > UCB0IFG=0;
> > UCB0TXBUF = value; // Send value
> > while (!(UCB0IFG&UCTXIFG) ); // USCI_B0 TX buffer ready?
> >
> > // TI_CC_Wait(10) ;
> > TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
> > }
> >
> > but it does not work, there were four clockpulses losted after the spi was
disable if I look for the RX flag and only two lost if I wait for TX .
> > What Im missing?
> >
> > In anotherserie f2 we use this scheme and works fine
> >
> > while (!(IFG2&UCB0RXIFG) ); // Wait for TX to finish
> > IFG2 &= ~UCB0RXIFG; // Clear flag
> > UCB0TXBUF = value; // Send data
> > while (!(IFG2&UCB0RXIFG) ); // Wait for TX to finish
> >
> > TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
> >
> >
> >
> >
> >
> > ____________ _________ _________ __
> > De: tintronic
> > Para: msp430@yahoogroups. com
> > Enviado: micoles 1 de abril de 2009, 13:48:34
> > Asunto: [msp430] Re: Spi simple question
> >
> >
> > Ok, I'm not sure what your problem is, either you didn't explain
it well or you have no idea what you are doing.
> > Obviously, you need to wait for the byte to be transferred completely (plus
the delay your slave specifies after the last SPI clock edge) before disabling
the slave, right? So you can't disable #CS right after writing to the
buffer, which means you can't just delete TI_CC_Wait() ;
> >
> > Your code only writes one byte, so I'll assume that you're not
trying to send more than one byte.
> > One way do to know if the transmission has finished is by means of the
RXIFG. But you have to clear RXIFG by software before sending the byte. Then you
write to TX buffer and wait for RXIFG to set, after which you wait for the
appropiate time (it might be less than an MSP instruction cycle) and disable
#CS.
> >
> > Did you search this forum? This has been wiiiidely discussed before.
> >
> > Michael K.
> >
> > --- In msp430@yahoogroups. com, mm bb wrote:
> > >
> > > Thanks for the answer , but I want to show you where there is a
problem with the spi. Im using the msp430t5438, which has some difference
with respect to the other series in employing the flags. I use this
routine to send data
> > >
> > >
> > > while (!(UCB0IFG&UCTXIFG) ); // USCI_B0 TX buffer ready?
> > > UCB0TXBUF = value; // Send value
> > >
> > > TI_CC_Wait(10) ; // this should not be here!!!!!!
> > >
> > >TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
> > >
> > > The problem is, if I don'tt use the delay, the clock and data are
still running.( I saw in the oscilloscope)
> > > when the spi is disable by the next instruction. This way it work, but I
do not understand where is the problem, I have tried also using the RX flag but
it is the same.
> > > This in place of delay :
> > > while (!(UCB0IFG&UCRXIFG) );
> > > Any ideas will be welcome, excuse my English#65533;
> > >
> > >
> > >
> > > ____________ _________ _________ __
> > > De: Matthias Weingart
> > > Para: msp430@yahoogroups. com
> > > Enviado: miércoles 1 de abril de 2009, 7:47:59
> > > Asunto: [msp430] Re: Spi simple question
> > >
> > >
> > > Hi Michael,
> > >
> > > I have used TXEPT for RS232 asynchronous transfers only. I think using the
> > > RXIFG for SPI is a good idea, nothing to say against this. I also use only
> > > RXIFG for SPI. (In that case you can ignore TXIFG completely.)
> > >
> > > M.
> > >
> > > "tintronic" :
> > >
> > > > Thanks Matthias for answering, as I would like to dig more into this
> > > > issue. First, I was wrong about the USCI. I was remembering a block
> > > > diagram which I couldn't find now. USCI does have double buffering.
And
> > > > it has a UCBUSY flag which is much more useful and makes a lot more
> > > > sense than the TXEPT flag, which by the way USCI doesn't have.
> > > >
> > > > On the USART matter, I'm not mixing the flags, I know what each
one
> > > > does. BUT, TI's datasheets don't provide any diagram where you
can see
> > > > TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> > > > Actually, there is no timing of EPT whatsoever, only a brief
description
> > > > stating that it sets when the shift register is empty, but when
exactly
> > > > is that? That's where the guessing and asumptions start. Making
> > > > assumptions, that's a receipe for disaster.
> > > >
> > > > Have you ever used EPT flag for deselecting the SPI slave? I have
done
> > > > so without luck. So have other people on the forum (many more were
> > > > wrongly using TX flag). They had to put a delay after EPT or the
slave
> > > > wouldn't recognize the last byte. Even TI's sample codes
(CC1100 for
> > > > example) don't use EPT flag for deselecting the slave on SPI
burst
> > > > writes, instead they use the RX flag. Since I very often use more
than
> > > > one SPI slave on the same bus, my codes always deselect the devices
> > > > after transfer completion.
> > > >
> > > > And yes, I know one has to check the timing parameters of the slave
to
> > > > know how much time after the last SPI clock edge one has to wait
before
> > > > deselecting the device for it to accept the full byte. I have
respected
> > > > all the timing parameters (hell, the time on some devices is shorter
> > > > than one 8MHz clock cycle) and still I have had to use RX flag
because
> > > > EPT wouldn't work.
> > > >
> > > > All of the above leads me to think the EPT flag sets as soon as the
last
> > > > transmitted bit is present at the MOSI pin, which effectively empties
> > > > the shift register, before the following clock edge which is when the
> > > > slave captures the MOSI pin value. I still might be wrong, as I
haven't
> > > > used EPT ever again, but based on my above observations, I can't
> > > > conclude anything else. I mean, why the hell wouldn't TI publish
the
> > > > timing diagram of TXEPT or at least include it on the timing diagram
of
> > > > the SPI transfer?
> > > >
> > > > I've made drivers for various SPI and SPI-like devices, all using
the RX
> > > > flag, so any new SPI devices I just recycle code from another device.
> > > > I've not dealt with EPT ever again, I've got some ideas on how
to really
> > > > know when EPT sets, but just haven't got the time right now to test
it.
> > > > It would be as simple as using an external clock source like a
> > > > (filtered) push button, or a very slow SPI clock, and a couple of
leds
> > > > that permanently show the status of the TX, RX and EPT flags and the
> > > > MOSI and CLK pins.
> > > >
> > > > Best Regards,
> > > > Michael K.
> > > >
> > > > --- In msp430@yahoogroups. com, Matthias Weingart wrote:
> > > >>
> > > >> "tintronic" :
> > > >>
> > > >> > On the MSP, the USART TX flag doesn't indicate that the
transmission
> > > >> > has finished, it only indicates that the TX buffer is empty. There
> > > >> > still might be bits in the shift register that are being sent. For
> > > >> > that matter, neither does TXEPT flag, which indicates that the
shift
> > > >> > register is empty, because it (seams to) sets as soon as the last
bit
> > > >> > in the shift register hits the output pin, which is half a clock
> > > >> > cycle before the clock edge on which the (spi) slave capturates
the
> > > >> > data bit. So, you need to use the RX flag, which is tricky when
you
> > > >> > try to take advantage of the "double buffering" (one byte for
> > > >> > shifting out and another one to store the next byte) sending
multiple
> > > >> > bytes in a row. Tricky, because RX falg will set when the second
last
> > > >> > byte written to the TXBUFFER has been received by the slave. And
this
> > > >> > won't work if the function can be interrupted, because you could
miss
> > > >> > an RX flag and the function would get stuck. I guess one could use
a
> > > >> > combination of TXEPT and reading the clock pin value. It should
work,
> > > >> > but I haven't tried it. I any case, I haven't found a
single use for
> > > >> > TXEPT flag. I think I've asked before and gotten no answers, but
if
> > > >> > anyone has an idea of what TXEPT could be used for, please
enlighten
> > > >> > me.
> > > >>
> > > >> I might be wrong but I think you are mixing the meaning of two
flags.
> > > >> TXIFG is set once the TXBUF is loaded into the shift register (like
> > > >> your description) . After that the shift register clocks 8 bits out
of
> > > >> the TXD-Pin and when this is finished the TXEPT is set. For SPI
master
> > > >> TXEPT is set at the same time as RXIFG.
> > > >> I have used TXEPT to wait until the last character has shifted out
> > > >> completely. Only after that it is allowed to set LPM3 (because with
> > > >> LPM3 the UART clock will be stopped also in some cases).
> > > >>
> > > >> > I might be wrong, but I think the USCI hasn't this problem,
basically
> > > >> > because it doesn't have a transmit buffer, just a single
shift
> > > >> > register that's used for both transmitting and receiving data,
in
> > > >> > which case probably both Rx and TX flag will work the same in SPI
> > > >> > master mode.
> > > >>
> > > >> No. Just got USCI and DMA working and I have learned that TXIFG is
set
> > > >> when TXBUF is loaded into the shift register, then the 8 bits are
> > > >> clocked out and (at the same time) 8 bits are clocked in and after
that
> > > >> RXIFG is set.
> > > >>
> > > >> In both serial engines (USART and USCI) there are always 2 registers
-
> > > >> one buffer for the character (TXBUF) and the (invisible) shift
> > > >> register. The transfer from TXBUF to the shift register will wait,
> > > >> until the shift out has been finished (double buffering).
> > > >>
> > > >> M.
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > > ------------ --------- --------- ------
> > > >
> > > >
> > > >
> > > >
Reply by mm bb●April 1, 20092009-04-01
Michael: Thanks for your patient answer, the thing is now working properly, as
you stated the Rx flag set=1 means that all bits in the shift register were
transferred because RX buffer has receive a complete character .I was confused
because I Think that the RX and TX were set at the same time, but this is wrong
because the shift register is in the middle.
With this concept in mind I arranged the program like this and its work fine.
The zero was just for a prove.
UCB0IFG &= ~UCRXIFG;
UCB0TXBUF = value; // Send value
while (!(UCB0IFG&UCRXIFG) ); // USCI_B0 RX buffer ready?
// while (!(UCB0STAT& UCBUSY));
________________________________
De: tintronic
Para: m...
Enviado: micoles 1 de abril de 2009, 16:26:37
Asunto: [msp430] Re: Spi simple question
The first problem is it seams you don't understand what the TX flag
indicates:
0: means the TX buffer is full
1: means the TX buffer is empty. There may still be data in the shift
register.
You need to check for the RX flag to know if the byte transmission has finished,
not the TX flag. But that will only work for 1 byte.
The TX falg goes from 0 to 1 when the byte is transferred to the shift register.
After that the SPI clock starts and the byte is shifted out. You are deselecting
the slave right after the shift register has been loaded with the byte from
TXBUF and is starting to be shifted out.
Seriously, changing RX for TX and hoping it will somehow work is not the
answer.
I think the problem is that you're not posting the complete routine. Since
RX should have worked, I'm guessing a transfer is already in progress when
you write 'value' into UCBOTXBUF. So, when you see UCRXIFG going up to
one, it is because the previous byte has been sent and not the last one. Try the
following, just to see if that is the reason. And please don't ever use
register=0 to clear a single flag, or else you're asking for headaches.
But anyway, you're using the USCI module, right? The why don't you use
the UCBUSY flag to know when the SPI has finished all transmissions? That is
what you should look at before deselecting #CS.
The RX flag is only used in the USART module because there is no flag that
indicates if the SPI has finished transmission (TXEPT flag seams to have been a
failed attempt at that).
Let us know how it goes.
Michael K.
--- In msp430@yahoogroups. com, mm bb wrote: >
> I will try to be more clear, but you get the problem, is exactly what you
undestand.
> I also try this way
>
> UCB0IFG=0;
> UCB0TXBUF = value; // Send value
> while (!(UCB0IFG&UCTXIFG) ); // USCI_B0 TX buffer ready?
>
> // TI_CC_Wait(10) ;
> TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
> }
>
> but it does not work, there were four clockpulses losted after the spi was
disable if I look for the RX flag and only two lost if I wait for TX .
> What Im missing?
>
> In anotherserie f2 we use this scheme and works fine
>
> while (!(IFG2&UCB0RXIFG) ); // Wait for TX to finish
> IFG2 &= ~UCB0RXIFG; // Clear flag
> UCB0TXBUF = value; // Send data
> while (!(IFG2&UCB0RXIFG) ); // Wait for TX to finish
>
> TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
>
>
>
>
>
> ____________ _________ _________ __
> De: tintronic
> Para: msp430@yahoogroups. com
> Enviado: micoles 1 de abril de 2009, 13:48:34
> Asunto: [msp430] Re: Spi simple question
>
>
> Ok, I'm not sure what your problem is, either you didn't explain it
well or you have no idea what you are doing.
> Obviously, you need to wait for the byte to be transferred completely (plus
the delay your slave specifies after the last SPI clock edge) before disabling
the slave, right? So you can't disable #CS right after writing to the
buffer, which means you can't just delete TI_CC_Wait() ;
>
> Your code only writes one byte, so I'll assume that you're not
trying to send more than one byte.
> One way do to know if the transmission has finished is by means of the RXIFG.
But you have to clear RXIFG by software before sending the byte. Then you write
to TX buffer and wait for RXIFG to set, after which you wait for the appropiate
time (it might be less than an MSP instruction cycle) and disable #CS.
>
> Did you search this forum? This has been wiiiidely discussed before.
>
> Michael K.
>
> --- In msp430@yahoogroups. com, mm bb wrote:
> >
> > Thanks for the answer , but I want to show you where there is a
problem with the spi. Im using the msp430t5438, which has some difference
with respect to the other series in employing the flags. I use this
routine to send data
> >
> >
> > while (!(UCB0IFG&UCTXIFG) ); // USCI_B0 TX buffer ready?
> > UCB0TXBUF = value; // Send value
> >
> > TI_CC_Wait(10) ; // this should not be here!!!!!!
> >
> >TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
> >
> > The problem is, if I don'tt use the delay, the clock and data are still
running.( I saw in the oscilloscope)
> > when the spi is disable by the next instruction. This way it work, but I do
not understand where is the problem, I have tried also using the RX flag but it
is the same.
> > This in place of delay :
> > while (!(UCB0IFG&UCRXIFG) );
> > Any ideas will be welcome, excuse my English#65533;
> >
> >
> >
> > ____________ _________ _________ __
> > De: Matthias Weingart
> > Para: msp430@yahoogroups. com
> > Enviado: miércoles 1 de abril de 2009, 7:47:59
> > Asunto: [msp430] Re: Spi simple question
> >
> >
> > Hi Michael,
> >
> > I have used TXEPT for RS232 asynchronous transfers only. I think using the
> > RXIFG for SPI is a good idea, nothing to say against this. I also use only
> > RXIFG for SPI. (In that case you can ignore TXIFG completely.)
> >
> > M.
> >
> > "tintronic" :
> >
> > > Thanks Matthias for answering, as I would like to dig more into this
> > > issue. First, I was wrong about the USCI. I was remembering a block
> > > diagram which I couldn't find now. USCI does have double buffering.
And
> > > it has a UCBUSY flag which is much more useful and makes a lot more
> > > sense than the TXEPT flag, which by the way USCI doesn't have.
> > >
> > > On the USART matter, I'm not mixing the flags, I know what each
one
> > > does. BUT, TI's datasheets don't provide any diagram where you
can see
> > > TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> > > Actually, there is no timing of EPT whatsoever, only a brief
description
> > > stating that it sets when the shift register is empty, but when exactly
> > > is that? That's where the guessing and asumptions start. Making
> > > assumptions, that's a receipe for disaster.
> > >
> > > Have you ever used EPT flag for deselecting the SPI slave? I have done
> > > so without luck. So have other people on the forum (many more were
> > > wrongly using TX flag). They had to put a delay after EPT or the slave
> > > wouldn't recognize the last byte. Even TI's sample codes (CC1100
for
> > > example) don't use EPT flag for deselecting the slave on SPI burst
> > > writes, instead they use the RX flag. Since I very often use more than
> > > one SPI slave on the same bus, my codes always deselect the devices
> > > after transfer completion.
> > >
> > > And yes, I know one has to check the timing parameters of the slave to
> > > know how much time after the last SPI clock edge one has to wait before
> > > deselecting the device for it to accept the full byte. I have respected
> > > all the timing parameters (hell, the time on some devices is shorter
> > > than one 8MHz clock cycle) and still I have had to use RX flag because
> > > EPT wouldn't work.
> > >
> > > All of the above leads me to think the EPT flag sets as soon as the
last
> > > transmitted bit is present at the MOSI pin, which effectively empties
> > > the shift register, before the following clock edge which is when the
> > > slave captures the MOSI pin value. I still might be wrong, as I
haven't
> > > used EPT ever again, but based on my above observations, I can't
> > > conclude anything else. I mean, why the hell wouldn't TI publish
the
> > > timing diagram of TXEPT or at least include it on the timing diagram of
> > > the SPI transfer?
> > >
> > > I've made drivers for various SPI and SPI-like devices, all using the
RX
> > > flag, so any new SPI devices I just recycle code from another device.
> > > I've not dealt with EPT ever again, I've got some ideas on how
to really
> > > know when EPT sets, but just haven't got the time right now to test
it.
> > > It would be as simple as using an external clock source like a
> > > (filtered) push button, or a very slow SPI clock, and a couple of leds
> > > that permanently show the status of the TX, RX and EPT flags and the
> > > MOSI and CLK pins.
> > >
> > > Best Regards,
> > > Michael K.
> > >
> > > --- In msp430@yahoogroups. com, Matthias Weingart wrote:
> > >>
> > >> "tintronic" :
> > >>
> > >> > On the MSP, the USART TX flag doesn't indicate that the
transmission
> > >> > has finished, it only indicates that the TX buffer is empty. There
> > >> > still might be bits in the shift register that are being sent. For
> > >> > that matter, neither does TXEPT flag, which indicates that the shift
> > >> > register is empty, because it (seams to) sets as soon as the last
bit
> > >> > in the shift register hits the output pin, which is half a clock
> > >> > cycle before the clock edge on which the (spi) slave capturates the
> > >> > data bit. So, you need to use the RX flag, which is tricky when you
> > >> > try to take advantage of the "double buffering" (one byte for
> > >> > shifting out and another one to store the next byte) sending
multiple
> > >> > bytes in a row. Tricky, because RX falg will set when the second
last
> > >> > byte written to the TXBUFFER has been received by the slave. And
this
> > >> > won't work if the function can be interrupted, because you could
miss
> > >> > an RX flag and the function would get stuck. I guess one could use a
> > >> > combination of TXEPT and reading the clock pin value. It should
work,
> > >> > but I haven't tried it. I any case, I haven't found a single
use for
> > >> > TXEPT flag. I think I've asked before and gotten no answers, but
if
> > >> > anyone has an idea of what TXEPT could be used for, please enlighten
> > >> > me.
> > >>
> > >> I might be wrong but I think you are mixing the meaning of two flags.
> > >> TXIFG is set once the TXBUF is loaded into the shift register (like
> > >> your description) . After that the shift register clocks 8 bits out of
> > >> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
> > >> TXEPT is set at the same time as RXIFG.
> > >> I have used TXEPT to wait until the last character has shifted out
> > >> completely. Only after that it is allowed to set LPM3 (because with
> > >> LPM3 the UART clock will be stopped also in some cases).
> > >>
> > >> > I might be wrong, but I think the USCI hasn't this problem,
basically
> > >> > because it doesn't have a transmit buffer, just a single shift
> > >> > register that's used for both transmitting and receiving data,
in
> > >> > which case probably both Rx and TX flag will work the same in SPI
> > >> > master mode.
> > >>
> > >> No. Just got USCI and DMA working and I have learned that TXIFG is set
> > >> when TXBUF is loaded into the shift register, then the 8 bits are
> > >> clocked out and (at the same time) 8 bits are clocked in and after
that
> > >> RXIFG is set.
> > >>
> > >> In both serial engines (USART and USCI) there are always 2 registers -
> > >> one buffer for the character (TXBUF) and the (invisible) shift
> > >> register. The transfer from TXBUF to the shift register will wait,
> > >> until the shift out has been finished (double buffering).
> > >>
> > >> M.
> > >>
> > >
> > >
> > >
> > >
> > > ------------ --------- --------- ------
> > >
> > >
> > >
> > >
Reply by tintronic●April 1, 20092009-04-01
The first problem is it seams you don't understand what the TX flag
indicates:
0: means the TX buffer is full
1: means the TX buffer is empty. There may still be data in the shift
register.
You need to check for the RX flag to know if the byte transmission has finished,
not the TX flag. But that will only work for 1 byte.
The TX falg goes from 0 to 1 when the byte is transferred to the shift register.
After that the SPI clock starts and the byte is shifted out. You are deselecting
the slave right after the shift register has been loaded with the byte from
TXBUF and is starting to be shifted out.
Seriously, changing RX for TX and hoping it will somehow work is not the
answer.
I think the problem is that you're not posting the complete routine. Since
RX should have worked, I'm guessing a transfer is already in progress when
you write 'value' into UCBOTXBUF. So, when you see UCRXIFG going up to
one, it is because the previous byte has been sent and not the last one. Try the
following, just to see if that is the reason. And please don't ever use
register=0 to clear a single flag, or else you're asking for headaches.
But anyway, you're using the USCI module, right? The why don't you use
the UCBUSY flag to know when the SPI has finished all transmissions? That is
what you should look at before deselecting #CS.
The RX flag is only used in the USART module because there is no flag that
indicates if the SPI has finished transmission (TXEPT flag seams to have been a
failed attempt at that).
Let us know how it goes.
Michael K.
--- In m..., mm bb wrote: >
> I will try to be more clear, but you get the problem, is exactly what you
undestand.
> I also try this way
>
> UCB0IFG=0;
> UCB0TXBUF = value; // Send value
> while (!(UCB0IFG&UCTXIFG)); // USCI_B0 TX buffer ready?
>
> // TI_CC_Wait(10);
> TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
> }
>
> but it does not work, there were four clockpulses losted after the spi was
disable if I look for the RX flag and only two lost if I wait for TX .
> What Im missing?
>
> In anotherserie f2 we use this scheme and works fine
>
> while (!(IFG2&UCB0RXIFG)); // Wait for TX to finish
> IFG2 &= ~UCB0RXIFG; // Clear flag
> UCB0TXBUF = value; // Send data
> while (!(IFG2&UCB0RXIFG)); // Wait for TX to finish
>
> TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
>
>
>
>
>
> ________________________________
> De: tintronic
> Para: m...
> Enviado: micoles 1 de abril de 2009, 13:48:34
> Asunto: [msp430] Re: Spi simple question
>
>
> Ok, I'm not sure what your problem is, either you didn't explain it
well or you have no idea what you are doing.
> Obviously, you need to wait for the byte to be transferred completely (plus
the delay your slave specifies after the last SPI clock edge) before disabling
the slave, right? So you can't disable #CS right after writing to the
buffer, which means you can't just delete TI_CC_Wait() ;
>
> Your code only writes one byte, so I'll assume that you're not
trying to send more than one byte.
> One way do to know if the transmission has finished is by means of the RXIFG.
But you have to clear RXIFG by software before sending the byte. Then you write
to TX buffer and wait for RXIFG to set, after which you wait for the appropiate
time (it might be less than an MSP instruction cycle) and disable #CS.
>
> Did you search this forum? This has been wiiiidely discussed before.
>
> Michael K.
>
> --- In msp430@yahoogroups. com, mm bb wrote:
> >
> > Thanks for the answer , but I want to show you where there is a
problem with the spi. Im using the msp430t5438, which has some difference
with respect to the other series in employing the flags. I use this
routine to send data
> >
> >
> > while (!(UCB0IFG&UCTXIFG) ); // USCI_B0 TX buffer ready?
> > UCB0TXBUF = value; // Send value
> >
> > TI_CC_Wait(10) ; // this should not be here!!!!!!
> >
> >TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
> >
> > The problem is, if I don'tt use the delay, the clock and data are still
running.( I saw in the oscilloscope)
> > when the spi is disable by the next instruction. This way it work, but I do
not understand where is the problem, I have tried also using the RX flag but it
is the same.
> > This in place of delay :
> > while (!(UCB0IFG&UCRXIFG) );
> > Any ideas will be welcome, excuse my English#65533;
> >
> >
> >
> > ____________ _________ _________ __
> > De: Matthias Weingart
> > Para: msp430@yahoogroups. com
> > Enviado: miércoles 1 de abril de 2009, 7:47:59
> > Asunto: [msp430] Re: Spi simple question
> >
> >
> > Hi Michael,
> >
> > I have used TXEPT for RS232 asynchronous transfers only. I think using the
> > RXIFG for SPI is a good idea, nothing to say against this. I also use only
> > RXIFG for SPI. (In that case you can ignore TXIFG completely.)
> >
> > M.
> >
> > "tintronic" :
> >
> > > Thanks Matthias for answering, as I would like to dig more into this
> > > issue. First, I was wrong about the USCI. I was remembering a block
> > > diagram which I couldn't find now. USCI does have double buffering.
And
> > > it has a UCBUSY flag which is much more useful and makes a lot more
> > > sense than the TXEPT flag, which by the way USCI doesn't have.
> > >
> > > On the USART matter, I'm not mixing the flags, I know what each
one
> > > does. BUT, TI's datasheets don't provide any diagram where you
can see
> > > TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> > > Actually, there is no timing of EPT whatsoever, only a brief
description
> > > stating that it sets when the shift register is empty, but when exactly
> > > is that? That's where the guessing and asumptions start. Making
> > > assumptions, that's a receipe for disaster.
> > >
> > > Have you ever used EPT flag for deselecting the SPI slave? I have done
> > > so without luck. So have other people on the forum (many more were
> > > wrongly using TX flag). They had to put a delay after EPT or the slave
> > > wouldn't recognize the last byte. Even TI's sample codes (CC1100
for
> > > example) don't use EPT flag for deselecting the slave on SPI burst
> > > writes, instead they use the RX flag. Since I very often use more than
> > > one SPI slave on the same bus, my codes always deselect the devices
> > > after transfer completion.
> > >
> > > And yes, I know one has to check the timing parameters of the slave to
> > > know how much time after the last SPI clock edge one has to wait before
> > > deselecting the device for it to accept the full byte. I have respected
> > > all the timing parameters (hell, the time on some devices is shorter
> > > than one 8MHz clock cycle) and still I have had to use RX flag because
> > > EPT wouldn't work.
> > >
> > > All of the above leads me to think the EPT flag sets as soon as the
last
> > > transmitted bit is present at the MOSI pin, which effectively empties
> > > the shift register, before the following clock edge which is when the
> > > slave captures the MOSI pin value. I still might be wrong, as I
haven't
> > > used EPT ever again, but based on my above observations, I can't
> > > conclude anything else. I mean, why the hell wouldn't TI publish
the
> > > timing diagram of TXEPT or at least include it on the timing diagram of
> > > the SPI transfer?
> > >
> > > I've made drivers for various SPI and SPI-like devices, all using the
RX
> > > flag, so any new SPI devices I just recycle code from another device.
> > > I've not dealt with EPT ever again, I've got some ideas on how
to really
> > > know when EPT sets, but just haven't got the time right now to test
it.
> > > It would be as simple as using an external clock source like a
> > > (filtered) push button, or a very slow SPI clock, and a couple of leds
> > > that permanently show the status of the TX, RX and EPT flags and the
> > > MOSI and CLK pins.
> > >
> > > Best Regards,
> > > Michael K.
> > >
> > > --- In msp430@yahoogroups. com, Matthias Weingart wrote:
> > >>
> > >> "tintronic" :
> > >>
> > >> > On the MSP, the USART TX flag doesn't indicate that the
transmission
> > >> > has finished, it only indicates that the TX buffer is empty. There
> > >> > still might be bits in the shift register that are being sent. For
> > >> > that matter, neither does TXEPT flag, which indicates that the shift
> > >> > register is empty, because it (seams to) sets as soon as the last
bit
> > >> > in the shift register hits the output pin, which is half a clock
> > >> > cycle before the clock edge on which the (spi) slave capturates the
> > >> > data bit. So, you need to use the RX flag, which is tricky when you
> > >> > try to take advantage of the "double buffering" (one byte for
> > >> > shifting out and another one to store the next byte) sending
multiple
> > >> > bytes in a row. Tricky, because RX falg will set when the second
last
> > >> > byte written to the TXBUFFER has been received by the slave. And
this
> > >> > won't work if the function can be interrupted, because you could
miss
> > >> > an RX flag and the function would get stuck. I guess one could use a
> > >> > combination of TXEPT and reading the clock pin value. It should
work,
> > >> > but I haven't tried it. I any case, I haven't found a single
use for
> > >> > TXEPT flag. I think I've asked before and gotten no answers, but
if
> > >> > anyone has an idea of what TXEPT could be used for, please enlighten
> > >> > me.
> > >>
> > >> I might be wrong but I think you are mixing the meaning of two flags.
> > >> TXIFG is set once the TXBUF is loaded into the shift register (like
> > >> your description) . After that the shift register clocks 8 bits out of
> > >> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
> > >> TXEPT is set at the same time as RXIFG.
> > >> I have used TXEPT to wait until the last character has shifted out
> > >> completely. Only after that it is allowed to set LPM3 (because with
> > >> LPM3 the UART clock will be stopped also in some cases).
> > >>
> > >> > I might be wrong, but I think the USCI hasn't this problem,
basically
> > >> > because it doesn't have a transmit buffer, just a single shift
> > >> > register that's used for both transmitting and receiving data,
in
> > >> > which case probably both Rx and TX flag will work the same in SPI
> > >> > master mode.
> > >>
> > >> No. Just got USCI and DMA working and I have learned that TXIFG is set
> > >> when TXBUF is loaded into the shift register, then the 8 bits are
> > >> clocked out and (at the same time) 8 bits are clocked in and after
that
> > >> RXIFG is set.
> > >>
> > >> In both serial engines (USART and USCI) there are always 2 registers -
> > >> one buffer for the character (TXBUF) and the (invisible) shift
> > >> register. The transfer from TXBUF to the shift register will wait,
> > >> until the shift out has been finished (double buffering).
> > >>
> > >> M.
> > >>
> > >
> > >
> > >
> > >
> > > ------------ --------- --------- ------
> > >
> > >
> > >
> > >
Reply by mm bb●April 1, 20092009-04-01
I will try to be more clear, but you get the problem, is exactly what you
undestand.
I also try this way
UCB0IFG=0;
UCB0TXBUF = value; // Send value
while (!(UCB0IFG&UCTXIFG)); // USCI_B0 TX buffer ready?
but it does not work, there were four clockpulses losted after the spi was
disable if I look for the RX flag and only two lost if I wait for TX .
What Im missing?
In anotherserie f2 we use this scheme and works fine
while (!(IFG2&UCB0RXIFG)); // Wait for TX to finish
IFG2 &= ~UCB0RXIFG; // Clear flag
UCB0TXBUF = value; // Send data
while (!(IFG2&UCB0RXIFG)); // Wait for TX to finish
TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
________________________________
De: tintronic
Para: m...
Enviado: micoles 1 de abril de 2009, 13:48:34
Asunto: [msp430] Re: Spi simple question
Ok, I'm not sure what your problem is, either you didn't explain it
well or you have no idea what you are doing.
Obviously, you need to wait for the byte to be transferred completely (plus the
delay your slave specifies after the last SPI clock edge) before disabling the
slave, right? So you can't disable #CS right after writing to the buffer,
which means you can't just delete TI_CC_Wait() ;
Your code only writes one byte, so I'll assume that you're not trying
to send more than one byte.
One way do to know if the transmission has finished is by means of the RXIFG.
But you have to clear RXIFG by software before sending the byte. Then you write
to TX buffer and wait for RXIFG to set, after which you wait for the appropiate
time (it might be less than an MSP instruction cycle) and disable #CS.
Did you search this forum? This has been wiiiidely discussed before.
Michael K.
--- In msp430@yahoogroups. com, mm bb wrote: >
> Thanks for the answer , but I want to show you where there is a
problem with the spi. Im using the msp430t5438, which has some difference
with respect to the other series in employing the flags. I use this
routine to send data
>
>
> while (!(UCB0IFG&UCTXIFG) ); // USCI_B0 TX buffer ready?
> UCB0TXBUF = value; // Send value
>
> TI_CC_Wait(10) ; // this should not be here!!!!!!
>
>TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN; // /CS disable
>
> The problem is, if I don'tt use the delay, the clock and data are still
running.( I saw in the oscilloscope)
> when the spi is disable by the next instruction. This way it work, but I do
not understand where is the problem, I have tried also using the RX flag but it
is the same.
> This in place of delay :
> while (!(UCB0IFG&UCRXIFG) );
> Any ideas will be welcome, excuse my English#65533;
>
>
>
> ____________ _________ _________ __
> De: Matthias Weingart
> Para: msp430@yahoogroups. com
> Enviado: miércoles 1 de abril de 2009, 7:47:59
> Asunto: [msp430] Re: Spi simple question
>
>
> Hi Michael,
>
> I have used TXEPT for RS232 asynchronous transfers only. I think using the
> RXIFG for SPI is a good idea, nothing to say against this. I also use only
> RXIFG for SPI. (In that case you can ignore TXIFG completely.)
>
> M.
>
> "tintronic" :
>
> > Thanks Matthias for answering, as I would like to dig more into this
> > issue. First, I was wrong about the USCI. I was remembering a block
> > diagram which I couldn't find now. USCI does have double buffering.
And
> > it has a UCBUSY flag which is much more useful and makes a lot more
> > sense than the TXEPT flag, which by the way USCI doesn't have.
> >
> > On the USART matter, I'm not mixing the flags, I know what each one
> > does. BUT, TI's datasheets don't provide any diagram where you can
see
> > TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> > Actually, there is no timing of EPT whatsoever, only a brief description
> > stating that it sets when the shift register is empty, but when exactly
> > is that? That's where the guessing and asumptions start. Making
> > assumptions, that's a receipe for disaster.
> >
> > Have you ever used EPT flag for deselecting the SPI slave? I have done
> > so without luck. So have other people on the forum (many more were
> > wrongly using TX flag). They had to put a delay after EPT or the slave
> > wouldn't recognize the last byte. Even TI's sample codes (CC1100
for
> > example) don't use EPT flag for deselecting the slave on SPI burst
> > writes, instead they use the RX flag. Since I very often use more than
> > one SPI slave on the same bus, my codes always deselect the devices
> > after transfer completion.
> >
> > And yes, I know one has to check the timing parameters of the slave to
> > know how much time after the last SPI clock edge one has to wait before
> > deselecting the device for it to accept the full byte. I have respected
> > all the timing parameters (hell, the time on some devices is shorter
> > than one 8MHz clock cycle) and still I have had to use RX flag because
> > EPT wouldn't work.
> >
> > All of the above leads me to think the EPT flag sets as soon as the last
> > transmitted bit is present at the MOSI pin, which effectively empties
> > the shift register, before the following clock edge which is when the
> > slave captures the MOSI pin value. I still might be wrong, as I
haven't
> > used EPT ever again, but based on my above observations, I can't
> > conclude anything else. I mean, why the hell wouldn't TI publish the
> > timing diagram of TXEPT or at least include it on the timing diagram of
> > the SPI transfer?
> >
> > I've made drivers for various SPI and SPI-like devices, all using the
RX
> > flag, so any new SPI devices I just recycle code from another device.
> > I've not dealt with EPT ever again, I've got some ideas on how to
really
> > know when EPT sets, but just haven't got the time right now to test
it.
> > It would be as simple as using an external clock source like a
> > (filtered) push button, or a very slow SPI clock, and a couple of leds
> > that permanently show the status of the TX, RX and EPT flags and the
> > MOSI and CLK pins.
> >
> > Best Regards,
> > Michael K.
> >
> > --- In msp430@yahoogroups. com, Matthias Weingart wrote:
> >>
> >> "tintronic" :
> >>
> >> > On the MSP, the USART TX flag doesn't indicate that the
transmission
> >> > has finished, it only indicates that the TX buffer is empty. There
> >> > still might be bits in the shift register that are being sent. For
> >> > that matter, neither does TXEPT flag, which indicates that the shift
> >> > register is empty, because it (seams to) sets as soon as the last bit
> >> > in the shift register hits the output pin, which is half a clock
> >> > cycle before the clock edge on which the (spi) slave capturates the
> >> > data bit. So, you need to use the RX flag, which is tricky when you
> >> > try to take advantage of the "double buffering" (one byte for
> >> > shifting out and another one to store the next byte) sending multiple
> >> > bytes in a row. Tricky, because RX falg will set when the second last
> >> > byte written to the TXBUFFER has been received by the slave. And this
> >> > won't work if the function can be interrupted, because you could
miss
> >> > an RX flag and the function would get stuck. I guess one could use a
> >> > combination of TXEPT and reading the clock pin value. It should work,
> >> > but I haven't tried it. I any case, I haven't found a single
use for
> >> > TXEPT flag. I think I've asked before and gotten no answers, but
if
> >> > anyone has an idea of what TXEPT could be used for, please enlighten
> >> > me.
> >>
> >> I might be wrong but I think you are mixing the meaning of two flags.
> >> TXIFG is set once the TXBUF is loaded into the shift register (like
> >> your description) . After that the shift register clocks 8 bits out of
> >> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
> >> TXEPT is set at the same time as RXIFG.
> >> I have used TXEPT to wait until the last character has shifted out
> >> completely. Only after that it is allowed to set LPM3 (because with
> >> LPM3 the UART clock will be stopped also in some cases).
> >>
> >> > I might be wrong, but I think the USCI hasn't this problem,
basically
> >> > because it doesn't have a transmit buffer, just a single shift
> >> > register that's used for both transmitting and receiving data, in
> >> > which case probably both Rx and TX flag will work the same in SPI
> >> > master mode.
> >>
> >> No. Just got USCI and DMA working and I have learned that TXIFG is set
> >> when TXBUF is loaded into the shift register, then the 8 bits are
> >> clocked out and (at the same time) 8 bits are clocked in and after that
> >> RXIFG is set.
> >>
> >> In both serial engines (USART and USCI) there are always 2 registers -
> >> one buffer for the character (TXBUF) and the (invisible) shift
> >> register. The transfer from TXBUF to the shift register will wait,
> >> until the shift out has been finished (double buffering).
> >>
> >> M.
> >>
> >
> >
> >
> >
> > ------------ --------- --------- ------
> >
> >
> >
> >
Reply by tintronic●April 1, 20092009-04-01
Ok, I'm not sure what your problem is, either you didn't explain it
well or you have no idea what you are doing.
Obviously, you need to wait for the byte to be transferred completely (plus the
delay your slave specifies after the last SPI clock edge) before disabling the
slave, right? So you can't disable #CS right after writing to the buffer,
which means you can't just delete TI_CC_Wait();
Your code only writes one byte, so I'll assume that you're not trying
to send more than one byte.
One way do to know if the transmission has finished is by means of the RXIFG.
But you have to clear RXIFG by software before sending the byte. Then you write
to TX buffer and wait for RXIFG to set, after which you wait for the appropiate
time (it might be less than an MSP instruction cycle) and disable #CS.
Did you search this forum? This has been wiiiidely discussed before.
Michael K.
--- In m..., mm bb wrote: >
> Thanks for the answer , but I want to show you where there is a
problem with the spi. Im using the msp430t5438, which has some difference
with respect to the other series in employing the flags. I use this
routine to send data
>
>
> while (!(UCB0IFG&UCTXIFG)); // USCI_B0 TX buffer ready?
> UCB0TXBUF = value; // Send value
>
> TI_CC_Wait(10); // this should not be here!!!!!!
>
>TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN;// /CS disable
>
> The problem is, if I don'tt use the delay, the clock and data are still
running.( I saw in the oscilloscope)
> when the spi is disable by the next instruction. This way it work, but I do
not understand where is the problem, I have tried also using the RX flag but it
is the same.
> This in place of delay :
> while (!(UCB0IFG&UCRXIFG));
> Any ideas will be welcome, excuse my English#65533;
>
>
>
> ________________________________
> De: Matthias Weingart
> Para: m...
> Enviado: miércoles 1 de abril de 2009, 7:47:59
> Asunto: [msp430] Re: Spi simple question
>
>
> Hi Michael,
>
> I have used TXEPT for RS232 asynchronous transfers only. I think using the
> RXIFG for SPI is a good idea, nothing to say against this. I also use only
> RXIFG for SPI. (In that case you can ignore TXIFG completely.)
>
> M.
>
> "tintronic" :
>
> > Thanks Matthias for answering, as I would like to dig more into this
> > issue. First, I was wrong about the USCI. I was remembering a block
> > diagram which I couldn't find now. USCI does have double buffering.
And
> > it has a UCBUSY flag which is much more useful and makes a lot more
> > sense than the TXEPT flag, which by the way USCI doesn't have.
> >
> > On the USART matter, I'm not mixing the flags, I know what each one
> > does. BUT, TI's datasheets don't provide any diagram where you can
see
> > TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> > Actually, there is no timing of EPT whatsoever, only a brief description
> > stating that it sets when the shift register is empty, but when exactly
> > is that? That's where the guessing and asumptions start. Making
> > assumptions, that's a receipe for disaster.
> >
> > Have you ever used EPT flag for deselecting the SPI slave? I have done
> > so without luck. So have other people on the forum (many more were
> > wrongly using TX flag). They had to put a delay after EPT or the slave
> > wouldn't recognize the last byte. Even TI's sample codes (CC1100
for
> > example) don't use EPT flag for deselecting the slave on SPI burst
> > writes, instead they use the RX flag. Since I very often use more than
> > one SPI slave on the same bus, my codes always deselect the devices
> > after transfer completion.
> >
> > And yes, I know one has to check the timing parameters of the slave to
> > know how much time after the last SPI clock edge one has to wait before
> > deselecting the device for it to accept the full byte. I have respected
> > all the timing parameters (hell, the time on some devices is shorter
> > than one 8MHz clock cycle) and still I have had to use RX flag because
> > EPT wouldn't work.
> >
> > All of the above leads me to think the EPT flag sets as soon as the last
> > transmitted bit is present at the MOSI pin, which effectively empties
> > the shift register, before the following clock edge which is when the
> > slave captures the MOSI pin value. I still might be wrong, as I
haven't
> > used EPT ever again, but based on my above observations, I can't
> > conclude anything else. I mean, why the hell wouldn't TI publish the
> > timing diagram of TXEPT or at least include it on the timing diagram of
> > the SPI transfer?
> >
> > I've made drivers for various SPI and SPI-like devices, all using the
RX
> > flag, so any new SPI devices I just recycle code from another device.
> > I've not dealt with EPT ever again, I've got some ideas on how to
really
> > know when EPT sets, but just haven't got the time right now to test
it.
> > It would be as simple as using an external clock source like a
> > (filtered) push button, or a very slow SPI clock, and a couple of leds
> > that permanently show the status of the TX, RX and EPT flags and the
> > MOSI and CLK pins.
> >
> > Best Regards,
> > Michael K.
> >
> > --- In msp430@yahoogroups. com, Matthias Weingart wrote:
> >>
> >> "tintronic" :
> >>
> >> > On the MSP, the USART TX flag doesn't indicate that the
transmission
> >> > has finished, it only indicates that the TX buffer is empty. There
> >> > still might be bits in the shift register that are being sent. For
> >> > that matter, neither does TXEPT flag, which indicates that the shift
> >> > register is empty, because it (seams to) sets as soon as the last bit
> >> > in the shift register hits the output pin, which is half a clock
> >> > cycle before the clock edge on which the (spi) slave capturates the
> >> > data bit. So, you need to use the RX flag, which is tricky when you
> >> > try to take advantage of the "double buffering" (one byte for
> >> > shifting out and another one to store the next byte) sending multiple
> >> > bytes in a row. Tricky, because RX falg will set when the second last
> >> > byte written to the TXBUFFER has been received by the slave. And this
> >> > won't work if the function can be interrupted, because you could
miss
> >> > an RX flag and the function would get stuck. I guess one could use a
> >> > combination of TXEPT and reading the clock pin value. It should work,
> >> > but I haven't tried it. I any case, I haven't found a single
use for
> >> > TXEPT flag. I think I've asked before and gotten no answers, but
if
> >> > anyone has an idea of what TXEPT could be used for, please enlighten
> >> > me.
> >>
> >> I might be wrong but I think you are mixing the meaning of two flags.
> >> TXIFG is set once the TXBUF is loaded into the shift register (like
> >> your description) . After that the shift register clocks 8 bits out of
> >> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
> >> TXEPT is set at the same time as RXIFG.
> >> I have used TXEPT to wait until the last character has shifted out
> >> completely. Only after that it is allowed to set LPM3 (because with
> >> LPM3 the UART clock will be stopped also in some cases).
> >>
> >> > I might be wrong, but I think the USCI hasn't this problem,
basically
> >> > because it doesn't have a transmit buffer, just a single shift
> >> > register that's used for both transmitting and receiving data, in
> >> > which case probably both Rx and TX flag will work the same in SPI
> >> > master mode.
> >>
> >> No. Just got USCI and DMA working and I have learned that TXIFG is set
> >> when TXBUF is loaded into the shift register, then the 8 bits are
> >> clocked out and (at the same time) 8 bits are clocked in and after that
> >> RXIFG is set.
> >>
> >> In both serial engines (USART and USCI) there are always 2 registers -
> >> one buffer for the character (TXBUF) and the (invisible) shift
> >> register. The transfer from TXBUF to the shift register will wait,
> >> until the shift out has been finished (double buffering).
> >>
> >> M.
> >>
> >
> >
> >
> >
> > ------------ --------- --------- ------
> >
> >
> >
> >
Reply by mm bb●April 1, 20092009-04-01
Thanks for the answer , but I want to show you where there is a
problem with the spi. Im using the msp430t5438, which has some difference
with respect to the other series in employing the flags. I use this
routine to send data
while
(!(UCB0IFG&UCTXIFG));
// USCI_B0 TX buffer ready?
UCB0TXBUF =
value;
// Send value
TI_CC_Wait(10);
//
¡¡¡¡¡ this should not be here!!!!!!
TI_CC_CSn_PxOUT |=
TI_CC_CSn_PIN; // /CS disable
The problem is, if I don’t use the delay, the clock and data are
still running.( I saw in the oscilloscope)
when the spi is disable by the next instruction. This way it work, but I do not
understand where is the problem, I have tried also using the RX flag but it is
the same.
This in place of delay :
while (!(UCB0IFG&UCRXIFG));
Any ideas will be welcome, excuse my English…
________________________________
De: Matthias Weingart
Para: m...
Enviado: miércoles 1 de abril de 2009, 7:47:59
Asunto: [msp430] Re: Spi simple question
Hi Michael,
I have used TXEPT for RS232 asynchronous transfers only. I think using the
RXIFG for SPI is a good idea, nothing to say against this. I also use only
RXIFG for SPI. (In that case you can ignore TXIFG completely.)
M.
"tintronic" :
> Thanks Matthias for answering, as I would like to dig
more into this
> issue. First, I was wrong about the USCI. I was remembering a block
> diagram which I couldn't find now. USCI does have double buffering.
And
> it has a UCBUSY flag which is much more useful and makes a lot more
> sense than the TXEPT flag, which by the way USCI doesn't have.
>
> On the USART matter, I'm not mixing the flags, I know what each one
> does. BUT, TI's datasheets don't provide any diagram where you can
see
> TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> Actually, there is no timing of EPT whatsoever, only a brief description
> stating that it sets when the shift register is empty, but when exactly
> is that? That's where the guessing and asumptions start. Making
> assumptions, that's a receipe for disaster.
>
> Have you ever used EPT flag for deselecting the SPI slave? I have done
> so without luck. So have other people on the forum (many more were
> wrongly using TX flag). They had to put a delay after EPT or the slave
> wouldn't recognize the last byte. Even TI's sample codes (CC1100
for
> example) don't use EPT flag for deselecting the slave on SPI burst
> writes, instead they use the RX flag. Since I very often use more than
> one SPI slave on the same bus, my codes always deselect the devices
> after transfer completion.
>
> And yes, I know one has to check the timing parameters of the slave to
> know how much time after the last SPI clock edge one has to wait before
> deselecting the device for it to accept the full byte. I have respected
> all the timing parameters (hell, the time on some devices is shorter
> than one 8MHz clock cycle) and still I have had to use RX flag because
> EPT wouldn't work.
>
> All of the above leads me to think the EPT flag sets as soon as the last
> transmitted bit is present at the MOSI pin, which effectively empties
> the shift register, before the following clock edge which is when the
> slave captures the MOSI pin value. I still might be wrong, as I
haven't
> used EPT ever again, but based on my above observations, I can't
> conclude anything else. I mean, why the hell wouldn't TI publish the
> timing diagram of TXEPT or at least include it on the timing diagram of
> the SPI transfer?
>
> I've made drivers for various SPI and SPI-like devices, all using the
RX
> flag, so any new SPI devices I just recycle code from another device.
> I've not dealt with EPT ever again, I've got some ideas on how to
really
> know when EPT sets, but just haven't got the time right now to test
it.
> It would be as simple as using an external clock source like a
> (filtered) push button, or a very slow SPI clock, and a couple of leds
> that permanently show the status of the TX, RX and EPT flags and the
> MOSI and CLK pins.
>
> Best Regards,
> Michael K.
>
> --- In msp430@yahoogroups. com, Matthias Weingart wrote:
>>
>> "tintronic" :
>>
>> > On the MSP, the USART TX flag doesn't indicate that the
transmission
>> > has finished, it only indicates that the TX buffer is empty. There
>> > still might be bits in the shift register that are being sent. For
>> > that matter, neither does TXEPT flag, which indicates that the shift
>> > register is empty, because it (seams to) sets as soon as the last bit
>> > in the shift register hits the output pin, which is half a clock
>> > cycle before the clock edge on which the (spi) slave capturates the
>> > data bit. So, you need to use the RX flag, which is tricky when you
>> > try to take advantage of the "double buffering" (one byte for
>> > shifting out and another one to store the next byte) sending multiple
>> > bytes in a row. Tricky, because RX falg will set when the second last
>> > byte written to the TXBUFFER has been received by the slave. And this
>> > won't work if the function can be interrupted, because you could
miss
>> > an RX flag and the function would get stuck. I guess one could use a
>> > combination of TXEPT and reading the clock pin value. It should work,
>> > but I haven't tried it. I any case, I haven't found a single use
for
>> > TXEPT flag. I think I've asked before and gotten no answers, but if
>> > anyone has an idea of what TXEPT could be used for, please enlighten
>> > me.
>>
>> I might be wrong but I think you are mixing the meaning of two flags.
>> TXIFG is set once the TXBUF is loaded into the shift register (like
>> your description) . After that the shift register clocks 8 bits out of
>> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
>> TXEPT is set at the same time as RXIFG.
>> I have used TXEPT to wait until the last character has shifted out
>> completely. Only after that it is allowed to set LPM3 (because with
>> LPM3 the UART clock will be stopped also in some cases).
>>
>> > I might be wrong, but I think the USCI hasn't this problem,
basically
>> > because it doesn't have a transmit buffer, just a single shift
>> > register that's used for both transmitting and receiving data, in
>> > which case probably both Rx and TX flag will work the same in SPI
>> > master mode.
>>
>> No. Just got USCI and DMA working and I have learned that TXIFG is set
>> when TXBUF is loaded into the shift register, then the 8 bits are
>> clocked out and (at the same time) 8 bits are clocked in and after that
>> RXIFG is set.
>>
>> In both serial engines (USART and USCI) there are always 2 registers -
>> one buffer for the character (TXBUF) and the (invisible) shift
>> register. The transfer from TXBUF to the shift register will wait,
>> until the shift out has been finished (double buffering).
>>
>> M.
>>
>
>
>
>
> ------------ --------- --------- ------
>
>
>
>
Reply by Matthias Weingart●April 1, 20092009-04-01
Hi Michael,
I have used TXEPT for RS232 asynchronous transfers only. I think using the
RXIFG for SPI is a good idea, nothing to say against this. I also use only
RXIFG for SPI. (In that case you can ignore TXIFG completely.)
M.
"tintronic" :
> Thanks Matthias for answering, as I would like to dig
more into this
> issue. First, I was wrong about the USCI. I was remembering a block
> diagram which I couldn't find now. USCI does have double buffering.
And
> it has a UCBUSY flag which is much more useful and makes a lot more
> sense than the TXEPT flag, which by the way USCI doesn't have.
>
> On the USART matter, I'm not mixing the flags, I know what each one
> does. BUT, TI's datasheets don't provide any diagram where you can
see
> TX, RX and EPT flags behaviour concurrently during an SPI transfer.
> Actually, there is no timing of EPT whatsoever, only a brief description
> stating that it sets when the shift register is empty, but when exactly
> is that? That's where the guessing and asumptions start. Making
> assumptions, that's a receipe for disaster.
>
> Have you ever used EPT flag for deselecting the SPI slave? I have done
> so without luck. So have other people on the forum (many more were
> wrongly using TX flag). They had to put a delay after EPT or the slave
> wouldn't recognize the last byte. Even TI's sample codes (CC1100
for
> example) don't use EPT flag for deselecting the slave on SPI burst
> writes, instead they use the RX flag. Since I very often use more than
> one SPI slave on the same bus, my codes always deselect the devices
> after transfer completion.
>
> And yes, I know one has to check the timing parameters of the slave to
> know how much time after the last SPI clock edge one has to wait before
> deselecting the device for it to accept the full byte. I have respected
> all the timing parameters (hell, the time on some devices is shorter
> than one 8MHz clock cycle) and still I have had to use RX flag because
> EPT wouldn't work.
>
> All of the above leads me to think the EPT flag sets as soon as the last
> transmitted bit is present at the MOSI pin, which effectively empties
> the shift register, before the following clock edge which is when the
> slave captures the MOSI pin value. I still might be wrong, as I
haven't
> used EPT ever again, but based on my above observations, I can't
> conclude anything else. I mean, why the hell wouldn't TI publish the
> timing diagram of TXEPT or at least include it on the timing diagram of
> the SPI transfer?
>
> I've made drivers for various SPI and SPI-like devices, all using the
RX
> flag, so any new SPI devices I just recycle code from another device.
> I've not dealt with EPT ever again, I've got some ideas on how to
really
> know when EPT sets, but just haven't got the time right now to test
it.
> It would be as simple as using an external clock source like a
> (filtered) push button, or a very slow SPI clock, and a couple of leds
> that permanently show the status of the TX, RX and EPT flags and the
> MOSI and CLK pins.
>
> Best Regards,
> Michael K.
>
> --- In m..., Matthias Weingart wrote:
>>
>> "tintronic" :
>>
>> > On the MSP, the USART TX flag doesn't indicate that the
transmission
>> > has finished, it only indicates that the TX buffer is empty. There
>> > still might be bits in the shift register that are being sent. For
>> > that matter, neither does TXEPT flag, which indicates that the shift
>> > register is empty, because it (seams to) sets as soon as the last bit
>> > in the shift register hits the output pin, which is half a clock
>> > cycle before the clock edge on which the (spi) slave capturates the
>> > data bit. So, you need to use the RX flag, which is tricky when you
>> > try to take advantage of the "double buffering" (one byte for
>> > shifting out and another one to store the next byte) sending multiple
>> > bytes in a row. Tricky, because RX falg will set when the second last
>> > byte written to the TXBUFFER has been received by the slave. And this
>> > won't work if the function can be interrupted, because you could
miss
>> > an RX flag and the function would get stuck. I guess one could use a
>> > combination of TXEPT and reading the clock pin value. It should work,
>> > but I haven't tried it. I any case, I haven't found a single use
for
>> > TXEPT flag. I think I've asked before and gotten no answers, but if
>> > anyone has an idea of what TXEPT could be used for, please enlighten
>> > me.
>>
>> I might be wrong but I think you are mixing the meaning of two flags.
>> TXIFG is set once the TXBUF is loaded into the shift register (like
>> your description). After that the shift register clocks 8 bits out of
>> the TXD-Pin and when this is finished the TXEPT is set. For SPI master
>> TXEPT is set at the same time as RXIFG.
>> I have used TXEPT to wait until the last character has shifted out
>> completely. Only after that it is allowed to set LPM3 (because with
>> LPM3 the UART clock will be stopped also in some cases).
>>
>> > I might be wrong, but I think the USCI hasn't this problem,
basically
>> > because it doesn't have a transmit buffer, just a single shift
>> > register that's used for both transmitting and receiving data, in
>> > which case probably both Rx and TX flag will work the same in SPI
>> > master mode.
>>
>> No. Just got USCI and DMA working and I have learned that TXIFG is set
>> when TXBUF is loaded into the shift register, then the 8 bits are
>> clocked out and (at the same time) 8 bits are clocked in and after that
>> RXIFG is set.
>>
>> In both serial engines (USART and USCI) there are always 2 registers -
>> one buffer for the character (TXBUF) and the (invisible) shift
>> register. The transfer from TXBUF to the shift register will wait,
>> until the shift out has been finished (double buffering).
>>
>> M.
>>
>
