Kinetis Software Development KitのトピックRe: SPI issue on KSDK V1.2.0 (at least on FRDM-KL25Z board)

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

lucaognibene — Fri, 16 Oct 2015 16:27:30 GMT

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).

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).

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:

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^)

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

DavidS — Fri, 16 Oct 2015 16:51:26 GMT

Hi Luca,

Another post mentions about glitch with GPIO:

https://community.freescale.com/message/577145?et=watches.email.thread#577145

I submitted request to our KSDK Developers to look into it. Maybe this is your issue too???

I am pointing them to this post too. Will report back when I hear something.

Regards,

David

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

lucaognibene — Mon, 19 Oct 2015 07:26:36 GMT

Hi David!

I read the suggested post, but I think it regards a similar problem into GPIO setup, while "my" glitch appears on SPI clock (either you use the hardware SPI enable signal, or GPIO).

The glitch problem is crucial if you want to use more than one peripheral on the same SPI bus: you have to use GPIO lines as enable for each peripheral on the bus, and select them "manually" before starting SPI communication.

Beside this using a GPIO line for SPI enable is mandatory if your peripheral isn't fast enough to get the SPI clock just half period after enabling it (as my case with CLRC663).

So I think you should open a different ticket for this issue.

Kind regards,

Luca O.

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

DavidS — Mon, 19 Oct 2015 15:42:30 GMT

Hi Luca,

I will mention to developers this may be separate issue.

Have you tried KSDK_1.3?

Regards,

David

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

lucaognibene — Wed, 21 Oct 2015 13:54:57 GMT

Hello again David!

At the moment our project is using KDS V3.0 and SDK V1.2.0, and I would not like to update the IDE on-the-fly, since this would mean jumping on a new version without knowing the exact effects (adding other variables to problem), and being almost sure about no benefits (by reading changes into the SDK release notes).

Anyway I got the KSDK V1.3.0. and I analyzed the sources for the relevant functions with WinMerge and they are absolutely the same code (SPI_HAL_Enable(), SPI_HAL_Disable() into fsl_spi_hal.h and MKL25Z4_extension.h for pointed macros).

I also tried, somehow, to set the SPI clock pin to ground level when SPI is not enabled, to prevent the glitch, but with no results: in this case I configured GPIO output to the pin PTC5 (by code), and set 0 the startup value.

It didn't work: the SPI clock pin was kept to zero all the time, even after SPI enabling.

With KDS+SDK+ Processor Expert it seems I can't share a pin between different peripherals: eg. using a pin as GPIO for a certain time, and using it as SPI clock for another time slice.

Anyway I think this issue should be solved somehow in a "clean" way, without touching the SDK: I'd like to notice that it appears on KL25Z128, but it may not on different architectures (eg. M4). I don't know.

Kind regards,

Luca O. \8^)

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

DavidS — Wed, 21 Oct 2015 16:32:03 GMT

Hi Luca,

Have you checked to ensure there is not a pull-up enabled for the SPI Clock signal either on board, in the PCR register, or somehow with the CLEV663B Blue Board?

If no pull-up found, could you try enabling the PCR pull-down for that pin to see how it affects the glitch?

Regards,

David

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

lucaognibene — Mon, 26 Oct 2015 17:01:53 GMT

Hello again David!

I checked the CLEV663B Blue Board schematic and I noticed that there's a pull-up resistor (1kohm) on the SPI clock.

This line on the dev board is also shared by the I2C bus clock so it's natural to have this connection.

But even for a SPI clock input, the pull-up it's advisable to be sure about what we get if the master SPI device is disabled for some reason.

Regarding the PCR register I checked the one related to the PTC port, and I noticed that the pull type selection is not available on the KL25Z (in fact the function PORT_HAL_SetPullMode() is ghosted since the #define FSL_FEATURE_PORT_HAS_PULL_SELECTION is 0.

This has been confirmed by KL25 reference manual (page 160, PS symbol in table, except for PTA0).

Anyway I tried 2 things:

- just set the pull-enable on PTC5 (the SPI0 CLK) editing the PE generated file pin_init.c: (not really advisable, but just a try...)

void init_gpio_pins(uint32_t instance)

{

switch(instance) {

case GPIOA_IDX: /* GPIOA_IDX */

/* Affects PORTA_PCR16 register */

PORT_HAL_SetMuxMode(PORTA,16UL,kPortMuxAsGpio);

break;

case GPIOB_IDX: /* GPIOB_IDX */

/* Affects PORTB_PCR18 register */

PORT_HAL_SetMuxMode(PORTB,18UL,kPortMuxAsGpio);

/* Affects PORTB_PCR19 register */

PORT_HAL_SetMuxMode(PORTB,19UL,kPortMuxAsGpio);

break;

case GPIOC_IDX: /* GPIOC_IDX */

/* Affects PORTC_PCR4 register */

PORT_HAL_SetMuxMode(PORTC,4UL,kPortMuxAsGpio);

PORT_HAL_SetPullCmd(PORTC,5UL,true);

break;

case GPIOD_IDX: /* GPIOD_IDX */

/* Affects PORTD_PCR1 register */

PORT_HAL_SetMuxMode(PORTD,1UL,kPortMuxAsGpio);

break;

default:

break;

}

Of course no differences in behaviour.

- used EmbSys RegEdit to modify registers on-the-fly (very cool :-) )

I manged to modify the PCR5 register of PORTC: mux from SPI to GPIO, set the GPIO pin from 1 to 0 and viceversa, and going back to SPI clock, but the glitch is always there when muxing to SPI clock selection again.

The "bad" thing at the end is that it seems to be necessary to disable/enable the SPI interface to flush its buffer.

To prevent this glitch it would be sufficient to find a way to flush SPI buffers securely without disabling the interface at all.

As written in the first post at the moment we solved the problem by modifying the SDK file fsl_spi_master.c, but it's not quite correct.

Kind regards,

Luca O. \8^)

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

DavidS — Wed, 28 Oct 2015 19:27:17 GMT

Hi Luca,

Thank you for the update and results.

What happens if you replace the pull-up with a pull-down? Do you still see the glitch?

Regards,

David

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

lucaognibene — Wed, 04 Nov 2015 11:13:58 GMT

Hello David!

Yes, with a pull-down no glitch, but it's really not advisable to use the pull-down (in this case modify the hardware config of the CLEV663 Blue Board).

What should be not done at driver level is the disable/enable of the SPI interface (thus no hi-Z state), so flushing SPI FIFO buffer differently.

Regards,

Luca O.

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

damarco — Thu, 07 Jan 2016 17:47:28 GMT

Hello

I have a similar and much worse problem with the SPI driver.

The glitches are not only the clock but also the MOSI. Since I first examined the problem in my application and found nothing. I have then tried the spi_loopback_example_frdmkl25z.

The execution is Success! The data push themselves despite the extremely bad timing in the register.

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

Kewal — Fri, 08 Jan 2016 19:52:10 GMT

I have been trying to get something on the MISO line, however I am unable to see anything.

While in parallel I have got the LDD working on the same board with almost same SPI register settings working properly as expected.

I was having a thread here on that issue here

SPI driver read not functioning with KSDK 1.2.0

also, I was wondering if there is any way to put LDD on my project, because the issue doesnt seem to exist with it and is only seen with the driver coming along with KSDK 1.2.0.

I have done pin settings for SCLK with pull down and other ping settings as shown here

Thanks,

Kewal

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

Kewal — Sat, 09 Jan 2016 17:28:03 GMT

Hi David,

I am having a similar problem where MISO is not able to communicate.

the below screen shot is the communication established through the LDD

While I am trying to use the PDD now along with safeRTOS and I believe i have done the right pin settings as well but still unable to see any response from the slave chip.

What could have gone wrong also my pin settings looks like this

Is there anything like busconfiguration init required before starting the communication.

thanks,

Kewal