[BUG] - ADC polling LPADC_GetConvResult

[AndreaRuberti]

Describe the bug
Last implementation of function LPADC_GetConvResult does not allow correct polling management.

To Reproduce

• Environment:
  • Tag/Commit hash: MCUX_2.14.0 - fsl_lpadc.c/.h
  • Toolchain: ARMGCC 12.1
  • Board/SoC: LPC5506 on Custom board.
  • Example: temperature_measurement (original source from SDK 2.13), lpadc_polling (SDK 2.14)
• Steps to reproduce the behavior:
  • Just execute the polling example without the LPADC_DoSoftwareTrigger.
  • execute "temperature_measurement" example from SDK 2.13 and comment LPADC_DoSoftwareTrigger.

Expected behavior
In polling management, function LPADC_GetConvResult should return false in case of not ready value (as in previous SDK 2.13).
The 2.14 implementation provide a WHILE loop inside the function that could "stop" the program execution if no data ready.
Furthermore, if no LPADC_DoSoftwareTrigger are execute and no WDOG is started... the system loop forever inside LPADC_GetConvResult fx.

Screenshots and console output
none

Additional context

• Temporay solution for data polling:
  • without lib changes: add/test if (ADC_RESFIFO_VALID_MASK & base->RESFIFO) before LPADC_GetConvResult
  • with lib Changes: replace fsl_lpadc.c/.h from older SDK 2.13 version.

[mcuxsusan]

Thanks for reporting the issue, already asked development team to check, reply could be delayed.

[ZhaoxiangJin]

Hi @AndreaRuberti, in MCUX-SDK 2.14 version, the change to the function LPADC_GetConvResult is due to the needs of the NXP Connectivity Team and has been reverted, in the MCUX-SDK release version after the connectivity branch merges back, the implementation of this function will return to the style of the previous version. We recommend calling the function LPADC_GetConvResultCount before calling the function LPADC_GetConvResult to ensure that it does not enter an infinite loop (in fact, such a calling flow is more reasonable).

[herrmanthegerman]

... in MCUX-SDK 2.14 version, the change to the function LPADC_GetConvResult is due to the needs of the NXP Connectivity Team ...

I don't understand. Are you saying that "due to the needs of the NXP Connectivity Team", you are providing an implementation that

• likely breaks existing software
• is not reflected in any documentation, not even in the doxygen comment of the function?

I think that is no adequate software quality management.

I wonder if there are similar changes hidden somewhere else in SDK 2.14?

[ZhaoxiangJin]

Hi @herrmanthegerman, Sorry that the impact of this change was not fully considered during development, and the current test case hasn't covered the behavior change issue. We will add a test case for it. We have checked the changed parts of the driver in MCUX-SDK version 2.13.1 and 2.14, there are no other similar changes hidden in the driver. We will create a patch ASAP to change the function LPADC_GetConvResult back and add a new API LPADC_GetConvResultBlocking which waits until the conversion is done. Thank you for your feedback.

[herrmanthegerman]

We have checked the changed parts of the driver in MCUX-SDK version 2.13.1 and 2.14, there are no other similar changes hidden in the driver. Thank you for your feedback.

Thanks @ZhaoxiangJin. Just to avoid any misunderstanding: Regarding "similar changes", I was referring to all drivers (see directory drivers/) not only the ADC driver. So which drivers did you check? Thank you for your support.

[mcuxsusan]

Hi @herrmanthegerman, for your information, the team has checked all driver change under the drivers/ folder and confirmed that no similar issue for other drivers.

[mcuxsusan]

Hi, I will close the issue for now. The fix has been applied to latest main branch, please see 1d72f41.