Change in LPADC_GetConvResult (driver fsl_lpadc) from SDK 2.13 to 2.14

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

Change in LPADC_GetConvResult (driver fsl_lpadc) from SDK 2.13 to 2.14

Jump to solution
3,119 Views
MartinHo
Contributor IV

Hi,
I have noticed that the function LPADC_GetConvResult() has been change in SDK 2.14 (LPADC Version 2.6.2).
I think that the change is not congruent with the function declaration, as the new code will return true, or will stuck for ever (if the FIFO is empty).
The old function returned false in case the FIFO was empty.

I’m calling LPADC_GetConvResult() inside an interrupt function so a possible endless loop is very bad.

Please revert to the "original" behavior in your next release.

Best regards

Martin

Tags (1)
1 Solution
3,068 Views
RaRo
NXP TechSupport
NXP TechSupport

Hello @MartinHo,

We are letting the team in charge to know about this, explaining the possible endless loop that it could be obtained like you mentioned.

Thanks for the feedback.

Best regards, Raul.

View solution in original post

0 Kudos
Reply
10 Replies
2,767 Views
PhilV
Contributor III

I too have hit this same issue today, I am using the LPC55S69 and code that worked fine on a previous project was hanging on my new project, I finally tracked it down to the change in SDK, and sure enough, that breaking code change - Its not even mentioned in the SDK release notes.

I have a while loop that kept retrieving results until the LPADC_GetConvResult returned false, at which point I knew the FIFO was empty. Now my code hits that call and hangs.

As mentioned by someone else, the code change means the function doesn't even operate as per the embedded documentation anymore:

/*!
 * brief Get the result in conversion FIFOn.
 *
 * param base LPADC peripheral base address.
 * param result Pointer to structure variable that keeps the conversion result in conversion FIFOn.
 * param index Result FIFO index.
 *
 * return Status whether FIFOn entry is valid.
 */
bool LPADC_GetConvResult(ADC_Type *base, lpadc_conv_result_t *result, uint8_t index)
{
    assert(result != NULL); /* Check if the input pointer is available. */

    uint32_t tmp32 = 0;

    while (0U == (ADC_RESFIFO_VALID_MASK & tmp32))
    {
        /* while loop until FIFO is not empty */
        tmp32 = base->RESFIFO[index];
    }

Quite how it got through a code review I don't know...

@danielholala - You mentioned "according to github" - where is the github for the SDK code, and who contributes? - Thanks.

2,719 Views
danielholala
Senior Contributor II

@PhilV ,

Thanks for sharing.

The MCUX SDK can be found here:

https://github.com/nxp-mcuxpresso/mcux-sdk/tree/main

and this driver can be found here:

https://github.com/nxp-mcuxpresso/mcux-sdk/blob/main/drivers/lpadc/fsl_lpadc.c

I did not check if this is exactly the code running in my device specific SDK. Note that there are subdirectories for every CPU which may change or replace the "general" drivers:

https://github.com/nxp-mcuxpresso/mcux-sdk/tree/main/devices

Hope that helps.

2,703 Views
PhilV
Contributor III
Many thanks, very useful, and for anyone else who comes across this, this is the open bug ticket to get it fixed:
https://github.com/nxp-mcuxpresso/mcux-sdk/issues/138
0 Kudos
Reply
2,958 Views
danielholala
Senior Contributor II

Hi @MartinHo ,

Thanks for sharing your important observation. I found the same code issue in the LPC5528 SDK.

Personal opinion: After each update of the IDE or SDK, I feel  sort of (ab)used as a external software quality assurance engineer for NXP. Has NXP laid off all of its QA staff?

 

0 Kudos
Reply
3,092 Views
JorgeCas
NXP TechSupport
NXP TechSupport

Hello, I hope you are doing well.

Could you please share the device you are using?

Best regards.

0 Kudos
Reply
3,081 Views
MartinHo
Contributor IV

Hi,

I'm using a LPC5504, but the driver seems to be used in a lot of different MCU's.

Martin

0 Kudos
Reply
2,939 Views
RaRo
NXP TechSupport
NXP TechSupport

Hello @MartinHo,

Just to let you know, we have the following answer from internal team. "For current version, we suggest calling the function LPADC_GetConvResultCount before calling LPADC_GetConvResult to ensure it does not enter an infinite loop. In future version, this function will return to the style of the previous (2.13) version."

Best regards, Raul.

Tags (1)
2,869 Views
danielholala
Senior Contributor II

Hi @RaRo ,

according to GitHub, "the change to the function LPADC_GetConvResult is due to the needs of the NXP Connectivity Team

Now why didn't the "NXP Connectivity Team" change their software to call LPADC_GetConvResultCount in a while loop instead? I assume that this would have been a lot less trouble for everybody else.

I wonder who controls your software development process. 🧂

Thanks.
Daniel

 

0 Kudos
Reply
2,852 Views
RaRo
NXP TechSupport
NXP TechSupport

Hello @danielholala,

We apologize for the inconvenient. Fortunately, thanks to the feedback, this function will return to the previous version.

Best regards, Raul.

0 Kudos
Reply
3,069 Views
RaRo
NXP TechSupport
NXP TechSupport

Hello @MartinHo,

We are letting the team in charge to know about this, explaining the possible endless loop that it could be obtained like you mentioned.

Thanks for the feedback.

Best regards, Raul.

0 Kudos
Reply