Speed command spikes during host-controlled ramp on F28069M dual-motor dyno model

I’m using the mcb_pmsm_foc_qep_dyno_f28069m example with a TI F28069M LaunchPad and two DRV8305 booster packs in the motor-dyno configuration.

When I run the model with a constant RPM command from the host, both motors behave normally and the reference speed is stable.

However, when I switch to a ramp input from the host model (over the SCI TX/RX link), the target’s Speed_Ref_PU signal occasionally spikes to extreme values, causing the control loop to overflow and the motor to jerk or stall.

I’ve verified that:

• The host model sends a continuous ramp through SCI without discontinuities.
• The issue persists whether I send only “speed” or include the full SCI data vector (motor select, debug flags, enable bits).
• The model works fine with single-step commands or static RPM inputs.

This makes me suspect that the serial communication framing or data synchronization in the receive path is being corrupted when streaming continuous values, possibly because the dyno model’s receive subsystem expects discrete “change-only” packets instead of continuous float updates.

Questions:

1. Is the dyno example’s SCI receive block designed for discrete or continuous data streaming?
2. What is the recommended way to send a smooth ramp command from the host without causing overflow?
3. Would it be more stable to generate the speed profile directly on the target model instead of streaming it over SCI?
4. Are there any updates or simplified single-motor examples for the F28069M that demonstrate host-controlled ramp inputs safely?

Any advice or updated example links would be greatly appreciated.

Answer 1

[Satyam]

Hi @Jonathan,

The mcb_pmsm_foc_qep_dyno_f28069m example uses a simple SCI framing mechanism intended for discrete command updates. Continuous high-frequency streaming of floating-point values can cause packet misalignment or partial reads, leading to corrupted Speed_Ref_PU values and control loop overflow.

Secondly, the recommended way to send a smooth ramp command from the host without causing overflow is to implement the ramp generator on the target model using a simple ramp block. This avoids SCI synchronization issues and ensures deterministic behavior.

Thirdly, generating the ramp on the target is the most robust approach because it eliminates communication-induced jitter and overflow.

You can refer to this example to explore single-motor FOC examples for F28069M: https://www.mathworks.com/help/ti-c2000/ug/foc-qep-example.html . While it does not explicitly show a continuous ramp from the host, it provides the framework for host-controlled speed updates with proper packet handling, which you can adapt for ramp inputs.