Check of this post from Blurbusters -
https://forums.blurbusters.com/viewtopic.php?f=17&t=8283
<Technical>
Frame presentation APIs such as Present() instantly triggers refresh cycles during VRR. That allows framerate and Hz to be in perfect sync to each other -- and eliminate framdrop-style stutters -- and de-stuttering smooth framerate changes -- but creates problem when framerates exits the VRR range (frametimes longer than min-Hz, for example).
Software bugs with VRR can cause blackouts on many FreeSync monitors, since it is kind of a real-time operation for software, and drivers that violate VRR ranges is sometimes more common than it should be.
Native G-SYNC chipped monitors will often be able to refresh unattended if drivers don't begin sending a new refresh cycles, but FreeSync doesn't do this -- the graphics driver is responsible for beginning to transmit a new refresh cycle on time. But oftentimes, software is not microsecond precise.
Ideally, manufacturers need at least fraction of a Hz of safety headroom below min Hz, to allow software imprecisions. For example, panels should support ~35-240Hz for a software-based 48Hz-240Hz VRR range. Unfortunately not enough manufacturers include enough min-Hz VRR headroom, and sometimes.... software-driven refresh cycle imprecision occurs.
Drivers (including Microsoft non-realtime behaviors) accidentally keeping the monitor unrefreshed too long -- is a major cause of FreeSync monitors going blank below min Hz.
VRR blackout issues are usually caused by software tolerance issues. A well-tuned Windows system may have no problems, while a flawed driver installation (on a monitor without min-Hz tolerance) may fail to keep up the refresh cycles.
Besides this, behaviours such as flicker (refresh-cycle decay, inversion algorithms, etc), also make it favourable to raise the min-Hz, to force the drivers to refresh more frequently.
LFC is simply driver-initiated automatic repeat-refreshes, but it must be done before monitor refresh cycles times out (and goes blank automatically). Even if sometimes minor stutters occur from new-refreshes colliding with monitor-busy-repeat-refreshing events. (But at 180Hz, a monitor is only busy for 1/180sec executing a repeat-refresh. And since it's chance whether a new frame may occur beyond halftime or before halftime of that refresh cycle -- so halve that. 0.5/180sec = 1/360sec average stutter caused by an LFC miss. 1/360sec stutters are very hard to see at 30fps or 40fps anyway, so a higher min-Hz is perfectly fine for wide-VRR ranges (3:1 ratio or bigger). So you're trading away those annoying blackouts for potentially un-seeable added stutter at low frame rates.
This was a bigger problem with 144Hz FreeSync monitors, where a 0.5/144sec (3.5ms) stutter may become visible during 55fps operation (18ms), since 3.5ms:18ms is an approximately 20% stutter (e.g. a frame step between adjacent frames suddenly increases by 20% in movement distance).
But as VRR ranges get wider, 240Hz, your 55fps material (21ms) versus the halftime of 240Hz repeat-refreshes (2ms) means stutter deviations are smaller -- less than a 10% stutter. This starts to become impossible to see for most people, and still looks like perfect 55Hz VSYNC ON with the stutter deviation so small that the low-framerate stutter becomes hidden in the plain display motion blur of the lowness of frame rate (as you've noticed, the lower the frame rate on VRR, the more motion blur, until it falls into the stutter-visibility region of the stutter-to-blur continuum).
TL;DR: LFC has far less penalty when VRR range is extremely wide, and LFC (hidden repeat refreshes) can be superior in image quality to extremely low native refresh rate because of various reasons. You you get the advantages of a higher min Hz (less flicker, less GtG decay, more consistent color equalling colors of max-Hz, avoid varying-ghosting effects, fewer inversion-artifacts such as scrolling chessboard effects, etc). Since picture quality at different refresh rates may be slightly different.
When LFC is absent of refresh-cycle collision events, it looks indistinguishable to well-done low-Hz (since repeat-refreshes ideally behave like no-operations, as long as they don't delay the new frame). At some point, the higher-min-Hz pros starts to exceed the LFC-cons when "busy-doing-refresh-cycle" events are very brief (1/240sec or faster).
So that's why Blur Busters now feels higher min-Hz on wide-VRR-ranges produces superior VRR experiences, visually -- not just for blackout reasons.
It is /sometimes/ ALSO the manufacturer's fault, occasionally
That said, manufacturers should include lower undocumented min Hz in more FreeSync panels just as safety headroom (even as low as 30-40Hz). This safety headroom is just accommodation for software performance -- graphics drivers too slow to refresh frequently enough risks these blackouts you saw. There should always be more undocumented min-Hz headroom below the EDID-advertised VRR range, but unfortunately many panels cheap out and have no safety margin -- creating lots of blackout complaints.
</Technical>