When I enabled DWT (STM32F407), for getting microsecond delays, everything works fine but suddenly all activity comes to a stop for about 2 minutes and then everything starts working as usual. Interrupts seem to be occurring but everything else freezes.

[Parmin Nayani]

This happens at randomly. Spent more than a month trying to figure out the issue and never suspected DWT. When I commented out DWT everything works fine now. Can someone educate me on why this is happening and how to avoid it? Thank you for your time.

[Tesla DeLorean]

Probably related to how the counter wraps and how you scope your delay loops

[Parmin Nayani]

I start this counter at the beginning of my code and during LCD writes I use the uSec delay for clocking "enable" pulse. I am using systick and timer3 for delays of 1mSec and 10mSec respectively. I have an RS485 bus through which I communicate with 4 devices. Everything works fine and suddenly communication on RS485 line stops and after a few minutes starts as normal (controller does not reset). I found interrupts to be getting executed. Can you please educate me on what happens when this counter wraps? This happens at random times. Sometimes after a few hours.

[Tesla DeLorean]

It wraps like any other uint32_t count would.

I would suspect you're doing the uSec delay incorrectly.

You'd want to dereference the count so you can do the comparison, not compute an end point.

[Parmin Nayani]

Hi Tesla DeLorean,

"I would suspect you're doing the uSec delay incorrectly." This could be the reason!!!. Will check. I am using this delay for LCD enable pin control and as you mentioned, there could be an issue here. Just to mention the HAL_Delay provided in the HAL libraries also has an issue. This delay reads the current tick count and adds the asked delay and waits for the tick count to cross this value. What if the added value wraps to a lower count? I think this is what is happening in my case too. Wrap happens much faster in DWT case. Thank you.

[Piranha]

> This delay reads the current tick count and adds the asked delay and waits for the tick count to cross this value.

That is just not what the HAL_Delay() does:

https://github.com/STMicroelectronics/STM32CubeF4/blob/52757b5e33259a088509a777a9e3a5b971194c7d/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.c#L389

[Parmin Nayani]

Hello Piranha,

Thanks for the update on HAL_Delay. I will go through the code.