SPI Receive block reading out incorrect data on TI C2000 MCU

21 visualizaciones (últimos 30 días)
Peter
Peter el 29 de Nov. de 2025 a las 7:26
Respondida: Ayush el 9 de Dic. de 2025 a las 6:54
Hello,
I am implementing FOC on a 3 phase inverter using a rotary encoder as the position sensor on a C2000 MCU (LAUNCHXL-F28379D board). The encoder I am using communicates with BiSS-C, and I have an FPGA that translates this into SPI (it sends CS, MOSI and CLK) to send to the MCU.
My Simulink model has 3 asynchronous subsystems, and has a swithcing frequency of 20kHz. In the first one, the MCU uses SPI SYNC to get the FPGA to request encoder position. This is triggered 8us before the top of the switching cycle via PWM interrupt. SPI RX interrupt triggers a second subsystem, which just has the SPI Receive block. The third subsystem is triggered after that (at the top of the switching cycle), and is the FOC block with current sampling adcs and PWM duty cycle generation. Subsystem 2 and 3 are non-preemptable. It is using a SPI clock frequency of 6MHz, with 16bits per position measurement.
This normally works perfectly, and motor position is read out accurately. My issue is that when my motor goes to high electrical speeds relative to the base speed (constant Fsw, constant SPI clk rate, not a signal integrity issue) I start to receive incorrect SPI position readouts. When I probe the SPI pins with a logic analyser they read out the correct position (same as BiSS-C), however when I log the position in Simulink it randomly jumps up or down and is incorrect. The random position sometimes looks like a bit shifted version of what it should be, but other times it is completely random (not bit shifted, many random bit changes).
I believe this could be something due to my CPU/model getting overloaded, as when I add more stuff to my FOC block these incorrect positions start to happen more often and at lower speeds. However, the SPI SYNC subsystem always runs on time and is preemptable, so the FOC block must be finishing running well before the SPI receive subsystem. I cannot remove anything else in my FOC block, as all it has are reading current sensors and doing clark/park transforms.
My questions are:
1) Anyone heard of this issue before, or knows what could be causing this?
2) If not, how can I ensure that my subsystems are being ran on time and can I probe how long these are taking to ensure they are not running overtime and causing problems?
Massive thank you to anyone that can provide guidance.

Respuestas (1)

Ayush
Ayush el 9 de Dic. de 2025 a las 6:54
Hi Peter,
I understand your concern and wanted to share some relevant findings from a similar case with SPI data inconsistencies on TI C2000 devices.
Sometimes, issues like random or shifted SPI reads can occur if the chip select (CS) line toggles during a multi-word transfer. If the SPI receive block or subsystem reads data before the entire transfer is complete, or if the CS goes high in the middle of a transaction, this can result in corrupted or incomplete data, especially at high speeds or CPU load. You can try the below mentioned recommendations:
  1. Try using the SPI Transfer block for the full data packet, followed by the SPI Receive block to read the data from the FIFO after the transfer is complete. This ensures all data is received before reading.
  2. Alternatively, if you use the Master Transfer block, configure explicit GPIO control for chip select. This way, CS stays low for the entire exchange, preventing protocol issues.
  3. Make sure the SPI receive logic only runs after the transfer is completed, to avoid partial or out-of-sync reads.
To check subsystem timing, use Simulink’s Execution Profiler or toggle a GPIO at the start/end of each subsystem and measure with a scope.
Hope this helps!

Productos


Versión

R2023a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by