SPI Slave Tx FIFO

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I'm hitting a wall getting 2-way communication going over SPI in slave mode.  I am trying to do a 2 byte write and a subsequent 2 byte read in the same transaction.  The port, pins, timing, etc. are all ok.  TX and RX buffers are enabled.  Timing wise, everything looks ok on the scope.  SDK 2.1.1

My transaction looks like this:

CS Assert

Master sets up tx buffer with 2 byte command.

slaveTxData(2 byte magic #)

slave->master FC

Master generates 16 clocks

Data is ok on both sides of the fence.

slaveTxData(2 byte response to command)

slave->master FC

Master setups up tx buffer with 0xffff for read

Master generates 16 clocks

CS Deassert

Master reads all 0's after second transaction.  I've played with just about everything I can think of -- adding delays, adding to fifo by byte, making sure there are two bytes in fifo before continuing, etc.  I am definitely writing the correct data into the fifo, it's just not coming out on the other end.

Is the TX fifo somehow latching onto the fact that it's empty?  Is there a limit on the number of transactions per CS?

EDIT

Just discovered something that might be revealing -- If I replace the second slaveTxData call with 2 individual slaveTxByte calls such as:

spiffyd_slaveTxByte(SPIFFYD_2, 0xAA);
spiffyd_slaveTxByte(SPIFFYD_2, 0xBB);

I receive 0x00 and 0xBB on the master side.  The Tx fifo never shows more than 2 bytes in it.

One other thing I should note - I am doing context switches back to the stack after each FC via the fine timer.

0 Likes
1 Solution

I spoke witht he developers about this today and they could not figure out what was wrong with your application based on the information provided.

They did provide the following guidance:

1.

Make sure the master and the slave use the same IO voltage.

2.

Within the SDK, refer to the /WICED-Smart-SDK/Apps/spi_comm_master and /WICED-Smart-SDK/Apps/spi_comm_slave examples as these are tested and have been designed to work with one another.

View solution in original post

0 Likes
7 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Have you verified that sleep is disabled during the transaction?

0 Likes
Anonymous
Not applicable

Yes, I thought that might be causing problems so I set my spi's lpm_query to always return 0.

Attached are some traces in case they might be useful:

Full transaction:

image5362.png

First 2 Bytes:

image3226.png

Second 2 Bytes:

image17419.png

0 Likes
Anonymous
Not applicable

I'm working around the issue by writing a dummy byte before my 2-byte write.  The 1st one is getting clobbered but the next two are ok.

While playing around I discovered that the dummy byte needed to be present after every master read of the tx fifo -- I can't just stuff it once and be done with it.  This makes me think that the Tx register has preloaded an empty byte when the fifo is empty and ignores any subsequently added data in the fifo until the empty byte is clocked out.  Some detail on how the rx and tx fifo's interact with the hardware will be helpful in figuring this out.

image32267.png

Master is writing 06 00 while reading B8 06

Master then reads a dummy 00 and then the correct 2-byte sequence 04 00

0 Likes

I wanted to let you know that we've created a case for the developers and will ask them to look into this one as well.

0 Likes

I spoke witht he developers about this today and they could not figure out what was wrong with your application based on the information provided.

They did provide the following guidance:

1.

Make sure the master and the slave use the same IO voltage.

2.

Within the SDK, refer to the /WICED-Smart-SDK/Apps/spi_comm_master and /WICED-Smart-SDK/Apps/spi_comm_slave examples as these are tested and have been designed to work with one another.

0 Likes
Anonymous
Not applicable

Jose, trying to understand your post, I am confused by the acronym FC.  What does it refer to?

0 Likes
Anonymous
Not applicable

FC = Flow Control

It's needed to prevent the fifo from overflowing.  See the referred master/slave code in the examples.

0 Likes