iMXRT1010 LPSPI isn't operational when source PLL is bypassed

[benedek_kupper]

We must have LPSPI1 running in all power modes (FullSpeed, LowSpeed, LowPower). I'm attaching the specific.c that we're using: I'm calling LPSPI_Deinit() before changing clocks, then LPSPI_MasterInit() when clocks are stable. This is the SPI configuration:

const lpspi_master_config_t LCD_SPI_config = {
  .baudRate = 15000000UL,
  .bitsPerFrame = 8UL,
  .cpol = kLPSPI_ClockPolarityActiveHigh,
  .cpha = kLPSPI_ClockPhaseFirstEdge,
  .direction = kLPSPI_MsbFirst,
  .pcsToSckDelayInNanoSec = 1000UL,
  .lastSckToPcsDelayInNanoSec = 1000UL,
  .betweenTransferDelayInNanoSec = 1000UL,
  .whichPcs = kLPSPI_Pcs0,
  .pcsActiveHighOrLow = kLPSPI_PcsActiveLow,
  .pinCfg = kLPSPI_SdiInSdoOut,
  .dataOutConfig = kLpspiDataOutRetained
};

First I had the LPSPI_CLK_SEL on PLL2_MAIN_CLK, now it's on PLL3_PFD0_CLK, in both cases if I switch into a clock mode that has the source PLL bypassed, the LPSPI peripheral doesn't initialize correctly, and I cannot perform any transfers anymore.

[victorjimenez]

Hello, 

The baudrate at which you are operating the LPSPI is high. Therefore when you bypass the PLL, the frequency might not be enough to reach this baudrate, which leads to the SPI not working at all. 

Regards,
Victor 

[benedek_kupper]

The LPSPI driver (LPSPI_MasterSetBaudRate) calculates a real baudrate based on the configuration value and the input clock speed, and sets the prescaler based on that. In this case (24 MHz input clock, 15 MHz desired baudrate) the realBaudrate is calculated to be 12 MHz. I've also tried to change the baudrade to 6 MHz, but that didn't change the result either. The peripheral driver should configure the closest achievable baudrate where the LPSPI is still operational, so if you say that it's because of the too high baudrate, then this needs to be fixed in the driver. But to me it looks like it has more to do with the silicon. Can you confirm that LPSPI transfers work for you when the clock source PLL is bypassed?

[victorjimenez]

Hello, 

I will make some tests on my side to see if I can replicate this behavior. Before you mentioned the following: "the LPSPI peripheral doesn't initialize correctly, and I cannot perform any transfers anymore". Could you please clarify what do you mean by the LPSPI peripheral doesn't initialize correctly? Are you seeing some error when initializing the module or the function to initialize it is running without problems but you are not seeing any transfer in the MOSI pin? 

Regards, 
Victor 

[victorjimenez]

Hello, 

I made some tests on my end and I didn't face any problems initializing the LPSPI module when I bypassed the PLL. For these tests, as a clock source for the LPSPI module, I selected the PLL2 PFD2. Keep in mind that in the SDK examples even if you modified the PLL3 in the MCUXpresso Config tools this won't have any effect due to the following condition. 

Regards,
Victor