AM6442: Freertos Ethernet Programmable Forced Speed and Duplex on power-up

No, looking for being able to change the speed and duplex different on every power-up based on the customers need. It needs to be able to be changed at run time, not at compile time.  Goal actually would be to be able to change the speed and duplex at any time, then tell the PHY to resync, and now be connected at the new speed and duplex.

Robert

Hi

This can be achieved by following a sequence of steps to bring the port down, then update the internal handles to update the PHY Link configuration, and bringing the port up again. I would like to understand the usecase where the customer wants to change the speed and duplexity during runtime, to a fixed link instead of using auto negotiation. Can you please provide more details on that so we can provide better fitting solution for the requirements?

Currently, since there is no support to update the link config during runtime, the user have to close the PHY handle, and update the link config before re-opening the PHY again with updated link speed and duplexity. There are other possible methods which involves adding additional APIs to the enetphy layer which are not tested from our end. Based on the requirements, we can suggest any other options possible.

Regards,
Teja.

As we produce industrial controls, often our customers like to lock everything down at the switch, (i.e. what is connected to what port on the switch and the speed and duplex. They do this as a security issue, if something that is not supposed to on a port they can shut the port down.) 

The port speed/duplex does not need to be changed on the fly, just on power-up, but the setting are not known at compile time.  There is a great structure in the autogenerated file "ti_enet_open_close.c" that would work great except it is static, and unable to get to it. I really hate to modify generated code as any updates/fixes may break the code at a later date. May I make a suggestion for later version would be to make "static const EnetAppInstInfo_LinkCfg enetAppMacPortLinkCfg[]" not a "static const".  That way updates could be done before the stack comes up and everything works as expected.

Robert

Hi Robert, 

I will take this feedback to the development team. Meanwhile, you can try the above mentioned method. Since the macport configuration has to be updated as well, I'll need some work on handling this usecase. I'll update you back on this by Monday since the following 2 days are public holidays in India. 

Thanks for your patience. Please let me know if this timeline doesn't work for you. We shall try to find an alternative.

Regards,
Teja.