This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM5728: SPI occasionally pausing mid-transfer

Part Number: AM5728

Tool/software: Linux

Hello,

We're working to get SPI communications between a custom AM5728 board running Linux (version 4.4.12) and a slave-only device. The AM5728 is configured as a master running at 9.6MHz. When the slave device has data to send it sets a GPIO high. A program running on Linux monitors the GPIO signal and on going high will perform a 128 byte transfer. Over the course of testing we've seen the 128 byte transfer pause mid-transfer. The pause varies from microseconds to milliseconds and happens randomly.

Attached is an image of two 128-byte bursts over SPI (CSn and SCLK shown). The 128-byte bursts happen every ~4.2ms and should only take ~250us each. During the second data burst there's a 3ms pause midway through the data offload. There are no other user programs running on the system and this happens often, though not always 3ms.

What would cause the transfer to pause?

Could a process with higher level priority be interrupting the SPI transfer?

If possible that another process is interrupting SPI, is there a way to disable all other background interrupts, either by elevating the priority of user program or by disabling background processes?

We've tried assigning an affinity value to our SPI program to test if running on CPU0 or CPU1 changed the behavior but on either core we still see the transfer occasionally pausing. Using cat /proc/interrupts we checked to see what other processes could be interrupting it but we're not sure how to change it so they don't interrupt anymore, or if we should. Below is a screenshot of the cat /proc/interrupts output.

  • Hi Juan,

    Juan Gonzalez65 said:
     custom AM5728 board running Linux (version 4.4.12)

    Do you use AM572x TI PSDK 03.00.00?

    Juan Gonzalez65 said:
    The AM5728 is configured as a master running at 9.6MHz

    Do you mean you have 9.6MHz on the AM572x SPI clock pin?

    Juan Gonzalez65 said:
    When the slave device has data to send it sets a GPIO high. A program running on Linux monitors the GPIO signal and on going high will perform a 128 byte transfer.

    You are using GPIO pin to signal AM572x device to start the transfer, but do you use AM572x SPI CS pin to select the SPi slave device before starting the actual transfer?

    Juan Gonzalez65 said:
    Over the course of testing we've seen the 128 byte transfer pause mid-transfer. The pause varies from microseconds to milliseconds and happens randomly.

    You have pause inside this 128 byte transfer or you have pause between two 128 byte transfers?

    When pause occur, do you see that pin SPI_CS is de-asserted? If yes, you can try to handle this with MCSPI_CHxCONF[20] FORCE bit. spim_cs[i] can be kept active between words with the SPIm.MCSPI_CHxCONF[20] FORCE bit.

    See AM572x TRM, section 24.4.4.3.5.2 Force spim_cs[i] Mode, 24.4.4.3.5.3 Turbo Mode




    Regards,
    Pavel

  • Hello Pavel,

    Thank you for your reply.

    We are using TI PSDK RT version 3.02.00.05.

    Yes, we have 9.6MHz on the AM572x SPI clock pin.

    Yes, we use CS to first select the slave prior to the SPI transfer. That would be the yellow trace (active low) in the first image in my original post.

    The pause has been observed both between 128byte transfers and within the 128byte transfer itself. The first image in the original post shows a pause within the 128byte transfer. The blue trace is SPI CLK and you can see it just stops (while CS is still active) and continues after ~3ms. The pause isn't always ~3ms and has been observed to vary from microseconds to milliseconds.

    As you can see in the image in the original post, CS is still active during the pause, and in fact remains active in between bytes. It would seem that something else Linux is running is causing the pause when we use SPI since we've seen this even when we only run the SPI transfer software and nothing else. We've ran baremetal SPI drivers before and have only seen this pause issue when managing McSPI from within Linux.

    How best can we determine and avoid the interrupts that are occurring? I attached a screenshot of the /proc/interrupts in case that helps.

    Is there a way to ensure our software runs at the highest priority level so that nothing can interrupt it?


    Thanks,
    Juan
  • Juan,

    Juan Gonzalez65 said:
    Yes, we have 9.6MHz on the AM572x SPI clock pin.

    Can you try to increase it to the max 48MHz (if your slave device support this speed)? You might get better performance in this case.

    Juan Gonzalez65 said:
    As you can see in the image in the original post, CS is still active during the pause, and in fact remains active in between bytes. It would seem that something else Linux is running is causing the pause when we use SPI since we've seen this even when we only run the SPI transfer software and nothing else.

    Can you also check with "top" command that you do not have any other process running?

    Juan Gonzalez65 said:
    How best can we determine and avoid the interrupts that are occurring? I attached a screenshot of the /proc/interrupts in case that helps.

    Is there a way to ensure our software runs at the highest priority level so that nothing can interrupt it?

    You can try with the "nice" command. See also if the below e2e threads will be in help:

    Regards,
    Pavel