Remark on SPI registers: TXDATCTL and TXCTL - bit EOT influences SCK to go idle

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Remark on SPI registers: TXDATCTL and TXCTL - bit EOT influences SCK to go idle

459 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by capiman on Tue Feb 19 07:04:34 MST 2013
I just tried SPI0 on LPC812. There is CPOL in CFG-Register. I have set it to 1. When enabling SPI0, SCK has the right level "high".
But after sending data, the SCK was not going back to right level (i had CPOL=1, it stayed "low").
After some tests i found out, that TXDATCTL and TXCTL have a bit called EOT (bit 20).
According to description in user manual of LPC800 (Rev. 1, from 12 November 2012 and also in rev 1.1 from 24 January 2013)
it only influences assertion/deassertion of SSEP. But in real life it also influences SCK going to idle.

@NXP: Perhaps a note for SCK can be added to the bit EOT in TXDATCTL and TXCTL in the next version of the User Manual of LPC800
Labels (1)
0 Kudos
3 Replies

396 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by okwh on Sat Dec 19 00:54:15 MST 2015
when I want to send 20 bits out. You send the first 16 bits in the first write to TXDATCTL without EOT.

code run faster than SPI,
so how to judge need to transfer the next 4bits ?

Is It possible:

first   send 16 bits  without EOT
and then send 4 bits  with EOT  ?

After 16bits, need to judge 16bits has sent, and set EOT,
after 4 bits,  DeSEEL occur .
0 Kudos

396 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by IanB on Wed Feb 04 04:20:07 MST 2015
Thanks for posting this two years ago, and indeed when I download the latest copy of the user manual there is the explanation!

I am recompiling software I'd written for the LPC1114 to the LPC812, and was a little annoyed to find out that the SPI ports work rather differently!
0 Kudos

396 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by noahk on Tue Feb 19 17:11:47 MST 2013
Hi capiman,

Thanks for catching this. Here is the reasoning for the behavior you are seeing:

In Mode 0 or 2 (CPOL = 0 or 1, CPHA = 0), the SPI protocol requires that at each rising edge new data be put out on MOSI. If you are performing a multi-transmit transfer, then the SPI block delays the final rising edge in order to wait for new data. If you set EOT, then the SPI block is able to complete the transfer, and so it performs the final rising edge and ends the transfer. You can tell when a stall occurs by reading the STALLED bit from the status register. Had you written new data to TXDATCTL before the SPI had put out the final bit of the last transmit, then you would not have seen this stall, as the SPI block would have been able to continue.

Consider the case where you want to send 20 bits out. You send the first 16 bits in the first write to TXDATCTL. At the 15th rising edge, the last bit of data of the first transmit is put out. At the 16th falling edge, that bit is read by the slave. If you had already written the final 4 bits into TXDATCTL, then the SPI block would continue with the 16th rising edge, where it would put out the first bit of the final four bits. But since you haven't written to TXDATCTL, the SPI block stalls. The SPI will now wait for a write of the final four bits. To abort without writing more data you can use the ENDTRANSFER bit of the STATUS register.

Noah
0 Kudos