2025-11-19 1:00 AM
Hello everyone,
I am reaching out to the community regarding an issue my team is experiencing on the STM32MP257F, specifically within a project running on the Cortex-M33 core.
We are attempting to configure SPI2 to transmit data to an external DAC using HPDMA1. While SPI2 transmission works correctly without DMA, integrating HPDMA results in no data movement—DMA does not appear to start, and SPI output remains idle.
We initially relied on CubeMX for code generation, but due to several inconsistencies (e.g., peripherals marked as enabled were not properly configured, some register settings missing), we shifted to a manual initialization approach. Unfortunately, the issue persists.
The intended configuration is as follows:
DMA Mode: Standard transfer (no linked list).
Direction: Transmit only; no receive path required.
DMA Request Source: HPDMA_REQUEST_TIM3_UP
TIM3 period: 50 µs
Clock: 200 MHz, Period register: 9999
Trigger Source: TIM15_TRGO
TIM15 period: 250 µs
Clock: 200 MHz, Period register: 3999
We would greatly appreciate if anyone could provide:
A reference implementation,
A known-working initialization sequence, or
Any code snippet demonstrating the correct setup of SPI2 + HPDMA1 under similar conditions.
Such an example would help us validate our approach and identify any missing configuration steps.
Thank you in advance for your support and insights.
2025-12-02 8:12 PM
This post has been escalated to the ST Online Support Team for additional assistance. We'll contact you directly.
Regards,
Christian
ST Support
2025-12-03 2:41 AM
Following my previous post, we have made some improvements to the issue, but we still need assistance to fully understand and resolve the remaining problems.
We managed to get the SPI2 peripheral communicating through HPDMA to an external DAC.
Compared to the previous setup, the following changes have been applied:
The DMA mode is now Linked List, no longer the standard mode.
The transfer direction is still memory-to-peripheral (TX only).
The DMA request source has been changed to REQUEST_SPI2_TX.
We are now using HPDMA2 (Channel 15) instead of HPDMA1.
TIM3 is no longer used.
TIM15 is used to trigger the DMA–SPI transmission of a single burst (1 word) taken from a 50-word buffer located in memory.
The clock remains at 200 MHz, and TIM15 triggers DMA–SPI transfers at 500 kHz.
An additional timer (TIM4) toggles a GPIO used to latch the DAC output (LDAC) at 500 kHz (update event).
The system initially works, starts the DMA–SPI transfers correctly, and the DAC updates properly. However, after some time (from a few seconds up to a few minutes), the DAC stops updating its output. It freezes on a single value and never recovers unless the system is reset.
Oscilloscope measurements show that the SPI data is still being transmitted correctly and the LDAC signal is still stable and well-timed.
We currently do not understand the following points:
Frequency dependence:
If we reduce the SPI/DMA trigger frequency from 500 kHz to 400 kHz, the system becomes stable and the issue never appears.
The same happens if we trigger the SPI transfer only every two timer update events (effectively ~250 kHz).
Output glitches depending on buffer location:
For testing, we are sending a simple ramp. However, depending on the DMA configuration, the ramp shows glitches or jumps.
We temporarily solved this by moving the buffer from DDR memory to SRAM, which removes the glitches.
Still, we would like to understand why the memory location has such a large effect on the output stability.
The DAC itself is known to work correctly at these speeds (SPI clock = 50 MHz), since it runs reliably on another FPGA-based setup. Therefore, we believe the issue is more likely related to our DMA/SPI configuration rather than the DAC.
We are not using CubeMX for code generation, as it tends to generate unreliable configurations for our setup.
Any hints, examples, or suggestions on properly configuring HPDMA linked-list mode, SPI2, and the timer triggers would be greatly appreciated.
Thanks in advance for your support.