S32K344 ADC Measurement Discrepancy between PTA2 and PTA3

[autolan22]

Hello everyone,

We are recently debugging the ADC function of PTA2 and PTA3 for voltage monitoring.

So we configured PTA2 and PTA3 as ADC functions, then used a 2k potentiometer to divide the voltage out to 1.6v, shorted the 1.6v to PTA3 and PTA2 respectively, and expected that both PTA2 and PTA3 could accurately measure about 1.6v. 

But the test result is: PTA2 reads about 1.6v, and PTA3 reads about 2.8v. (Whether it is reading the MCU register or using a multimeter to measure the short contact point between the potentiometer and PTA2 or PTA3, the result is the same, so it can be ruled out as a reading error.)

After some attempts, we configured PTA3 as an ADC input and also configured it as a GPIO input as following(Software version: S32DS3.4, RTD 1.0.0).

Then PTA3 can also read the voltage of 1.6v correctly.

Although PTA3 can read the voltage as expected in this strange configuration, 

I still don't know what the specific difference is between the two ports when powered on, and how this difference leads to this voltage difference.

I checked the manual and only found that the direct signals of PTA2 and PTA3 are different.

Will there be other risks in how to configure it?

Thank you for taking the time to review this issue.

Best regards

[PavelL]

Hi,

It is not recommended to jump off from bootloader directly but used SW reset and jump into application code before an initialization. Looking to S32K344_S32K324_S32K314_IOMUX.xlsx, E16 looks HiZ by default, so nothing to configure.

Best regards,

Pavel

[autolan22]

Hi,

As we understand it, when configuring PTA3 solely for ADC functionality using the pin tool in S32DS and generating code, the tool does not include a PTA3 configuration structure inside the generated `const Siul2_Port_Ip_PinSettingsConfig g_pin_mux_InitConfigArr0[NUM_OF_CONFIGURED_PINS0]`.

Therefore, during initialization using `g_pin_mux_InitConfigArr0` in the application, no pin-related initialization for PTA3 will occur.

Given this situation, should we still consider configuring PTA3 using the pin tool in S32DS?

Is there information available on whether future versions of S32DS will address this functionality?

Best regards,
Lan

[PavelL · Accepted solution]

Hi,

Still, I would recommend the way with SW reset.
Set a flag e.g to RAM that application shall run without bootloader after next SW resets. Bootloader checks this flag and jump into application instantly, without any unwanted initialization.
Alternatively, if there is no “de-init” procedure in RTD, you should do “de-init” manually. But you never know if something styed initialized. In my opinion, the way with SW reset is bulletproof.

Best regards,

Pavel

[autolan22]

Hi Pavel,

Thank you for your helpful response on the forum. It effectively resolved my confusion. Have a great day!

Best regards,

Lan

[PavelL]

Hi,

in your screenshot, I see enabled pullup on E16. Please try set GPIO's "Pullup Enable" to disable.

Best regards,

Pavel

[autolan22]

Hi,

I tried to disable the GPIO's "Pullup Enable," but it didn’t work.

Further investigation revealed that the issue arose because PTA3 was configured as the UART TX pin in the bootloader. During the transition from bootloader to application, the PTA3-ADC configuration failed to properly override the previous PTA3-UART TX settings.

This override failure occurred because when configuring PTA3 solely for ADC function in S32DS and generating code, the tool does not include a PTA3 configuration structure inside the generated

const Siul2_Port_Ip_PinSettingsConfig g_pin_mux_InitConfigArr0[NUM_OF_CONFIGURED_PINS0]

.

Consequently, during initialization using `g_pin_mux_InitConfigArr0` in application, PTA3 is not reconfigured.

In contrast, if we configure PTA3 for GPIO input function and generate code, S32DS generates a configuration structure for PTA3.

Currently, the best solution I can think of is:
1. Configuring pins used as ADC to be both GPIO inputs and ADC functions.
2. Restoring all configurations to their default settings before the bootloader jumps to the application.

However, we haven't found a function in the RTD library that deinitializes all GPIO configurations.

Is there a better method or a register that can reset all configurations (not only GPIO) without resetting the MCU?

Since the MCU always starts from the bootloader and then transitions into the application, resetting the MCU won’t effectively reset all configurations needed for the application in this case.

Best regards,
Lan