IMX8M Mini - SPI Data/Burst Size on Cortex-M4

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

IMX8M Mini - SPI Data/Burst Size on Cortex-M4

315 Views
Swiss2
Contributor II

Hi,
I am trying to use a ECSPI communication between the M-core and a FPGA, but I can't seem to figure out how to change the data size from 32 bits to 8 bits. When using the CMSIS SPI example from the MCUXpresso SDK (cmsis_ecspi_int_loopback_transfer, adjusted to use pins instead of loopback), the control command:
```
DRIVER_MASTER_SPI.Control(ARM_SPI_MODE_MASTER | ARM_SPI_CPOL0_CPHA0 | ARM_SPI_MSB_LSB | ARM_SPI_SS_MASTER_SW | ARM_SPI_DATA_BITS(8), TRANSFER_BAUDRATE);
```
Has absolutely no influence on the transfer, most importantly the ARM_SPI_DATA_BITS(8), but also changing the Slave Select mode or the speed changes nothing. The transfer keeps operating correctly only when uint32_t values are sent.
I then decided to try without CMSIS, and use the example "ecspi_loopback" from driver_examples folder, but just at the first look of the [ECSPI Documentation](https://mcuxpresso.nxp.com/api_doc/dev/1418/a00009.html) I see that struct ecspi_transfer_t have a send/receive buffer of uint32_t.
I know that the physical buffer is 64 x 32 but is it really impossible to send/receive 8 bit sized elements (e.g. char)?

I then went away from the CMSIS implementation to the regular ECSPI Driver following the example from the SDK (SDK_2_12_0_MIMX8MM6xxxKZ\boards\evkmimx8mm\driver_examples\ecspi\ecspi_loopback)

I experimented with different burst lengths and here are my observations:
When setting the burst length to 32 and sending uint32_t data, where first three numbers are 1002, 1023, 1024 the data is sent correctly (see Figure under).

Bild_2022-07-19_132156596.png
 

But when the burst length is set to 8 with the same uint32_t data, only the last 8 bits of each number are sent (you can double-check in binary but it is clear that 1023 is sent as 1111 1111 and 1024 as 0000 0000). I expected to see the whole uint32_t sent in four bursts, but the fact is that the data just gets lost. It is funny how the driver examples from the SDK work just because they are always sending numbers smaller than 256 packed inside a uint32_t. If they tried with a bigger number, it wouldn’t work.

image.png

 I would like to understand whats going on a bit better.

Labels (1)
0 Kudos
0 Replies