Bug in S32K SDK clock callback recovery code

[nathand]

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.

[lukaszadrapa]

Hi Nathan,

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

Regards,

Lukas