RT1176 SPI clock short on every 8th interval

[raddeh]

Using the RT1176 for SPI communication, we do see weird clock behaviour: every 8th clock signal is very short. I've attached two images below, showing that this happens on every clock and an zoomed in version showing how short the clock signal is.Of note is, that the data follows the clock properly, so the signal of the 8th bit is also shortened. In the measurements, the clock is shown in yellow, SDO is shown in blue.

Note that the noise on that line is connected to where we've done the measurement. Other instances of SPI communication with the RT1176 show the same behaviour, even if the signal is less noisy.

Three byte SPI transmission. Clock: yellow, SDO: blue. Shortened signals marked with red arrowZoomed-in on one byte transmission. 8th shortened clock marked with red arrow. clock: yellow. SDO: blue

The RT1176 SPI interfaces is set up as master with the following parameters:

{
    uint32_t clock_freq;
    lpspi_master_config_t sdk_spi_config;
    edma_config_t sdk_dma_config;
    uint8_t dma_mux_channel_rx, dma_mux_channel_tx;
    LPSPI_Type* instance;

    //Init SPI
    LPSPI_MasterGetDefaultConfig(&sdk_spi_config);
    instance = LPSPI5;
    clock_freq = CLOCK_GetRootClockFreq(kCLOCK_Root_Lpspi5);
    sdk_spi_config.baudRate = 1000000/2;
    sdk_spi_config.bitsPerFrame = 8;
    sdk_spi_config.cpha = kLPSPI_ClockPhaseFirstEdge;
    sdk_spi_config.cpol = kLPSPI_ClockPolarityActiveLow;
    sdk_spi_config.direction = kLPSPI_MsbFirst;
    sdk_spi_config.pcsToSckDelayInNanoSec = 100;
    sdk_spi_config.lastSckToPcsDelayInNanoSec = 100;
    sdk_spi_config.betweenTransferDelayInNanoSec = 10;
    sdk_spi_config.whichPcs = kLPSPI_Pcs0;
    sdk_spi_config.pcsActiveHighOrLow = kLPSPI_PcsActiveLow;
    sdk_spi_config.pinCfg = kLPSPI_SdiInSdoOut;
    sdk_spi_config.dataOutConfig = kLpspiDataOutTristate;
    instance->CR |= LPSPI_CR_DBGEN_MASK; //enable LPSPI in debug mode
    LPSPI_MasterInit(instance, &sdk_spi_config, clock_freq);


    //Data transfer
    uint8_t buf_tx[9] = {0};
    uint8_t buf_rx[9] = {0};
    lpspi_transfer_t transfer;
    txBuffer[0] = 0x24 | (1 << 7);
    transfer.txData = buf_tx;
    transfer.rxData = buf_rx;
    transfer.dataSize = 9;
    transfer.configFlags = kLPSPI_MasterPcs0 | kLPSPI_MasterPcsContinuous;
    if((retval = LPSPI_MasterTransferBlocking(instance, &transfer)) != kStatus_Success)
    {
        printf("Transfer failed!\r\n");
        if(retval == kStatus_LPSPI_Busy)      printf("kStatus_LPSPI_Busy\r\n");
        if(retval == kStatus_InvalidArgument) printf("kStatus_InvalidArgument\r\n");
        if(retval == kStatus_LPSPI_Timeout)   printf("kStatus_LPSPI_Timeout\r\n");
        return false;
    }
    return true;
}

The transfer does succeed, kStatusSuccess is returned by LPSPI_MasterTransferBlocking(). We're using the latest SDK.

[jay_heng]

According to your configuration, it should be as below timing diagram

sdk_spi_config.cpha = kLPSPI_ClockPhaseFirstEdge;           // 0
sdk_spi_config.cpol = kLPSPI_ClockPolarityActiveLow;        // 1

So i think what you marked is not 8th SCK issue, it seems that 1st SCK issue start from second byte transfer. can SPI slave get correct second byte data then?

Can you try different CPHA&CPOL configuration to see any difference?

Do you run \SDK_2_12_1_MIMXRT1170-EVK\boards\evkmimxrt1170\driver_examples\lpspi\polling_b2b_transfer demo on your side? can it work properly?

 

[raddeh · Accepted solution]

@jay_hengSorry for the delay, but I was only now able to continue on this problem. I did some more tests with other configuration values. There is no different when using other CPOL or CHPA values. But I did discover, that the betweenTransferDelayInNanoSec value corresponds to the length of this last clock.

The reference manual specifies:

Configures the delay from the last SCK edge of a transfer word and the first SCK edge of the next transfer word, in a continuous transfer.

So I did expect it would be a delay end of the 8th clock pulse and the beginning of the 9th clock pulse. But it seems to directly control the high-time of every 8th clock pulse:

The following setting results in a 40nsec long high-period of every 8th clock pulse:

baudRate = 100000;
betweenTransferDelayInNanoSec = 10;

The following setting results in a 80nsec long high-period of every 8th clock pulse:

baudRate = 100000;
betweenTransferDelayInNanoSec = 100;

The following setting results in a 952nsec long high-period of every 8th clock pulse:

baudRate = 100000;
betweenTransferDelayInNanoSec = 1000;

So this value is the length between these 2 edges. So it should be set to 1/2 * baudrate + delay_between_bytes.