AM13E23019: Sequencer disabling behaviour

Hi Oleksandr,

Thank you for the detailed question and for sharing your stop/start routines. 

The AM13E230x TRM (Rev. A) does not explicitly document what happens when SEQENABLE is cleared mid-conversion.

The key insight comes from how the sequencer handles pre-emption. Even in the most aggressive pre-emption mode, the hardware is explicitly designed to **never abort a single SOC conversion that is already in progress**. The specification states:

"The ongoing sequence will be discarded **after completing any ongoing conversion** and arbitration will switch to higher priority sequence."

This pattern is consistent across all pre-emption modes documented in the architecture. The hardware waits for the current SOC conversion to reach EOC before acting on any state change. This means that when SEQENABLE is cleared mid-conversion, the most likely behavior is:

- The **currently active single SOC conversion will complete** and its result will be stored
- **No new SOC conversions will be initiated** after that point for this sequencer
- **New external triggers arriving after SEQENABLE is cleared will not be accepted** by the disabled sequencer

This corresponds to a scenario from a mid-conversion perspective — the in-flight conversion completes, then the sequencer stops — rather than an immediate hard abort.

DMA Trigger Implication

This is an important corner case for your implementation. The ADCWRAPPER architecture generates DMA interrupts at End of Conversion (EOC):

"ADCWRAPPER generates a DMA interrupt after end of conversion (EOC) of previous conversion only."

This means that **after calling `DL_ADC_disableSequencer`, one residual DMA trigger may still fire** corresponding to the EOC of the conversion that was already in progress. Your current stop routine correctly handles this because you immediately follow the sequencer disable with `DL_ADC_disableDMAInterrupt` and then disable the DMA channel entirely — providing three independent layers of protection against any stale data transfer.

Impact on Neighboring Sequencers

Based on the sequencer arbitration architecture, disabling one sequencer should have **no disruptive effect on neighboring sequencers**. The arbiter simply removes the disabled sequencer from consideration in the priority chain:

- SEQ1 → SEQ2 → SEQ3 → SEQ4 priority ordering is maintained among **enabled** sequencers only
- A disabled sequencer does not block, pre-empt, or interfere with the conversion flow of other active sequencers
- The overflow flag logic is per-sequencer, so disabling one sequencer does not affect the overflow status of others

The one interaction worth being aware of: if your disabled sequencer was **currently being serviced by the arbiter** at the moment of disable, the arbiter will complete that sequencer's current SOC and then move to the next enabled sequencer in priority order on the following arbitration cycle.

Assessment of Your Stop/Start Routines

Your routines are well-structured. Here is a detailed assessment/breakdown:

Stop Routine:

Start Routine:

The ordering in your start routine is particularly important. Clearing the DMA interrupt status **before** re-enabling the interrupt and sequencer ensures that any residual EOC event from the stopped sequence does not immediately trigger a spurious DMA transfer of stale data.

Optional Enhancement for Maximum Robustness

If you want to completely eliminate any timing uncertainty around the residual in-flight conversion, you could add a **status poll** between the sequencer disable and DMA interrupt disable steps in your stop routine:

DL_ADC_disableSequencer(...);

// Optional: poll until sequencer is no longer actively converting
// Check busy/active status flag if available on AM13e2x
while (DL_ADC_isSequencerActive(...)) { } // confirm in-flight SOC has completed

DL_ADC_disableDMAInterrupt(...);
DL_ADC_disableDMAChannel(...);

Best Regards,

Zackary Fleenor