We have the problem, that the ecspi2 MOSI signal is not driven appropriatly on first usage of the spi-driver.
After a restart of our software, or after closing the SPI- filehandle and reopening it, the MOSI signal works as expected without any further problems, until the device is restarted.
The SPI-CLK works without any problems.
There is only one slave attached to the SPI, therefore CS is pulled low and MISO is not connected.
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Greetings,
For the issue where the ECSPI2 MOSI signal on the Verdin iMX8MP Q 2GB WB IT V1.1A does not drive high on the first operation after startup, but functions as expected after restarting the software or reopening the SPI file handle, there are several potential areas to investigate:
Device Tree Configuration: Ensure that the SPI interface is correctly configured in the device tree. This includes checking the initialization of the ECSPI2 interface, the pin multiplexing settings for the MOSI signal, and any relevant chip select (CS) configurations. Since the issue corrects itself after a software restart, it might not be a misconfiguration but it’s worth reviewing for any potential issues that could affect initial SPI communication.
SPI Driver Initialization: There could be an issue with the initialization sequence of the SPI driver in the Linux kernel. The driver might not be correctly setting up the MOSI line on the first operation. Reviewing the driver’s source code for the initialization sequence might provide insights. Specifically, look for any differences in the driver’s behavior between the first SPI operation and subsequent operations.
Electrical Characteristics: Since the issue is observed on a custom carrier board, it’s important to verify the electrical characteristics of the SPI lines, especially the MOSI signal. Ensure that there are no electrical issues that could prevent the MOSI line from being driven high initially. This includes checking for proper pull-up/pull-down resistors, signal integrity issues, or interference that might affect the MOSI signal.
Software Workaround: As a temporary workaround, you might consider implementing a software sequence that performs a dummy SPI operation (e.g., sending a byte that the slave device ignores) as part of the initialization process of your application. This could “prime” the SPI interface and ensure that the MOSI signal is driven correctly for subsequent operations.
Kernel and BSP Version: Ensure that you are using the latest version of the TorizonCore and the Board Support Package (BSP) for the Verdin iMX8MP. Sometimes, issues like these are resolved in newer versions of the software.
SPI Clock Configuration: Although you mentioned that the SPI clock (CLK) works without any problems, it’s still worth reviewing the clock configuration for the SPI interface. Incorrect clock settings might sometimes cause unexpected behavior in SPI communication.
If after reviewing these areas the issue persists, it might be beneficial to conduct further debugging by enabling detailed logging for the SPI driver in the
Please, also check if these links can help you solve your problem:
Hello @aigF,
What do you mean by the MOSI pin not being driven appropriately? Does this mean that upon first use of the SPI you see the clock but don’t see the data pins moving? What is the behavior of the chipselect?
when I say the MOSI is not driven appropriately, I mean the measurement above. (see the image of the oscilloscope)
The MOSI signal can not even reach a value of 1V.
The clock signal is as expected: 1.5MHz; 0-3V3;
The CS-PIN for this SPI as directly connected to ground on the SLAVE, since there is only one.
Restarting our software, or closing and reopening the SPI, lead to the MOSI working as expected. (Signals are driven from 0 - 3V3).
Bidirectional buffers with automatic direction of every pin may be tricky. Device you used seems being simpler, but you should make sure you MOSI device on 3V side device doesn’t pull pin low. Pull up resistor should pull properly high. If LCD MOSI is bidirectional, then perhaps LCD RESET pin is not driven properly. If RESET is applied later than first SPI transaction, then it could explain why 2nd attempt is OK
please excuse the late reply.
See the plot for the 1V8 side below. As you can see it shows the same problem as the 3V3 side.
I also thought @Edward reply might have some merrit, but our current workaround seems to disprove this slightly.
Our current workaround looks as follows:
//this is a hack
//dummy initialisation of the SPI2;
//write to the bus, and reinit, since we currently have a problem with MOSI otherwise
spi2.Init("/dev/verdin-spi2", SPI_SPEED_DISP);
gpiod_line_set_value(gpio_dispA0, 0); //clear A0 pin
uint8_t cmd = 0xD7; // Disable Auto Read
spi2.Write(&cmd, 1, SPI_MODE_3);
spi2.~SPIPort();
spi2.Init("/dev/verdin-spi2", SPI_SPEED_DISP);
//init display
disp.Init(&spi2, gpio_dispA0, gpio_dispReset, gpio_dispBacklight);
We init the SPI, write a command to the LCD that has no effect and deinit the SPI again.
Afterwards the SPI works as expected. The LCD reset is touched during the display initialisation.
