AM13E23019: Missing PPB offset correction

Hi Oleksandr,

Thank you for bringing this to our attention and for your report — this is a great catch.

After further review, I can confirm that PPB Offset Correction is indeed supported on the AM13E230x device. The ADCOFFTRIM register (Offset = E8h, Section 15.12.2.35) is present in the TRM and is the register used to apply the offset correction value.

It appears the disconnect is that while the hardware and register support exist, the corresponding driverlib API may not yet be implemented for AM13E2x. I am looking into this further and will follow up once I have a confirmed answer on driverlib support and timeline.

In the meantime, as a workaround, you should be able to directly write to the ADCOFFTRIM register using register-level access to apply your desired offset correction value, bypassing the need for a driverlib API call.

Could you confirm which SDK version you are currently using? This will help us investigate the driverlib gap more accurately and provide you with the most relevant guidance.

Apologies for any confusion, and thank you again for your patience. Please let me know if you have any additional questions in the meantime.

Best Regards,

Zackary Fleenor

Thank you for the response, Zackary!

But isn't ADCOFFTRIM used to configure "15.11.10 ADC Zero Offset Calibration" -- a single calibration value that will apply for all ADC measurements, not for a single SOC? TRM also says that the value is "determined and calibrated during factory testing", so ideally, we would not want to change it to have precise measurements.
I'm not sure if that's what we are looking for. Or did I misunderstood something from the manuals?

We are an older version of SDK as of today -- 01.00.00.EA2.

And driverlib on this version contains API to work with ADCOFFTRIM, e.g.: 

However, when comparing against 26.00.00.06 -- it seems that these functions were removed:

Just an interesting observation, we are not using them, so it shouldn't be an issue for us.

BR,
Oleksandr

Hi Oleksandr,

Thank you for the correction and the thorough follow-up — you are absolutely right, and I apologize for the confusion in my previous response. ADCOFFTRIM and PPB Offset Correction are two distinct features, and I incorrectly conflated them. Let me address each point properly.

ADCOFFTRIM (Section 15.11.10) is a global offset calibration register that applies a single correction value across all ADC conversions. As you noted, this value is factory-calibrated during boot, and modifying it would compromise measurement accuracy across all channels — it is not a substitute for PPB Offset Correction.

PPB Offset Correction (Section 15.6.1) operates on a per-SOC basis via the ADCPPBxOFFCAL.OFFCAL registers and is intended specifically for removing channel-level offsets introduced by external sensors or sources, with zero software overhead.

After further review, I can confirm that this is a genuine inconsistency in the TRM. While Section 15.6.1 describes the PPB Offset Correction feature and the datasheet lists it as a supported PPB capability, the ADCPPBxOFFCAL register definitions appear to be missing from the TRM register map chapter, and the corresponding driverlib APIs are absent in SDK 26.00.00.06. I have escalated this internally to get clarification on the following:

1. Whether the ADCPPBxOFFCAL registers are present in silicon but simply undocumented in the current TRM revision, and if so, what their addresses are
2. Whether an errata or TRM correction is planned to address this discrepancy
3. Whether the removal of ADCOFFTRIM-related driverlib APIs between SDK 01.00.00.EA2 and 26.00.00.06 was intentional

I will follow up as soon as I have confirmed answers on these points.

In the meantime, a potential hardware workaround worth evaluating is the PPB Error Calculation feature (Section 15.6.2), which is fully documented. Using the ADCPPBxOFFREF.OFFREF register, you can subtract a per-SOC reference value from the raw conversion result, with the output stored in ADCPPBxRESULT as a sign-extended 32-bit value. The key distinction from OFFCAL is that this produces a separate PPBxRESULT rather than modifying ADCRESULT directly. If reading from PPBxRESULT is acceptable for your application, this would provide per-SOC offset subtraction in hardware without software overhead and without touching the factory-calibrated ADCOFFTRIM value.

Again, I apologize for the initial misdirection, and I appreciate your patience and diligence in working through the documentation. Please let me know if you have any additional questions in the meantime.

Best Regards,

Zackary Fleenor

Hi Zackary!

1. We are not blocked and are using a software-based implementation for now.

2. I'm not sure that we will gain much from using PPB Error Calculation feature, as ADC results are transferred with DMA from ADCRESULT0-ADCRESULTX registers. Having a sub-set of channels available in PPBxRESULT would require additional steps to read data from there (and safely sync this reading with DMA IRQ), which might nullify the benefit of the HW-based simple math operation.

3. The software approach fits for now, but in the future, we might start looking for opportunities to improve performance as we do for the other controllers by utilizing HW-features.

BR,
Oleksandr

Hi Oleksandr,

Thank you for the detailed update and for clarifying your current implementation approach.

Best Regards,

Zackary Fleenor