2388126_en-US

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

2388126_en-US

2388126_en-US

ADC Configuration Issue

Hi @Senlent ,

I have also same issue which you mentioned above.

Our external oscillator clock is 25 MHz. According to the S32K322 datasheet, the ADC supports up to 80 MHz, so I have configured a prescaler of 2. I also configured the sampling time to 1.2 microseconds and set the BCTU mode to trigger mode. However, we are still getting noisy data when executing the BCTU method and the normal chain method simultaneously on the same ADC0 peripheral. Is there a workaround or an alternative method to safely run both on the same ADC0 peripheral?

praveen_ext_0-1782473167287.pngpraveen_ext_1-1782473350906.pngpraveen_ext_2-1782473423830.png

S32 SDK for S32K1Re: ADC Configuration Issue

Hello @praveen_ext ,

Considering the previous Community thread, the behavior in BCTU Control Mode is expected: when the ADC is controlled by BCTU in Control Mode, normal conversions cannot be started independently on the same ADC instance. This explains why the current sensing becomes more stable in Control Mode, but the voltage and temperature channels configured in the normal chain stop working.

In Trigger Mode, the situation is different. This mode allows BCTU-triggered conversions as well as normal/injected conversions, but all these conversions still share the same ADC instance and therefore the same ADC conversion resources. For a time-critical current sensing use case, especially if synchronized with PWM, the important point is not only whether the conversion is possible, but also whether the sampling instant remains deterministic.

From the shared data, the current-sense signal seems mostly stable, but it shows occasional large spikes/dropouts. These do not look like ordinary random analog noise only. They look more like event-related outliers, possibly caused by conversion scheduling, result handling or interaction between the BCTU-triggered conversions and the normal chain conversions on the same ADC peripheral.

Therefore, I would suggest first isolating whether the issue is caused by the mixed use of the ADC instance:

1. Please run only the BCTU-triggered current sensing in Trigger Mode and completely disable the normal chain execution.

   - Do the current-sense spikes still occur?

2. Please run only the normal chain conversions and disable the BCTU-triggered current sensing.

   - Are the voltage and temperature channels still stable?

3. Please check whether the current-sense spikes correlate with the moment when the normal chain conversion is started by the application. 

Could you also clarify how the normal chain conversion is started while the BCTU-triggered current sensing is running? For example, is the normal chain started periodically by software, from an interrupt or from another scheduler task?

One more point to confirm: from your channel list, ADC1-P2 and ADC1-P3 seem to be mentioned both as BCTU current-sensing channels and as normal-chain channels. Could you please confirm whether these channels are intentionally used by both acquisition methods or if this is only a description/configuration mismatch?

 If the spikes disappear when the normal chain is disabled, then the likely issue is not the ADC electrical configuration itself, but the timing/scheduling of two acquisition flows on the same ADC instance. In that case, possible workarounds would be:

- keep the current-sensing channels exclusively under BCTU control,

- move the slower voltage/temperature measurements to another ADC instance, if available,

- or schedule the normal chain conversions only in a time window where they cannot interfere with the BCTU/PWM-synchronized current measurement.

 

After this isolation test, it is still recommended to check the analog front-end, especially for the continuously noisy signals:
- source impedance of the measured signal,
- external RC filter values,
- ADC input capacitor value,
- capacitor placement close to the MCU ADC input pin,
- whether the configured sampling time is sufficient for the given source impedance and external components.

 

Similar ADC accuracy/noise-related discussions are available here:
- Issue with Inaccurate ADC Values on S32K3:

 

- Smoke detector interfacing with FS32K146HAT0MLLT:

 

- S32K3 Confusion about ADC accuracy and results:

 

Best regards,

Pavel

Tags (1)
No ratings
Version history
Last update:
2 hours ago
Updated by: