SCT halt problem in split mode with different prescalers?

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
Content originally posted in LPCWare by MarcVonWindscooting on Sun Nov 16 12:25:28 MST 2014
I want to program beep() functionality with CPU in sleep mode.
I planned the following: SCT lower 16bits ("SCT-L"): frequency generator, SCT upper bits ("SCT-H") duration. The output CTOUT0 always has to end with level LOW. Due to the limited range of the match registers, SCT-H runs at a lower frequency to get reasonable durations. For frequency generation I use 1us cycle time, for duration 20us. CTOUT1 is used as communication between SCT-L and SCT-H.

The whole beep runs from the SCT alone without CPU intervention as follows (no sleep mode used so far):
when calling beep(), CTOUT1 is set to 0 (active) and both SCT-L and SCT-H cleared and started.

SCT-H has one match (event EV_END), that causes CTOUT1 to be set and SCT-H stopped.

SCT-L toggles CTOUT0 using mathes at value 0 (clear CTOUT0) ("EV_L"/"EV_HALT") and t/2 (set CTOUT0) ("EV_H") and a bidirectional counter. EV_HALT is configured to HALT [color=#f00]both[/color] SCT-L and SCT-H besides clearing CTOUT0. EV-HALT happens at match value 0, if CTOUT1=1. EV-L at the same match, if CTOUT1=0 (active) and only  clears CTOUT0. EV_H sets CTOUT0 and reverses counting direction (limit event).

The observation is: SCT-H ist NOT halted by EV_HALT (SCT.CTRL.HALT_H not set).
Okay, it's stopped already, but I wanted the SCT.CTRL.HALT_H as the single authoritive value indicating, that the next beep can be started.

I assume, it's because of the different clocks/prescalers. Some kind of synchronization problem. But that synchronization is exactly what I'm after ;) Has anybody experienced a similar problem?
I can do a workaround (halting SCT-H in the first place, later checking for both HALT flags). What is the expected behaviour?
The SCT documentation does not clarify this situation.

EDIT: uC: LPC812, later LPC810.