SPI clock settings on i.MX7

Technical Support
, , ,
1

Hi,
I just discovered, that there is only the Chance to select two clock rates !!!
With my former SoM I had the Chance to select a clock divider value (32 bit Register) and so it was easy to set lot of baud rates.
I have to work with ~15Mhz for Timing reasons, but on the i.MX7 dual I only can set 1Mhz or 10Mhz.

Any Chance to solve that, otherwise it will be hard or impossible to use the i.MX7.

With best regards

Gerhard

2

hi @Gerhard

Could you provide the hardware and software of your module? Which carrier board are you using?

How are you setting the spi clock frequency? For which spidev, do you want to set the Spi Clock?

Best regards, Jaski

3

Hi Jaski,
I plan to use the i.MX7 Dual, my moduls were Revision D.
This module should work on my custom board (to be designed) but now I use the IRIS carrier board, but also have the Colibri development board V 3.2 here.

The target OS is WEC2013.

The BSP is the latest i.MX7 Version, also the SDK.

I need a SPI connection, Colibri is master and a SAM4N processor by Atmel is slave. According to hardware limitations of the SAM4N there is only byte transfer available at a max. speed of 15MHz.

The timing requirements for the data transfer in general dictates a very high speed, so with 15Mhz it is quite ok, at lower speeds the risk of data loss is higher.

On both sides ring buffers were used to decouple the time domains of the two systems.

System A: Powerd by SAM4N
System B: Powerd my AT-501 SoM, which should be replaced by Colibri i.MX7D.

A typical cycle:

1174-last-xfer-problem-3.png
1174-last-xfer-problem-3.png800×503 9.75 KB

~BRDY, out of System A signals, that data is available for transfer.
DL_SCLK, output of System B is the SPI shiftclock (System B is master) so we can see the actual data transfer. Sometimes the OS (WEC2013) stops responding and so the ring buffers do their job to prevent data loss.

So I hope that the latency times on the i.MX7 are not longer than I see now (on the AT-501) and the transfer speed is close to 15MHz.

On my AT-501 ( and its BSP) I can fine tune the time span between ~CS goes low and SPI clock starts, in the moment I use a delay of 55ns. There is no chance to fine tune this (important) parameter on the i.MX7D & BSP, so there is just hope it will work out.

Currently I work on a port of the thin hardware related layer of my project, after finishing this work, I am able to do tests using real hardware.

Cause I am out of office from 10.9 to 24.9, I think, first results will be available in october.

With best regards

Gerhard

4

Hi Gerhard

I did some quick checks:

  • From a hardware aspect the SPI bit rate can be much higher than 10Mbps (according to the datasheet)
  • The library forwards any requested SPI bit rate to the underlying driver. The driver call fails, if a frequency cannot be met within 10% tolerance.
    I assume that our setup already does support other clock rates than 1 and 10 MBps, but it requires some investigation and documentation on our side to specify the possible options better. I have put this as a feature request in our bug&feature report system.
    Meanwhile you could try to use other bit rates by increasing the requested frequency in steps of approximately 5%.

Regards, Andy

5

Hi @Gerhard

I did some more detailed checks with the library V2.2:
Available SPI bit rates on the Colibri iMX7S and Colibri iMX7D can be calculated as follows:

**60MHz / N / 2^M **, where

  • N is in the range [4 … 16], and
  • M is in the range [0…15]

The algorithm selects a frequency which is up to 10% higher than the requested frequency!

  • Example 1: The user requests a bit rate of 11MHz. The actual bit rate will be 12MHz (see table below).
  • Example 2: The user requests a bit rate of 10.8MHz. The actual bit rate will be 10MHz (see table below).

Bit rates up to 15MHz are supported.

Regards, Andy