Showing results for 
Search instead for 
Did you mean: 

Fast pin toggling on STMH723

Associate II

I have been trying to see how fast can I toggle the pins on STM32H7 MCU. I'm using a nucleo-H723zg board. 

the clock configs are at the highest (550Mhz for CPU, 275 for APB and AHB), the pins are configured as very high speed. 
But still with a simple while loop such as 


while (1) {

GPIOE->BSRR = (uint32_t) GPIO_PIN_2;

GPIOE->BSRR = (uint32_t) GPIO_PIN_2 << 16U;


the frequency of the PWM I see on the oscilloscope is 7.3 MHz max. Ofcourse the PWM is not the final goal
but I wanted to see how fast this mcu can implemnet the bit toggling.
Am I doing something wrong here?



That seems very slow indeed.

Any interrupts active?

In case you need fast PWM, use a timer.

Not really a great test, way the bus is constructed apt to be slow.

Use a TIM, they have an actual mode for this..

Perhaps use an address bit of an FMC bus? And use M2M mode DMA

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Uwe Bonnes
Principal II

What is GPIO High time, what is low time? Low time include the loop. Run many such sequences in a loop! Is Icache Otherwise the loop will include wait state. And what is optimization setting?

I don't just need a pwm. it was more of a test because I suspected that every instruction is taking longer than I expected. 

originally I realized this while trying to implement a custom protocol and realized every instruction seem to add a considerable amount of overhead. 

for example a simple

 GPIOE->BSRR = (uint32_t) GPIO_PIN_2;

adding 60ns. Also not getting accurate delay because 


adding extra 20 or 30ns.

The high and low time were almost the same. maybe 45% high 55% low. changed the optimization from none (-O0) to optimize for speed (-Ofast) and no change. 

You did not use a scope to measure timing?

I did.  time high and time low are exactly the same. 

As @Tesla DeLorean said above, in 'H7, GPIO access time from processor is dominated by traversal through the many buses and their interfaces




Try removing the unnecessary casting, from

GPIOE->BSRR = (uint32_t) GPIO_PIN_2 << 16U;



I hope this helps.

Kind regards