STM32H755 DMA peripheral read timing differs from AN4031, actual hold time shorter, seeking explanation

[Large炒肉]

Hello,

I have recently tested the timing of DMA reading data from GPIO on an STM32H755 and found that the required input signal hold time is shorter than what is described in AN4031. I would like to ask whether my understanding is incorrect or if it is due to architectural differences in the chip.

Test platform and configuration:

Hardware: NUCLEO-H755ZI-Q, using the CM4 core, CM7 idle.

System clock: SYSCLK = HCLK = PCLK2 = 8 MHz, APB2 timer clock = 8 MHz.

Timer: TIM1 configured in PWM mode, CH1 outputs a 1 MHz square wave with 50% duty cycle, and the DMA request for the CC1 event is enabled.

DMA: Using DMA1_Stream0, peripheral address is GPIOA->IDR, data width half-word (16 bits), peripheral address not incremented; memory address points to an SRAM array, half-word width, address incremented. FIFO disabled.

External signal: A signal generator produces a 1 MHz PWM signal connected to PA0, and the phase is adjusted so that its edges align with the edges of the TIM1_CH1 output.

Test method:

Start DMA, transfer 100 data items, then stop; discard the first 20 samples and observe the value of Bit0 in the remaining 80 data items.

Gradually adjust the external signal duty cycle (starting from 50% and increasing), and record the critical condition at which DMA correctly reads high/low levels.

At the same time, change the duty cycle of the TIM1_CH1 output to verify how long the external signal must remain stable relative to the CC1 event.

Observation:
When the external signal duty cycle exceeds 75%, the value of Bit0 read by DMA becomes stable at the expected level; if the TIM1_CH1 output duty cycle is adjusted to 25%, the critical point appears at 50%. This means that the external signal must remain stable for about 250 ns (25% of the 1 MHz period) after the CC1 event in order to be correctly latched by DMA.

However, AN4031 mentions that the peripheral port access/transfer time is at least 4 AHB cycles (which would be 500 ns here). Why is the observed hold time shorter? My guesses are:

• The non-incrementing peripheral address causes the peripheral address computation phase (t_PAC) to be simplified or omitted;

• During continuous burst transfers, the peripheral port arbitration (t_PA) is not performed again;

• Or the DMA latches the peripheral data before the bus matrix arbitration (t_BMA).

Are these guesses valid? Or is the timing of the H7 series DMA fundamentally different from what is described in AN4031? I look forward to your reply. Thank you!

[KDJEM.1]

Hello ​@Large炒肉 ;

 

Thank you for sharing. I reported this behavior internally for checking. I will com back to you for more details as soon as possible. 

Internal ticket number CDM0065620 (This is an internal tracking number and is not accessible or usable by customers).

 

Thank you.

Kaouthar

[KDJEM.1]

Hello ​@Large炒肉 ;

 

To help us reproduce and understand the observed behavior, could you please provide the test example used and waveform capture illustrating the timing observed.

 

Thank you.

Kaouthar

[Large炒肉]

Hello Kaouthar,

Thank you for your support and for creating the internal ticket (CDM0065620).

I have prepared the complete test example and analysis report. Please find the attached file TEST_DMA_GPIO_Timing_2.zip.

The contents of the ZIP file are organized as follows:

• STM32CubeMX Project: A complete dual-core project. The test code executes on the CM4 core while the CM7 core remains idle. This project was generated with STM32CubeMX v6.18.1.

• Readme.pdf: Located in the root directory. It contains the detailed test methodology, measured data, result analysis, and my preliminary hypotheses.

• Test Waveforms: Oscilloscope screenshots stored under the Doc\Pictures\ folder.

Important Notes for Reproduction:

1. Project Compilation: Due to file size limits, the HAL library in this ZIP is linked to an external driver directory. To compile the project, please open the .ioc file with STM32CubeMX and regenerate the project to relink the drivers.

2. Hardware Modification: On the NUCLEO-H755ZI-Q board, the 0 Ω resistor SB72 must be removed to disconnect the ST-LINK clock from OSC_IN. A 4 MHz external clock signal must be supplied to OSC_IN. The system clocks (SYSCLK, HCLK, PCLK2) are configured to 8 MHz within the project.

Please let me know if the internal team requires any further information. I look forward to your findings.

Best regards,
Large炒肉

[KDJEM.1]

Hello ​@Large炒肉 ;

 

I think it is a correct approach, but I do not think it can provide cycle-accurate results.

A more accurate test would be:

• Place an incremental buffer in SRAM, for example values from 1 to 20,
• Then configure the DMA to read this buffer and write it to GPIO->ODR,
• Use the TIM1_CH1 compare event to trigger the DMA transfer from SRAM to GPIO->ODR.

It is true that, for both STM32F4 and STM32H7, the DMA is on the AHB bus matrix.
However, there are other architectural differences between STM32H7 and STM32F4:

• On STM32H7, GPIO is located on AHB4, which belongs to the D3 bus matrix.
• This is not the same matrix as D2, where DMA1 and DMA2 are located.

Referring to the transfer timing presented in AN4031, Table 4:

• For STM32F4 devices, tBMA bus matrix arbitration is always counted, except for the STM32F4 devices mentioned in note 1.
• For STM32H7 devices, tBMA bus matrix arbitration is counted only on the first data transfer. 

Thank you.

Kaouthar

[Richard Li]

 

Hi, ​@Large炒肉 ,

I didn’t find you noticed 4 AHB time request in AN4031, it only noticed if use burst mode, I don’t think you used burst mode.

Are you use different version?

Attached is “DocID022648 Rev 3”

Your test idea is good.

 

 

 

[Large炒肉]

Hi Richard Li,

Thank you for your reply and for attaching DocID022648 Rev 3. I confirm that I am also using Rev 3, and my code does not use DMA burst mode.

Regarding the “4 AHB” I mentioned, let me clarify: I did not mean that AN4031 explicitly states a “4 AHB request time”. My basis is Table 4, column “Through bus matrix / To AHB peripherals”, in non-burst mode, where the phases add up as follows:

• t_PA = 1 AHB
• t_PAC = 1 AHB
• t_BMA = 1 AHB
• t_EDT = 1 AHB
• t_BS = N/A

This gives a total of 4 AHB cycles.

Please note that Note 3 applies only to the t_EDT cell, not to the entire table. It says that in burst mode t_EDT depends on the burst length, for example INC4 gives t_EDT = 4 AHB cycles. My configuration does not enable the FIFO and does not use burst, so Note 3 does not apply, and t_EDT is taken as the default 1 AHB cycle.

I also understand that AN4031 is for STM32F2/F4/F7 DMA. My device is STM32H755: DMA1 is an AHB1 master in the D2 domain, while GPIOA is an AHB4 slave in the D3 domain, so there is a cross-domain access. Therefore AN4031 Table 4 cannot be directly applied to H755. I cited it only to explain where my initial “4 AHB” statement came from. My measured 2 AHB cycles also indicate that the H755 behavior differs from the F4 model.

Thank you for confirming that the test idea is good. Since the test method itself seems acceptable, may I ask whether the conclusion obtained from it — that GPIO data is latched in about 2 AHB cycles — can be considered reliable for STM32H755? Or would you recommend any additional checks or boundary conditions to make the conclusion more solid? Because not every STM32 series has a dedicated DMA application note like AN4031, I would like to know how much confidence I can place in this measured result.

Best regards,

Large炒肉

[Richard Li]

I think test idea is good, but test method may need check.

First question : Is this for product design?

If it only for study, this OK.

If it is for product, I think a lot of detail need change.