AnsweredAssumed Answered

SPI issue on KSDK V1.2.0 (at least on FRDM-KL25Z board)

Question asked by Luca Ognibene on Oct 16, 2015
Latest reply on Jan 9, 2016 by Kewal Deshpande

Hello everybody!

 

I'm working on a project using the FRDM-KL25Z dev board and a CLEV663B Blue Board (with a NXP CLRC663 RFID transponder).

I configured the latter for an SPI connection.

All the development is done under KDS V3.0 and SDK V1.2.0, so the lastest available versions at this moment (AFAIK).

I setup/configured an SPI interface at driver level (DRV calls - speaking about KSDK): SPI clock, MISO, MOSI and Slave Select pins, bit rate 1MHz, polarity active high, phase on first edge, Msb first.

 

After two days struggling for make it work, I managed to find the problem.

Right at the beginning, after the first negative results, checking the SPI signals with an oscilloscope, revealed a glitch just before the SPI clock start (see Image_1.bmp).

Image_1.bmp

Yellow track: SPI clock

Violet track: MISO

Blue track: SPI slave select

 

But I didn't care that much since the SPI select goes active (low) at the beginning of the SPI clock period.

The CLRC663 responded bad things in this situation, so after pin checking and other stuff, I decided not to use the hardware SPI slave select, but using the same pin as a GPIO, and controlling it manually in my SPI routines.

So I went in this other situation (see Image_2.bmp).

Image_2.bmp

As you can see the glitch is located in the same position, but this time slave select goes low far before the SPI clock starting.

 

In fact my code is doing like this:

 

GPIO_DRV_ClearPinOutput(SPI_EN_663);

retval = SPI_DRV_MasterTransferBlocking(FSL_SPICOM1, NULL, buffer_ptr, &spi_rx_buf[0], length, SPI_TIMEOUT);

 

As you can guess also in this case SPI data is not correct because glitch occurs when the slave select is already active (low).

So, who's doing that glitch???

By going step by step I discovered (thanks also to my colleague Stefano) that is due to the lines into the file 'fsl_spi_master_driver.c':

SPI_HAL_Disable(base);

SPI_HAL_Enable(base);

 

For preventing this glitch I commented the first line ( SPI_HAL_Disable(base) ), but since the important comment just above in the code:

/* In order to flush any remaining data in the shift register, disable then enable the SPI */

 

I added the two lines above in my SPI routines:

SPI_HAL_Disable(base);

SPI_HAL_Enable(base);

GPIO_DRV_ClearPinOutput(SPI_EN_663);

retval = SPI_DRV_MasterTransferBlocking(FSL_SPICOM1, NULL, buffer_ptr, &spi_rx_buf[0], length, SPI_TIMEOUT);

 

In this way the glitch appears but before the slave select goes low, and the CLRC663 has all the time to know I'm going to communicate with SPI.

The results are here in Image_3.bmp:

Image_3.bmp

 

In this way using GPIO I can easily select which SPI peripheral to use for communication (if I have more than one on the same bus), and can also cope with devices not so fast recognizing SPI clock, when enabled it its proximity.

But all of this has been achieved in a quite "dirty way", by modifying the SDK code at driver level (see line commented).

 

So I suggest to add a couple of functions/methods in next SDK updates, for providing the option to enable/disable SPI slaves

manually.

Let me know what you think.

 

Kind regards,

      Luca O.   \8^)

Outcomes