I’m an engineer working under Michael Snadden at Coherent Corp and I’m working on a variant system similar to what Mike was working on in this TS thread " 2 Devices on 1 SPI Port, CS0 problem"
The system that I’m working on now is very similar to the one in the above thread. The main difference is in this system, only 1 SPI port is being used to talk to multiple devices using GPIO ports for each device CS. An FPGA is using the standard pin 86 as it’s CS, an ADC is using pin 70 as it’s CS. For the most part communication is fine when addressing the FPGA and ADC using this port 1, but what I’m seeing is on average over the span of 8-10 hours of the system happily running without issues, the SPI port will have a random spurious CS access (pin 86 going low) for a very short time time, < 1us, and this will initiate a read cycle with clock cycles on the bus, with the CS line in the high state! The data will be read as 0xFFFF, which our code will be read as a fault condition. I have captured scope images showing this weird CS “blip” and the resulting clock cycles for some bus access. I’ve used a TPx location on our h/w board to signal when this faulty read occurs and captured the previous read on the bus that initiated the fault bit. The scope trace shows this “blip” in the CS (pin 86) and the subsequent clock cycles. I even temporarily removed all other devices from using this SPI port (ADC code removed for testing to make sure it wasn’t interfering with the SPI comm).
What in your opinion is causing this seemingly random CS “blip” on the default pin 86?
In those trace pictures, the blue probe trace is MISO, cyan probe trace is SCLK, yellow probe trace is TP6 (GPIO activated in f/w), the lower green probe trace is the CS (pin 86);
the digital signals are the sclk, CS, MISO, MOSI above. You can see in tek00003.png the CS “blip” and tek00004.png shows the zoomed in clock cycles during the phantom “read” operation when CS is in the high state.
Any ideas on this? This system is using the imx6 Colibri module, replacing the T20 due to its end of life timing. We are also debugging a similar ADC read issue that will also return spurious 0xFFFF reads on occasion too and that currently is on the same platform that Mike originally sent those TS questions previously.
Thanks,
Glen
Colibri iMX6DL, 512MB, V1.1Y
Custom carrier board, AviaNX
WinCE 7.0, Image BSP 1.8
I believe we have a custom GpioLib.cpp and GpioLib.h files
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hi Glen,
Based on the information provided, it seems like you are experiencing spurious chip select (CS) glitches on the SPI interface of your Colibri iMX6DL module. Here are a few potential causes and suggestions to troubleshoot this issue:
Electrical Noise and Signal Integrity:
Ensure that the SPI lines, especially the CS line, are properly terminated and shielded to minimize noise and crosstalk.
Check the PCB layout for any potential issues that could cause signal integrity problems, such as long traces or improper grounding.
GPIO Configuration:
Since you are using GPIOs for CS lines, ensure that the GPIOs are correctly configured in your firmware. Any misconfiguration could lead to unintended toggling of the CS lines.
Verify that there are no conflicting configurations or unintended GPIO manipulations in your custom GpioLib.cpp and GpioLib.h files.
Software Timing Issues:
Check if there are any timing issues in your software that could cause the CS line to glitch. This could be due to race conditions or improper synchronization between different parts of your code.
Ensure that the SPI transactions are properly synchronized and that there are no overlapping operations that could cause the CS line to toggle unexpectedly.
SPI Driver and Firmware:
Review the SPI driver and firmware to ensure that there are no bugs or issues that could cause the CS line to glitch. This includes checking for any known issues or errata related to the SPI controller on the iMX6.
Consider adding additional logging or debugging information to help identify the root cause of the issue.
Power Supply Stability:
Ensure that the power supply to the Colibri module and the SPI devices is stable and free from noise. Power supply fluctuations can sometimes cause unexpected behavior in digital circuits.
External Interference:
Check for any external sources of interference that could be affecting the SPI lines. This could include other high-frequency signals or electromagnetic interference (EMI) from nearby components.
Given that you have already captured scope images showing the CS “blip” and subsequent clock cycles, it would be helpful to analyze these traces in detail to identify any patterns or correlations with other events in the system.
If the issue persists, you may want to reach out to Toradex technical support for further assistance, as they may have additional insights or suggestions based on their experience with the Colibri iMX6 module and similar issues.
Best regards,
[Your Name]
Please, also check if these links can help you solve your problem:
I haven’t run any tests with just the OS running yet.
We’ve only made minor formatting changes and type definition changes in the gpiolib class. We use the uIo data structure instead of INT32 for pin numbers due to the multiplexing differences in the T20 to imx6 processor.
SPI Library v2.6.1521564247 is what is being currently used.
I don’t believe we made any registry changes to image 1.8 to handle any SPI port definitions, we handled all setups within the application code base.
I am trying to load BSP 1.9 to see if there is any change with our application.
I will try to pare down a minimal program that still exhibits this spike behavior.
I’m having problems trying to load the 1.9 image file to be recognized by TEZI. I’ve tried the image zip file, [imx6_winceimage_1.9-20240506.zip] extracted and placed this on a USB stick formatted to FAT32, but TEZI does not see it. I’ve even tried to use a custom image imx6_winceimage-custom.zip package and replaced the nk7.nbk from the 1.9 OS image zip, renamed to nk.nbk, but I get an error in the TEZI app, “Error downloading or writing image cat: can’t open ‘Backup.i6r’:No such file or directory…”
What am I doing wrong in getting TEZI to recognize the 1.9 OS image?
The imx6_winceimage_1.9-20240506.zip is not a TEZI-compatible image. If you have an older WinCE release running on the module, you can use the Update tool to upgrade it (use the version included in that zip). Otherwise, put the module into recovery mode and run imx6recovery.bat from the recovery folder in that zip file
@alex.tx and @GlenM, I think the root cause of this issue might be the same as the root cause of this other topic, which is that the GPIO library is not thread-safe on the iMX6. More testing is required to confirm that.
