• State
  • Replies 0 replies
  • Subscribers 81 subscribers
  • Views 21 views
  • Users 0 members are here
Support feedback
Options
Options
Related

LAUNCHCC3235MOD: TMS320F28379D: ADC Burst Mode with Post-Processing Block (PPB) Result Registers reading 0 at runtime despite valid conversions

Rong Wang
Prodigy 20 points

Part Number: LAUNCHCC3235MOD
Other Parts Discussed in Thread: LAUNCHXL-F28379D, TMS320F28379D

TI Part should be  LAUNCHXL-F28379D (Delfino F28379D LaunchPad)
Hardware Platform: LAUNCHXL-F28379D (Delfino F28379D LaunchPad)
Part Number: TMS320F28379D
Toolchain / IDE: Code Composer Studio (CCS) v12
Compiler: TI v22.6.0.LTS
Description of Issue:
We are implementing hardware-level oversampling on a LAUNCHXL-F28379D development board to capture phase currents at a 20kHz control frequency (50µs execution window). Our design requires a factor-8 oversampling mechanism to filter noise from the analog feedback lines before feeding a motor control algorithm.
To achieve this, our initialization code configures ADC-C (Phase A) and ADC-B (Phase B) to run in Burst Mode with a burst size of 8 samples, triggered via ePWM1 SOCA (Trigger 5). The Post-Processing Blocks (PPB1) are mapped to capture the accumulated results.
Our driver configuration file establishes the following baseline mapping:
  • Phase B (Ib): Handled by ADC_B, pin ADCIN2. It is mapped to SOC0 with an active hardware trigger (TRIGSEL = 5U, ePWM1 SOCA).
  • Phase A (Ia): Handled by ADC_C, pin ADCIN2. In our hardware driver, this physical pin is mapped to both SOC0 (TRIGSEL = 5U, ePWM1 SOCA) and SOC2 (TRIGSEL = 0U, software/disabled trigger).
The Core Failure:
The project compiles cleanly with zero warnings or errors. However, at runtime, as soon as the execution loop begins, the ADCPPB1RESULT registers for both modules read completely dead (absolute 0), regardless of whether we map the PPB to track SOC0 or SOC2.
If we completely disable the custom Burst Mode initialization code block and read the normal ADCRESULT0 registers, the analog feedback signals return instantly and track the motor currents perfectly.
The configuration code is executed within the EALLOW-protected initialization phase. What are we missing or misconfiguring in the hardware sequence that causes the oversampled result registers to remain stalled at zero when Burst Mode is active?
Initialization Code Segment:
c
void init_ADC_Burst_Oversampling(void)
{
    EALLOW;

    // 1. Configure Burst Mode and link master trigger to ePWM (Trigger 5)
    AdccRegs.ADCBURSTCTL.bit.BURSTSIZE = 7;     // Take 8 burst samples (Factor-8 requirement: N+1)
    AdccRegs.ADCBURSTCTL.bit.BURSTRIGSEL = 5;  // Trigger source: ePWM1 SOCA
    AdccRegs.ADCBURSTCTL.bit.BURSTEN = 1;       // Enable Burst Mode globally for ADC-C

    AdcbRegs.ADCBURSTCTL.bit.BURSTSIZE = 7;     // Take 8 burst samples (Factor-8 requirement: N+1)
    AdcbRegs.ADCBURSTCTL.bit.BURSTRIGSEL = 5;  // Trigger source: ePWM1 SOCA
    AdcbRegs.ADCBURSTCTL.bit.BURSTEN = 1;       // Enable Burst Mode globally for ADC-B

    // 2. Bind Post-Processing Blocks to respective asynchronous channels
    // Note: We have tested both CONFIG = 2 and CONFIG = 0 for ADC-C due to dual-pin mapping. Both result in 0.
    AdccRegs.ADCPPB1CONFIG.bit.CONFIG = 0;     // Link ADC-C PPB1 to SOC0 (Phase A)
    AdccRegs.ADCPPB1CONFIG.bit.TWOSCOMP = 0;   // Unsigned standard format
    AdccRegs.ADCPPB1OFFREF = 0;                 // Clear hardware calibration offsets

    AdcbRegs.ADCPPB1CONFIG.bit.CONFIG = 0;     // Link ADC-B PPB1 to SOC0 (Phase B)
    AdcbRegs.ADCPPB1CONFIG.bit.TWOSCOMP = 0;   // Unsigned standard format
    AdcbRegs.ADCPPB1OFFREF = 0;                 // Clear hardware calibration offsets

    EDIS;
}
Use code with caution.
 
Runtime Readout Sequence (inside the 20kHz main interrupt loop):
c
// Reading from the respective PPB result buffers
// A factor of 0.125f (1/8) scaling is applied downstream to resolve the 8x accumulation average.
uint32_t Ia_raw = AdccResultRegs.ADCPPB1RESULT.bit.PPBRESULT; // Stalled at 0
uint32_t Ib_raw = AdcbResultRegs.ADCPPB1RESULT.bit.PPBRESULT; // Stalled at 0
Use code with caution.
 
Specific Technical Inquiries for TI Support:
  1. When BURSTEN = 1 and BURSTTRIGSEL = 5 (ePWM), does the burst engine always start converting from SOC0 through SOC7 sequentially regardless of the individual ADCSOCxCTL.bit.TRIGSEL settings? If so, why does ADCPPB1RESULT stay at 0 when CONFIG = 0?
  2. Does enabling global Burst Mode require us to manually disable or clear the base ADCSOCxCTL.bit.TRIGSEL configurations for our active channels, or should they be left pointing to 5U?
  3. Is there a specific clock gate, interrupt flag, or timing constraint within the F28379D round-robin state machine that causes the PPB result registers to latch/freeze at zero if a hardware ePWM trigger arrives while a burst sequence is executing?

   The C file without PPB Oversampling 

Hardware Platform: LAUNCHXL-F28379D (Delfino F28379D LaunchPad)
Part Number: TMS320F28379D
Toolchain / IDE: Code Composer Studio (CCS) v12
Compiler: TI v22.6.0.LTS
Description of Issue:
We are implementing hardware-level oversampling on a LAUNCHXL-F28379D development board to capture phase currents at a 20kHz control frequency (50µs execution window). Our design requires a factor-8 oversampling mechanism to filter noise from the analog feedback lines before feeding a motor control algorithm.
To achieve this, our initialization code configures ADC-C (Phase A) and ADC-B (Phase B) to run in Burst Mode with a burst size of 8 samples, triggered via ePWM1 SOCA (Trigger 5). The Post-Processing Blocks (PPB1) are mapped to capture the accumulated results.
Our driver configuration file establishes the following baseline mapping:
  • Phase B (Ib): Handled by ADC_B, pin ADCIN2. It is mapped to SOC0 with an active hardware trigger (TRIGSEL = 5U, ePWM1 SOCA).
  • Phase A (Ia): Handled by ADC_C, pin ADCIN2. In our hardware driver, this physical pin is mapped to both SOC0 (TRIGSEL = 5U, ePWM1 SOCA) and SOC2 (TRIGSEL = 0U, software/disabled trigger).
The Core Failure:
The project compiles cleanly with zero warnings or errors. However, at runtime, as soon as the execution loop begins, the ADCPPB1RESULT registers for both modules read completely dead (absolute 0), regardless of whether we map the PPB to track SOC0 or SOC2.
If we completely disable the custom Burst Mode initialization code block and read the normal ADCRESULT0 registers, the analog feedback signals return instantly and track the motor currents perfectly.
The configuration code is executed within the EALLOW-protected initialization phase. What are we missing or misconfiguring in the hardware sequence that causes the oversampled result registers to remain stalled at zero when Burst Mode is active?
Initialization Code Segment:
c
void init_ADC_Burst_Oversampling(void)
{
    EALLOW;

    // 1. Configure Burst Mode and link master trigger to ePWM (Trigger 5)
    AdccRegs.ADCBURSTCTL.bit.BURSTSIZE = 7;     // Take 8 burst samples (Factor-8 requirement: N+1)
    AdccRegs.ADCBURSTCTL.bit.BURSTRIGSEL = 5;  // Trigger source: ePWM1 SOCA
    AdccRegs.ADCBURSTCTL.bit.BURSTEN = 1;       // Enable Burst Mode globally for ADC-C

    AdcbRegs.ADCBURSTCTL.bit.BURSTSIZE = 7;     // Take 8 burst samples (Factor-8 requirement: N+1)
    AdcbRegs.ADCBURSTCTL.bit.BURSTRIGSEL = 5;  // Trigger source: ePWM1 SOCA
    AdcbRegs.ADCBURSTCTL.bit.BURSTEN = 1;       // Enable Burst Mode globally for ADC-B

    // 2. Bind Post-Processing Blocks to respective asynchronous channels
    // Note: We have tested both CONFIG = 2 and CONFIG = 0 for ADC-C due to dual-pin mapping. Both result in 0.
    AdccRegs.ADCPPB1CONFIG.bit.CONFIG = 0;     // Link ADC-C PPB1 to SOC0 (Phase A)
    AdccRegs.ADCPPB1CONFIG.bit.TWOSCOMP = 0;   // Unsigned standard format
    AdccRegs.ADCPPB1OFFREF = 0;                 // Clear hardware calibration offsets

    AdcbRegs.ADCPPB1CONFIG.bit.CONFIG = 0;     // Link ADC-B PPB1 to SOC0 (Phase B)
    AdcbRegs.ADCPPB1CONFIG.bit.TWOSCOMP = 0;   // Unsigned standard format
    AdcbRegs.ADCPPB1OFFREF = 0;                 // Clear hardware calibration offsets

    EDIS;
}
Use code with caution.
 
Runtime Readout Sequence (inside the 20kHz main interrupt loop):
c
// Reading from the respective PPB result buffers
// A factor of 0.125f (1/8) scaling is applied downstream to resolve the 8x accumulation average.
uint32_t Ia_raw = AdccResultRegs.ADCPPB1RESULT.bit.PPBRESULT; // Stalled at 0
uint32_t Ib_raw = AdcbResultRegs.ADCPPB1RESULT.bit.PPBRESULT; // Stalled at 0
Use code with caution.
 
Specific Technical Inquiries for TI Support:
  1. When BURSTEN = 1 and BURSTTRIGSEL = 5 (ePWM), does the burst engine always start converting from SOC0 through SOC7 sequentially regardless of the individual ADCSOCxCTL.bit.TRIGSEL settings? If so, why does ADCPPB1RESULT stay at 0 when CONFIG = 0?
  2. Does enabling global Burst Mode require us to manually disable or clear the base ADCSOCxCTL.bit.TRIGSEL configurations for our active channels, or should they be left pointing to 5U?
  3. Is there a specific clock gate, interrupt flag, or timing constraint within the F28379D round-robin state machine that causes the PPB result registers to latch/freeze at zero if a hardware ePWM trigger arrives while a burst sequence is executing?

The C file attached has no PPB Factor-8 Oversampling, it works fine. PPB failed to work after we add the above code.