FSM: a state gets latched

Reducing logic a bit, you see that many FSM transition conditions include TRIG[0] as direct input, e.g.

case (state)				
WAIT: 																	
	if (TRIG & !trig_SI_old)													
		state <= WAIT_2_X;											
WAIT_2_X: 														
	if(!TRIG)															
		state <= WAIT;														

Each of this conditions involves a data path to two state FFs, one to be set and one to be reset if the condition occurs. Flipping TRIG[0] in coincidence with the active clock edge (during the forbidden setup and hold window) can cause either both FFs set or both FFs reset, depending on clock skew and logic delays. The latter case has a good chance to act as illegal stuck state.

Adding synchronizer FFs for TRIG[0] makes all state FFs see a consistent input condition. Safe state machine encoding causes detection of any illegal state and reset to INIT.