This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Spi clock problem

I have double checked the driver of spi controller, and before transferring, there is an if condition to check the DMA as below:
Quote:        /* we need prepare dma before spi was enabled */ 
        if (master->can_dma && master->can_dma(master, spi, xfer))  
                rs->use_dma = 1;   
                rs->use_dma = 0;  

And can_dma() compares the transfer length and FIFO length:
Quote:        return (xfer->len > rs->fifo_len);

The length of FIFO is 32, since the transfer length is 3 in test program, the DMA should be disabled.
However, I still got the failed waveform as you attached pic.

(08-17-2017, 03:12 AM)jamess Wrote: for building kernel
$ make ARCH=arm miniarm-rk3288_defconfig -j16
$ make zImage ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -j16

then you will get a file in the following path

and just replace the zImage file in your sdcard
before you replace the file, we recommend to backup the original file first

(08-21-2017, 03:32 AM)ychou Wrote:
(08-18-2017, 09:51 AM)alr2000 Wrote: Thanks!
The problem is that there is a DMA error and I have to disable the DMA on the SPI driver according to
I already solve and the Papirus E-Ink screen is working with the TinkerBoard.


Did you also test the SPI clock with your test program after fixing the issue?  No, because the problem was different, the INK screen accepts the continuous clock (with out word pauses)

Because our codebase (miniarm) already merged the fixing commit before I verified this issue.
And I have checked the DMA settings, it should not be enabled. 
I am surprising at the solution which is to disable DMA.

Could you please share the modified code? I would like to check again.
The modified code is:

@@ bool rockchip_spi_can_dma(struct spi_master *master,
struct spi_device *spi,
struct spi_transfer *xfer)
- struct rockchip_spi *rs = spi_master_get_devdata(master);
- return (xfer->len > rs->fifo_len);
+ return false;

Thank you!
Thank you!

But it seems that to force returning false in rockchip_spi_can_dma() is the same result as your test tool to send data, since the length of sending data is less than 32.
Just for confirmation, is there an interval in spi clock between words after patching?
I use spidev 3.4 to make a communication between (personal development board) and (ASUS Tinker Board S). I use xfer2 function to read spi data on ASUS Board from my board. So i want to add a delay_usec in between blocks, I found the delay_usec in the spi.xfer2 but it is not working for me. I have tried several ways to add this delay, but I didn't succeed.
Some of my attempts I used are:

spi = spidev.SpiDev(),0)
spi.mode = 1
#spi.max_speed_hz = 250000
spiResp = spi.xfer2([0, 1, 2, 3], 250000, 1000, 8)

spiResp = spi.xfer2([1])
spiData = range(spiResp[0])
spiResp = spi.xfer2(spiData, 250000, 1000)

Please, can anyone help me with that ?
I think you might add a time.sleep(). But for the python nature timing are not reliable as expected. You should look for the RTOS. Another answer might be this, which, in short, tells to split your transfer blocks at the point you need to separate.
Light blue words might be a link. Have you try to click on them? Big Grin
It's not good to add a time.sleep(). I need to delay interbyte response time, because my development board does not get enough time to fill the answer from xfer/xfer2 functions.

2. And from what I noticed, the delay_usec doesn't work at all... or at least at a frequency of 250kHz
I would refrain that timing with python are not reliable as one would expect. Because of the multitasking nature of the system.
You may try a different path to write a program with wiringPi, but also that might fail because of OS priorities over any program. Except to adopt a RTOS kernel.
If you're using the TB as master, it might improve the situation if you reduce the SPI speed for a relaxed speed (say 5kHz). Probably the receiver will find more time to manage the received data. Rather than loose the data at all.
Light blue words might be a link. Have you try to click on them? Big Grin

Forum Jump:

Users browsing this thread: 1 Guest(s)