I'm writing to ask for your expertise on a challenging issue customer is facing with reading data from two ADCs simultaneously on the AM6422. Please see below email:
We've implemented a solution to communicate with two ADS7038Q ADCs in parallel using two SPI peripherals (MCSPI0 and MCSPI1), but the implementation is proving to be unreliable.
Our Current Approach
The intended logic is to use a master-slave clocking scheme:
-
MCSPI0 is configured as the clock master, generating the SPI clock for both devices.
-
MCSPI1 is set up as "data-only" and is intended to use the clock from MCSPI0.
-
A single GPIO pin acts as a shared Chip Select (CS) for both ADCs.
Here is a view of the hardware connections from our schematic:
Our transaction sequence is as follows:
-
Pull the shared GPIO CS pin low.
-
We then initiate the two
MCSPI_transfercalls. To manage the timing, we use the Init delay parameter from the SysConfig tool specifically when starting the transfer for the slave peripheral (MCSPI1), right before the master (MCSPI0) begins generating the clock. -
We wait for both transfers to complete using semaphores.
-
Finally, we pull the shared GPIO CS pin high.
The Problem: Inconsistent and Unreliable Data
The core challenge we're trying to solve is reliably controlling this shared-clock and shared-CS architecture from software.
Despite this setup, the communication is not stable. Even when tuning the Init delay and experimenting with different SPI clock frequencies, we are consistently getting different or corrupted values from the ADCs on each read cycle.
It seems that even with the
Init delay, we cannot overcome the inherent timing jitter of starting two peripheral operations from software. The slight, unpredictable delay is enough to cause misalignment and unreliable data.Given these synchronization challenges, I was hoping you might have some suggestions.
An alternative solution was suggested that involves using the PRU to "bit-bang" the SPI protocol directly. This method would provide the deterministic, cycle-accurate timing needed to solve our synchronization problem.
An alternative solution was suggested that involves using the PRU to "bit-bang" the SPI protocol directly. This method would provide the deterministic, cycle-accurate timing needed to solve our synchronization problem.
However, this solution is not feasible for our current hardware design. The PRU bit-banging approach requires that the CLK, MOSI, and CS lines be controllable as general-purpose I/O (GPIO). Our board does not use GPIO for these signals; they are wired directly to the dedicated MCSPI peripheral pins on the processor. Because of this hardware constraint, we cannot implement this PRU-based solution without a board revision.
Do you know of a more robust, method on the AM6422 to trigger two SPI transfers at the exact same time?
For example, could we use an internal event trigger or another peripheral feature to ensure both MCSPI modules start in perfect lockstep?
For example, could we use an internal event trigger or another peripheral feature to ensure both MCSPI modules start in perfect lockstep?
Any insights or alternative approaches you could recommend would be a great help.
Thank you for your time and consideration.
