STM32U585OIY6QTR ADC reading garbage values

[Francis_Fu]

I am planning to do an aging test which need capture the voltage of a net, but i found STM32U585OIY6QTR report a value about 40 while the actual voltage of ADC channel is close to VREF.

Then i write a simple ADC demo to verify ADC configuration, and run my code on B-U585I-IOT02A board(based on STM32U585AII6Q), it report a correct value, but the same code report a wrong value on my board.I use ADC1  CHANNEL2(GPIOC GPIO_PIN_1) on both board.

The only difference between B-U585I-IOT02A and my hardware is the different VREF i think(B-U585I-IOT02A use 3.3V, but my board use 2.5V).

Is there any difference on ADC usage between STM32U585AII6Q and STM32U585OIY6QTR?

You can find my ioc file and code in attachment, can anyone help me check my configuration?

[Francis_Fu]

We can read correct internal voltage value, so the ADC not broken.

But the converted VDDA is a strange value 9947mv.

What can we get from this phenomenon?

[jiangfan]

STM32U385 Vrefint=1.215V typ. I suppose you measure Vrefint channel and ADC result is 1979.

So, equation Vrefint / Vdda = ADC_result / 4096, then Vdda = Vrefint * 4096 / ADC_result = 1.215 * 4096 / 1979 = 2.515V.

Vdda=2.515V is in line with your board using 2.5V - ADC seems to work fine.

[jiangfan]

VREFINT_CAL: 14-bit raw data acquired by ADC1 at 30 °C (± 5 °C), VDDA = VREF+ = 3.0 V (± 10 mV), with Memory address 0x0BFA 07A5 - 0x0BFA 07A6.

maybe VREFINT_CAL is not correct, to be clarified.

[Francis_Fu]

Thanks your reply, after modify the formula, we get correct VDDA value.

But the other external channel still have a low and fixed value which don't change according to actual voltage.

[Francis_Fu]

I have verified that when use the ADC channel pin as GPIO, it can be toggled. So the gpio is not damaged.

The other channel of ADC1 and ADC4 are also can not get correct value except the internal channel like REFINT.

[jiangfan]

Did you use TrustZone security (TZEN = 1) ?

[Francis_Fu]

I didn't enable Trustzone.

[jiangfan]

What we know from the 4 points

1.Same code works on ST board (B‑U585I‑IOT02A) but not on your board

⇒ Software + ADC configuration are basically correct.

2.Toggling PC1 on your board works

⇒ The digital function of PC1 is OK; the pin is not dead.

NOTE: assume you use almost the same configuration as the one for ADC configuration

NOTE: assume you can see PC1 toggling at desired LOW/HIGH (0V, Vdd) level and at specified toggle rate (low rate Hz level, high rate kHz level)

3.ADC conversion of internal channels (e.g. REFINT) on your board is correct

⇒ ADC peripheral itself is OK; the issue is specific to the external analog input path on PC1.

4.TrustZone is not enabled

⇒ Ruling out: obvious TrustZone isolation of ADC/PC1.

So the issue is narrowed down to “external analog input path on PC1 for this package/board”, not ADC IP, not basic firmware, not security.

You may try to read PC1 input, to see if OK to read LOW/HIGH (0/1) input.

Besides, even though you said “same code”, it’s still worth verifying:

• PC1 is set to analog mode (not left in digital input with pull‑up/pull‑down).
• No stray code reconfigures PC1 after ADC init (e.g. board support package, CubeMX init for other features).
• Low‑power modes / SMPS / booster / trustzone are not re‑configuring the pin:
  For example, check that no low‑power configuration disables the analog pad or re‑routes PC1.

[Mike_ST]

Hello,

>> "The only difference between B-U585I-IOT02A and my hardware is the different VREF i think(B-U585I-IOT02A use 3.3V, but my board use 2.5V)."

In your code I see :

/* Value of analog reference voltage (Vref+), connected to analog voltage */
/* supply Vdda (unit: mV). */
#define VDDA_APPLI (3300UL). Maybe you have to update to #define VDDA_APPLI (2500UL)

Another thing I see in the code, is that the ADC1 input frequency is on the low end (HSI16 / ADC presc 2 = 8MHz). Too high or too low frequency may give wrong reading, don't know if this is the case here, but please check the STM32U585 datasheet.

[Francis_Fu · Accepted solution]

Thanks you for the reminder.

Finally, i found the root cause. I use the "erase full chip memory" function of Cube programmer to restore all option byte, and didn't check the actual value of TZEN, so TZEN is opened when i did the test. The correct method to close the TrustZone is set RDP first and close TZEN.