VictorLorenzo

Is anyone really using PE Generated SPI driver with MQXLite? How?

Discussion created by VictorLorenzo on May 20, 2013
Latest reply on Jan 7, 2014 by Marc Lindahl

Hi,

Sorry for such a post title, but that's simply how it came to my mind after being more than three days struggling with this and debugging it with one DSO.

 

We made a custom board based on the MK20DX256VLK100 kinetis microcontroller. Now I'm trying to use the SPI0 port to control some other device, something so simple that MQXLite functionalities are enough for my application. End of the easy and good part of the story.

 

The device I need to control requires CS to be kept asserted (LOW) for the entire transaction time (as usually happeds) so I tried the following solutions:

 

1) Configuring the chipselect list with one entry and properly indicating the CS output pin.

It seems to work if this conditions {1.a and {1.b-1 or 1.b-2} } apply:

1.a) Transactions in ONLY ONE DIRECTION (only read or only write)

1.b-1) Transactions with ONLY ONE CHAR, or

1.b-2) Transactions with VERY LONG DELAY BETWEEN CHARS.

 

As one interrupt is required for sending EACH and EVERY char to Tx FIFO, under some circumtances the delay introduced between one char and the next is greater that the Delay Between Chars PE Parameter so CS is automatically deasserted (Driven HIGH) by the silicon IP. And that is totally wrong!

 

When the transaction involved TX {n} chars and RX {m} chars... it was impossible to keep CS asserted, always was driven HIGH before being able to even start reading.

 

Here is a screen capture from the DSO: CS is Ch1, CK is Ch4 and MOSI is Ch3. This corresponds to one TX transaction, three bytes long.

TEK0004.JPG

 

2) Configuring the component without any chipselect output selected and driving it manually.

 

It seemed to work, but! When trusting in PE function ***_SPI_GetBlockSentStatus() it was also dissastrous. This funcion does not take into account the real Silicon IP state, but the driver's internal state. It reports that transmission was completed before data in TX FIFO was really streamed out.

 

Furthermore, things got worst when I tried to optimise performance and configured PE for taking advantage of TX/RX FIFO capacities. No need to say why.

 

My Questions:

What should do?

Should I just forget about that so famous Processor Expert and code a real driver myself?

Are there any other solutions out there?

How are you managing to use the SPI port?

 

Thanks a lot for your comments, Victor

Outcomes