I have a custom board with a K66F processor. I have Ethernet functionalities in my firmware. Etherenet control is on a task of its own.
Most of the times/boards will run the firmware without any issues; after the boot, I can PING the board.
Some boards, some rarely some often, boot completely but I can't PING them. Debugging the program, I see that the Ethernet task gets stuck during the PHY initialization, more precisely in this loop in fslphy.c PHY_Init() function
while ((idReg != PHY_CONTROL_ID1) && (counter != 0))
{
PHY_Read(base, phyAddr, PHY_ID1_REG, &idReg);
counter --;
vTaskDelay(100);
}
if (!counter)
{
return kStatus_Fail;
}
idReg is always 0xFFFF (must return 0x7). The counter is initialized to 0xFFFFFU, so basically the loop will go on "forever".
What can be the problem that lead to such behavior?
I've noticed that if I initialize counter to, e.g., 10, the loop terminates and the function returns kStatus_Fail, but then I can communicate via Ethernet without any (apparent) issue; from basic PING to the more elaborate TCP protocol communication of my application.
Is it safe to ignore PHY initialization's errors?
The project is quite old (4 years at least). I don't know the exact SDK version used, but it is from back in those day.
