Tracing the texture that stores this normal: Grass-R.fx says,
#define RT_NMLDEPTH_FX "Sub/Grass-NormalDepth.fxsub"

Searching for RT_NMLDEPTH_FX in Grass-R-Core.fxsub, we see that FMT_NDMAP is "A32B32G32R32F": so no problems from trying to use 8-bit texture with no negatives. We find DECL_SAMPLER for the same texture name (RT_NormalDepthMap4Grass##ID), and the sampler name smpOrgNormalDepthMap.

This ends up being one of the arguments passed to the pixel shader PS_Save. Which just returns a sample from this texture, as part of 'pass SaveNormalDepth', which is used by both MainTecNS and MainTec_BS (non-self-shadow and self-shadow).

This is written to RCT_NormalDepthMap + ID. Sampled by smpHeightMap. Which is used only once, on line 498, and stored as "vNrmD".

So: the bug is line 581, "float3 a = normalize( float3( vNrmD.y, 0.0, -vNrmD.x ) );"

If the object's normal points straight up and grass controller's bone isn't rotated, then xy are 0. Normalizing involves dividing by length, and so this divides by zero. Maybe some hardware handles it differently. If we affect the normal in "NormalDepth-Core.fxsub" pixel shader with something like "IN.vNormal +float3(3,1,0)", no visible change. I guess this is related to normal map.

From Grass-R.fx:
// 地面の法線に合わせる 1で有効、0で無効、有効にすると不思議なことに読み込み時間が結構増える
#define USE_FIT_NORMAL 1

"Align with ground normal 1 is enabled, 0 is disabled, strangely enough, enabling it increases loading time quite a bit"

Strangely enough, it seems to do nothing. Looks the same if changed to 0. But it fixes the flickering problem, works with Self-Shadow etc.