SPI Using DMA Sends Duplicate Bytes...

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

SPI Using DMA Sends Duplicate Bytes...

2,554 Views
icm
Contributor I

Hi,

I'm using a Kinetis KL14 and am trying to implement the Proessor Expert SPI interface as Master. The device I am connecting to requires multiple bytes to be transferred without raising the CS pin in between bytes; therefore I believe I have to use the SPI interface with DMA so it can keep up - tt seems to ALMOST work, but I have noticed some strange behaviour...

If I have the SPI clock rate set to 1MHz, and I attempt to send 12 bytes of data, it actually sends 13 (confirmed with oscilloscope) and it is the first byte that is repeated twice. The sent data count reads as 12, and send status reads as complete.

If, however, I have the clock rate set higher (e.g. 2MHz, 4Mhz) the same thing happens, HOWEVER only ever on the FIRST time.... repeated attempts will then always send the correct 12 bytes as expected. UNTIL I call the 'cancel transmission' function, at which point the problem resets; i.e. the first send is broken, subsequent sends work as expected.

There is a slightly cryptic note in the reference manual which seems vaguely relevant:

After DMA transfers the first byte to the SPI data register, the SPI pushes this data into

the shifter, thereby making SPTEF high again. This generates another DMA request

immediately, but the CPU lacks enough time to service the first DMA interrupt service

request (ISR). The subsequent DMA request is paced at the SPI transfer rate. Manage this

behavior during the first byte transfer through the DMA channel. Write the first byte to

the SPI data register via the CPU. The other bytes are transmitted by the DMA.

This seems to suggest that the first byte should be handled differently, although I can not see whether this is happening in the PE generated code. I have attempted to manually send the first byte, however this leaves a long gap between the first byte and those that follow it, which is not acceptable for my implementation.

I guess my question is: is there a known bug in the SPI DMA implementation, or am I just using it wrong? And if so, how do I implement a reasonably fast and reliable SPI Master interface....?

Any help would be much appreciated....

Ian

Tags (3)
0 Kudos
4 Replies

1,200 Views
joseplluismoral
Contributor II

Dear Ian

I had the same problem, I solved the repeated byte problem activating the spi FIFO  (SPI1_C3 0x01)  in kinetis MKWZ01 before transmit, this way i think that the SPI system can handle correctly the DMA transfer, in this example I perform a 264 bytes TX transmit from RAM buffer to SPI.

Hope will be helpful

0 Kudos

1,200 Views
Petr_H
NXP Employee
NXP Employee

Hi,

Could you provide some sample project showing the components settings and usage in code ?

Best regards

Petr Hradsky

Processor Expert Support Team

0 Kudos

1,200 Views
icm
Contributor I

As far as the code is concerned, I simply call the 'receive' and 'send' commands....

memset(spiWriteBuffer, 0, SPI_DATA_SIZE+2) ;
spiWriteBuffer[0] = 3 ; // Read command is 00000011
spiWriteBuffer[1] = tmpVal ; // Copy the SPI register address
   
// We don't need any more data for a read, so just start it
regData.status.spiStatus = SPI_STATUS_BUSY ;

if (ERR_OK != spiEth_ReceiveBlock(spiEth_DeviceData, spiReadBuffer, 10+2) )
{
regData.status.spiStatus = SPI_STATUS_READ_ERROR ;
}

if ( ERR_OK != spiEth_SendBlock(spiEth_DeviceData, spiWriteBuffer, 10+2) ) // Need to send data to get a response...
{
regData.status.spiStatus = SPI_STATUS_READ_ERROR ;
}

and use the "OnBlockReceived" function to handle the returned data.

I have attached a copy of the ProcessorExpert_Settings.xml for the SPI 'Bean' as I believe this shows all of the relevant settings....

Since my original post I have looked into the auto-generated code in more detail, and it does not seem to follow the recommended process in the reference manual (Figure 34-22). I have attempted to modify this code to follow the recommended steps with some limited success - i.e. I can force it to always send the correct number of bytes, however the behaviour of the first transfer is still different to all subsequent transfers, until the 'cancel' function is called, even though the process claims to complete properly (since the 'on block sent/received) functions are called.

Ian

0 Kudos

1,200 Views
Petr_H
NXP Employee
NXP Employee

Hi,

We are not aware of any issues with this, and we would need more details on reproducing the issue, a simplified project showing the settings with a sample code would be the best.

Could you be more specific on why the "auto-generated code" does not follow the reference manual?

Thank you.

Best regards

Petr Hradsky

Processor Expert Support Team

0 Kudos