5.25 DSPI issues related to the DMA usage

[tsvetanmudrov]

Hello.

In release notes of last MQX version(4.1), i have found the following issue:

5.25 DSPI issues related to the DMA usage

When the DSPI uses the eDMA, it may transfer data incorrectly or fail when eDMA is used for another purpose. If the DSPI driver is the only user of eDMA, it should operate correctly. This behavior is a result of the silicon design of the DSPI.

DMA usage can be disabled in the DSPI driver by redefining the macro BSPCFG_DSPIx_USE_DMA to 0 in user_config.h.

But what this means?

1. Can I use 2 SPI channels simulatenously with DMA transfers?

2. Can I use SPI with eDMA simulatenously with SDHC and ADMA transfers?

I have read the errata sheets of Kinetis, and there is no related bugs in silicon. What exactly means "This behavior is a result of the silicon design of the DSPI."?

Can somebody explain clearly where is the problem and possible workaround? In most applications is common to use DMA for many peripherals, so if it's not usable, this makes entire MQX usage in question...

[petel]

Pavel

"......which works the way one would expect only on Senna, K60_2M and TorqSilver (and future devices). For prior devices,.....Generic recommendation it not to use DMA w/DSPI on older devices.

Is Vybrid an 'older device' ??

Is DSPI DMA usage with MQX 4.1.1 going to be a problem in the VF6xx Vybrid?? 

thanx

[kevinparks]

I need this additional question answered as well. Does Vybrid (VF6xx) fall into this 'older device' category?

[soledad]

Hi,

“There is a known problem in DSPI w/DMA because DSPI peripheral cannot handle narrow writes to PUSHR correctly (except of Senna, K60_2M and TorqSilver) and the driver does not implement workaround for this.

The DSPI w/DMA driver does not write full 32-bits to PUSHR  to avoid copy of data to intermediate buffer (there is no other efficient way to perform 32-bit write using eDMA).

This assumes that DSPI peripheral keeps the previous value (i.e. zero) in the bits not being written, which is unfortunately not true for older silicons, as I mentioned above.

However the non-DMA DSPI was thoroughly tested and I think it asserts CS correctly. If it does not work for some BSPs then the issue might rather be in the BSP/board configuration.

Please note that if you change CS using IOCTL it does not affect the state of CS signals immediately but rather upon next transfer as CS and bus settings are specific to particular file descriptor of SPI device.

Please refer to most recent MQX IO guide about this (be sure you have the latest IO guide)”

Have a great day,
Sol

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[tsvetanmudrov]

I plan to start my tests on SPI with eDMA next week. For the moment, I'm reviewing MQX drivers code....

I still don't have a clear answer of the question - how we can transmit block of 8 bit data with DSPI. Due to the data sheet - we need to load 32 bit values in TX FIFO, including command. There is some threads in community which discusses this issue:

https://community.freescale.com/thread/319196

https://community.freescale.com/thread/314225

After reading these threads, I'm still in question - is it correct to write a 8 bit value in PUSHR register, and what happens with "missing" bits - they preserve last values, they are cleared, or....

I'm a bit confused in the way, how the DSPI drivers in MQX are realized. Seems they write PUSHR register in 8 bit values. In this way, they loose control of nCS signals in traditional way (via control part of the 32 bit word). Instead of this, they are playing with PCSIS bits in SPI_MCR register which controls the inactive level of the pins. Probably this works, but it's sure not effective (it's slower), and they lose the control of CTAR timings in this way...

[pavel_chromy · Accepted solution]

Dear Tsvetan,

the text in the reply from soledad came originally from me, but it is not complete regarding information on CS.

It states correctly that the problem is in narrow writes to PUSHR register, which works the way one would expect only on Senna, K60_2M and TorqSilver (and future devices).

For prior devices, if DMA is not used for other purposes, then the bits in PUSHR not being written shall stay zeros, but this surely an undocumented feature.

Generic recommendation it not to use DMA w/DSPI on older devices. There is no reasonable workaround because it would involve making a copy of data to be transferred, extending it to 32 bits (waste of memory and copy overhead).

The CS bits on in PUSHR register are not used by the MQX driver solely on purpose, because it is then very problematic to deassert CS without transferring dummy data. It is makes problem when changing transfer mode (SCK polarity/phase) as it is desired to do this with inactive CS.

Pavel

[tsvetanmudrov]

Hello Pavel.

Thank you very much for this answer. The news are clearly not good ( DMA is not usable with SPI ), but I have expected this. In fact I was pretty sure that the explanation is exactly the "strange" behavior of the PUSHR register (when access is shorter the 32 bits). But now I have it confirmed from the freescale support, which is good.

Now I have switched to interrupt driven transfer in SPI driver, but I have a problems... again. :smileysad: See this thread:

MQX 4.1 SPI with interrupt problem?

[pbanta]

I would like to know the answer to this question, too.

I'm trying to move a project from MQX 3.8.1 to MQX 4.1 on a Kinetis K70.  I'm trying to use the MQX 4.1  DSPI driver with DMA and I'm seeing data corruption.  The most significant bit of each byte received is always set.  This never happened with the SPI driver in MQX 3.8.1 on the same board.  Also, my logic analyzer is showing the new driver 8x slower.  The latency between CS and SCLK is huge on both ends of the transaction.

[pavel_chromy]

Dear pbanta,

in fact the new driver offers higher sustained data rate in most cases. The delays between CS and SCK you observed are caused by software control of CS.

However when transferring larger amounts of data CS is typically kept active thus constant delay between CS and SCK is not an issue.

[pbanta]

I have determined that the cause of the data corruption has nothing to do with the DMA.  I noticed some odd settings in the CTAR register and traced them down to an incorrect baudrate setting in the init structure in init_spi.c.  I accidentally overlooked it.