Bug in S32K SDK clock callback recovery code

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

Bug in S32K SDK clock callback recovery code

821 Views
nathand
Contributor II

I'm debugging an issue with clock configuration on an S32K148, and I noticed a bug in the recovery code when changing clock configurations fails. The issue is in this code, starting at line 4022 (SDK 4.0.1, same issue exists in earlier versions as well):

    else /* Error occurs, need to send "RECOVER" notification. */
    {
        notifyStruct.notifyType = CLOCK_MANAGER_NOTIFY_RECOVER;
        for(;;)
        {
            callbackConfig = g_clockState.callbackConfig[callbackIdx];
            if (callbackConfig != NULL)
            {
                (void)(*callbackConfig->callback)(&notifyStruct,
                        callbackConfig->callbackData);
            }
            if(callbackIdx == 0U)
            {
                break;
            }
            callbackIdx--;
        }
    }

The problem is that in this code, callbackIdx starts at one more than the number of callbacks. On the first iteration, callbackConfig will probably not be null, but it will point at something that is not actually a callback configuration, leading to a crash when trying to call *callbackConfig->callback()

The actual issue I'm seeing is that CLOCK_SYS_ConfigureSOSC() returns a timeout, which causes the clock configuration code to attempt to recover, triggering this bug in the code. I'm suspecting random bad hardware for my specific problem, since thousands of identical boards running the same code work fine, but I'd welcome ideas as to what would prevent SOSCVLD from being set. Investigating this problem turned up the bug in the code, which I thought was worth reporting here.

Labels (1)
0 Kudos
1 Reply

754 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi Nathan,

thanks for pointing this out, I have already forwarded this to SDK team.

Regards,

Lukas

0 Kudos