KW36 - SPI - troubles with TX FIFO & bit shifting

[loic_guillaume_]

Hello,

Some context here : I'm using a MKW36 on a custom shield plugged on a nucleo L053R8. The goal is to replicate the S2-LP behaviour as 2.4Ghz sniffer. 

I'm having issues to understand something that is happening while I'm using SPI. Please find attached my code (forked from nxp example).

after using DSPI_SlaveTransferNonBlocking(SPI1, &g_s_handle, &slaveXfer), the registers state is correct : 

SR & TX0 are as expected.

On the master side, i'm sending a byte (CS low). I want the slave to send 0xAA but it sends 0x00. And if repeat the operation with another transfer right after (sending 0xBB for example). 0xAA is sent. The CS didn't return to the higher state.

I cannot understand the "delay". 

Also if the CS go HIGH then LOW between the transfer, there is no "delay" but the first byte sent is still 0x00.

I would greatly appreciate if you have some indications for me.

Regards,

Loic

[mario_castaneda]

Hi Loic,

Sorry for my late reply.

What is the example that you are running on the KW36?

Are you seeing this dummy data with a logic analyzer?

However, this behavior that you are seeing is a none issue. When the SPI module sends data, the FIFO keeps the last data in the buffer. The workaround, the device sends a dummy byte for erasing or cleaning the buffer, but if you look at the logic analyzer, you shouldn't see this dummy data.

The CS didn't return to the higher state.

The CS is controlled by the Master device, are you setting the CS as 0 in the Master side?

Regards,

Mario

[loic_guillaume_]

Hello Mario,

Thanks for the reply.

What is the example that you are running on the KW36?

  I'm using "driver_examples_dspi_interrupt_b2b_transfer_slave" from the example pool of the kw36

Are you seeing this dummy data with a logic analyzer?

Yes I am. I use an Oscilloscope to watch the 4 SPI lines (CLK, MOSI, MSIO, CS) and with a special feature it can display MOSI and MISO values.

The CS didn't return to the higher state.

The CS is controlled by the Master device, are you setting the CS as 0 in the Master side?

Yes. It is on purpose. I want to chain 2 transfers into the same "CS Low" if I can say. 

Beg my pardon, but when you say "the device sends a dummy byte for erasing or cleaning the buffer". Why the next transfer doesn't erase the buffer ? I don't understand the need of a dummy byte here.

Regards,

Loïc.

[mario_castaneda]

Hi  Loïc GUILLAUME,

Please see the image attached. I am sending a byte at the same time that the Master is sending the first data.

I tested by my side, working on the driver_examples_dspi_interrupt_b2b_transfer_slave from the SDK.

I am sending just one byte as you.

Yes. It is on purpose. I want to chain 2 transfers into the same "CS Low" if I can say. 

You are trying, in this case, to send 0xAA and 0xBB, aren't you?

I am following your implementation and using the SPI included in the SDK.

I commented on the Stop Transfer and Flush Fifo, the DSPI_SlaveTransferNonBlocking is implementing these 2 functions.

    uint8_t a[2] = {0xAA,0xBB};
    uint8_t b = 0x01;

    //DSPI_StopTransfer(SPI1);
    //DSPI_FlushFifo(SPI1, true, true);

    while (1)
    {
        PRINTF("\r\n Slave example is running...\r\n");

        /* Reset the receive buffer */
        for (i = 0; i < TRANSFER_SIZE; i++)
        {
            slaveRxData[i] = 0U;
        }

        /* Set slave transfer ready to receive data */
        isTransferCompleted = false;
        slaveXfer.txData = a;//NULL;
        slaveXfer.rxData = NULL;//slaveRxData;
        slaveXfer.dataSize = TRANSFER_SIZE;
        slaveXfer.configFlags = kDSPI_SlaveCtar0;

        /* Slave start receive */
        DSPI_SlaveTransferNonBlocking(EXAMPLE_DSPI_SLAVE_BASEADDR, &g_s_handle, &slaveXfer);

        while (!isTransferCompleted)
        {
        }

        /* Set slave transfer ready to send back data */
        isTransferCompleted = false;
        slaveXfer.txData = &b;//slaveRxData;
        slaveXfer.rxData = NULL;
        slaveXfer.dataSize = TRANSFER_SIZE;
        slaveXfer.configFlags = kDSPI_SlaveCtar0;

        /* Slave start send */
        DSPI_SlaveTransferNonBlocking(EXAMPLE_DSPI_SLAVE_BASEADDR, &g_s_handle, &slaveXfer);
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Why the next transfer doesn't erase the buffer?

Sorry for this misunderstanding, this implementation is already done in the code. The driver is erasing the buffer.

I checked the main file that you provided.

Is it possible that you could provide some screen of the issue?

What is the reason that you are toggling the PTC17? 

Regards,

Mario

[loic_guillaume_]

Hi Mario,

Sorry I should have started by some screens. 

Here is my problem rephrased: 

I don't get the CS influence when I'm chaining 3 transfers of a given size (1 in this case). With the same code on the slave side (cf. the file provided with the first post), I get two different results, whether or not I raised the CS between the transfer. 

With CS lowered and raised between transfer:

Without CS lowered and raised between transfer :

PTC17 is raised for timing purpose, It helps me to see when I'm in the interruption after the transfer (Channel 4 on the screens). 

As you can see when the transfer is finished, the interruption is triggered with and without the CS. In one case (without CS) I got 0xAA then 0xBB the 0xCC and in the other, a "delay" is created.

I hope it will help you understand my issue.

Regards,

Loïc

[mario_castaneda]

Hi Loic,

Please see the image below, the CS is going up after the end of the transmission. I am using 2 KW36 boards.

As you can see when the transfer is finished, the interruption is triggered with and without the CS. In one case (without CS) I got 0xAA then 0xBB the 0xCC and in the other, a "delay" is created.

This time delay is creating by your master application. I am not sure why the CS is taking a lot of time to returns to the high value. Please see the next image.

The timing marker pair is showing the time form the last falling edge of the CLK to the rising of the CS. The time is 2us, after that, the KW36 takes 11us to toggle the PIN(following the same process that you did.)

The KW36 is waiting for the CS rising edge, but as the Master application is taking some time, the slave enters in another process. If you look at each to toggle pin, the "delay" is increasing, this is because the CS takes more time to change the status

Regards,

Mario