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
已解决! 转到解答。
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.
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
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.
@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.
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?
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.
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
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.