S32K312 Flip-Flops behavior of software override for sync from LCU I'm trying to understand the LCU's software override section using the sync[x] input. I configured the following fields for Logic cell "0": -SWVALUE=1 -LC0_SCTRL[SW_SYNC_SEL]=0 -LC0_SCTRL[SW_MODE]=1 -SWEN[0]=1 -LC0_LUTCTRL0[0] = 0b1010101010101010,(since I'm controlling INPUT 0 and OUTPUT 0.) Using TRGMUX, I applied a rising edge to the sync[x] input and immediately saw the switching at SWOUT[0]. However, following the schematic in the manual (Software override section), with two flip-flops chained together, I expected the output to update on the second edge. Why does the diagram show two chained flip-flops both with the same CLK source, but their behavior is different? arielcolombo_0-1769015411971.png Re: S32K312 Flip-Flops behavior of software override for sync from LCU Hi @arielcolombo
Although the diagram shows two flip‑flops connected in series and driven by the same clock, they are not intended to introduce a two‑edge delay. Both flip‑flops are synchronous and update on the same rising edge of the clock.
In this Software override path, the value to be forced (SWVALUE[0] - MUX) is already registered before the sync[x] event occurs. The purpose of the two chained flip‑flops is to internally synchronize the sync[x] control signal and to reduce metastability, not to require two separate trigger events.
When a rising edge is applied to sync[x], that edge is synchronized through the flip‑flop chain and then to the SWOUT[0]. As a result, the output changes after the first trigger event. So, even though two flip‑flops are shown, they serve as a synchronizer, not as a mechanism to delay the output until a second sync[x] edge.
BR, VaneB Re: S32K312 Flip-Flops behavior of software override for sync from LCU Hi, thank you for the clarification. That makes sense — the two flip-flops are used purely as a synchronizer for the sync[x] control signal, not as a pipeline introducing a two-event latency. My confusion came from interpreting the diagram as a sequential delay element, while in practice the SWVALUE is already registered and the synchronized sync[x] edge effectively updates SWOUT on the first trigger. Thanks for confirming the intended behavior.
View full article