SPI communication with epaper display driver ssd1680

[massimoklk]

Hello,

I am currently trying to migrate the code to activate an epaper display from STM to Nordic. The function used to write to the driver via SPI is the following:

int32_t NORDIC_SPI_Write(HANDLER hSPI,uint8_t *pData,uint32_t DataSize){
  ret_code_t ret = NRF_SUCCESS;
  int32_t wr_ret = (int32_t) EMBL_OK;
  HANDLER hPDev = WRSPI_getPhysicalDevice(hSPI);
  WRSPI_setCSS(hSPI,false);
  ret = nrf_drv_spi_transfer(hPDev, pData, DataSize,NULL, 0);
  WRSPI_setCSS(hSPI,true);
  if(ret != NRF_SUCCESS){ // HAL_SPI_Mem_Read retorna o HAL_OK o HAL_ERROR
    wr_ret = (int32_t)EMBL_ERROR;
  }
  return wr_ret;
}

And the configuration of our SPI is:

  nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG;
  spi_config.mosi_pin = 33;
  spi_config.sck_pin  = 35;
  spi_config.frequency    = SPI_FREQUENCY_FREQUENCY_M1,

The signal Analyzed in both MCUs is practically Identical, with the only difference that when I send the data after a command in nordic the clk signal does not go idle in between bytes, and with the STM it does. Is there anyway to configure SPI so that it acts the same? Attached are both captures of the signal for STM(CLK stops in between bytes) and nordic(constant CLK through all the transfer ):

[Kenneth]

Hello,

I suspect setting the following kconfig option to 1 will give indirectly provide that result:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/kconfig/index.html#CONFIG_SPI_NRFX_RAM_BUFFER_SIZE 

Alternatively you may use the nrfx api directly to user the spim hardware, such as shown here:
https://github.com/zephyrproject-rtos/hal_nordic/blob/master/nrfx/samples/src/nrfx_spim/blocking/main.c

Kenneth

[hmolesworth]

The trace for the Nordic part is preferable given that there are no unwanted idle periods and so the transaction completes in less time; why would an idle period be required? In this case the STM is doing individual byte transfers rather than a burst transfer, but it is unlikely that is required unless there is some hardware restriction on the slave.

Edit: I don't see a trace for the Data/Command signal on the STM; that implies you are using 3-wire SPI on the STM but in any case the data stream requires no gap between transmitted bytes.