Technical Inquiry Regarding Undefined Last Channel in ADC Instance

[dongxun]

Dear Technical Support Team,

I am writing to report an anomaly observed during ADC data acquisition debugging on an S32K312 microcontroller using the ​​Adc_TS_T40D34M20I2R0 MCAL package (SW32K3_RTD_4.4_2.0.2_D2211)​​. The issue pertains to the incorrect definition of the ​​Last Channel​​ in the ADC instance, specifically affecting DMA buffer population under specific configurations.

 ​​Issue Description​​

1. ​​Configuration Context​​:

   • ​​Trigger Mode​​: Hardware-triggered conversion via Timer (1-second interval).
   • ​​Data Transfer​​: DMA-based data transport without interrupt (DMA interrupt handles data movement).
   • ​​Channel Setup​​: Configured multiple channels, with the last channel indexed as ​​Channel 72​​ (as per EB28.2 configuration).
     

2. ​​Observed Behavior​​:

   • The first channel index in the configuration ​​fails to populate the designated DMA buffer​​, despite the ​​PCDR register confirming successful data acquisition​​ (register values match expected analog inputs).
     
   • Debugging reveals that the function Adc_Ipw_CalculateLastChan() — responsible for determining the last converted channel — ​​consistently returns AdcResultLastCh.AdcChnIdx = 0​​ instead of the expected 72.
     

3. ​​Root Cause Analysis​​:

   • In the function Adc_Ipw_CalculateLastChan() (invoked as AdcResultLastCh = Adc_Ipw_CalculateLastChan(Group, ConversionType, CoreId);):
     • The initialization of AdcChnIdx defaults to 0 and ​​never updates to reflect the configured last channel (Channel 72)​​.

Subsequent logic (e.g., DMA buffer assignment) erroneously treats ​​Channel 0 as the last channel​​, causing data for Channel 72 to be skipped in the buffer.

4. Code Modification​​:

Revised Adc_Ipw_CalculateLastChan() to initialize AdcChnIdx with the ​​configured LastCh value (72)​​ instead of 0.

AdcChnIdx = ConfigPtr->LastCh; // Directly use configured last channel index

​​Validation Results​​:

• Post-modification, AdcResultLastCh.AdcChnIdx correctly returns ​​72​​.
• DMA buffer now ​​successfully captures data for all channels​​, including Channel 72.
• 

  Open Questions​​

  1. ​​Potential Oversight​​:

     • Is there a configuration parameter or runtime condition (e.g., group/conversion mode) that should update AdcChnIdx but was missed in our analysis?
     • Does the MCAL design implicitly assume Channel 0 as the last channel in certain modes?

  2. ​​Suspected Bug​​:
     Given that the default initialization (AdcChnIdx = 0) contradicts the configured channel topology, is this a ​​latent bug in the MCAL implementation​​?

  Request for Guidance​​
  • Could you verify whether this behavior aligns with the intended design of Adc_Ipw_CalculateLastChan()?
  • If confirmed as a bug, is there a planned patch for the MCAL package?
  • Alternatively, are there workarounds beyond the described fix?

   Thank you for your expertise and prompt attention to this matter.

  Best reagrds,

[Senlent]

Hi@dongxun

I've taken the time to check the latest RTD versions, and the following changes have been made in RTD 4.0.0 and later, such as RTD 5.0.X and RTD 6.0.x.

This is likely a known and fixed bug. I recommend that you stop using older versions of RTD.

You may encounter new issues later, but these issues may have been fixed in newer versions,

and we don't have the resources to help you reproduce issues with older versions.