Setting ipconfigETHERNET_AN_ENABLE to 0 didn’t change anything (btw, I didn’t see in the code any use of this macro, it only changes whether some struct variables are used or not).
I have the datasheet, but I can’t publish it here because it’s under NDA.
ipconfigETHERNET_AN_ENABLE affects the xPHYProperties configuration.
I have the datasheet
Then you might try debugging, as I suggested in the previous post.
I looked more closely in the code of my working platform (the one with Keil libraries), and read a bit in the datasheet, and it seems there is no way that FreeRTOS’s implementation can work with MV88E6071, because its PHY registers are not directly accessible. You need to use special command and data registers access procedure to read/write them.
True, but normally there are encapsulation functions such as ReadPhyReg that you can use in your code.
@RAc
There is a function in the FreeRTOS+TCP - vMACBProbePhy():
void vMACBProbePhy( void )
{
vPhyInitialise( &xPhyObject, xSTM32_PhyRead, xSTM32_PhyWrite );
xPhyDiscover( &xPhyObject );
xPhyConfigure( &xPhyObject, &xPHYProperties );
}
As you can see - xSTM32_PhyRead() and xSTM32_PhyWrite() are the encapsulation functions. These functions just use STM32 ETH HAL functions.
In order to work with MV88E6071, I need to rewrite xSTM32_PhyRead() and xSTM32_PhyWrite() to use indirect register access. But if I do it, this implementation will work only with MV88E6071 and xPhyDiscover() will fail.
In my first response, I asked whether you are using a supported PHY to which you responded yes. I am confused. What made you think earlier that the port you use supports that PHY when now it appears that you are using a hardware NOT supported by the port?
Pleaese note that a PHY is not tightly coupled to a port. A PHY is a separate chip for which a specific driver is required.
@RAc
As I’ve mentioned before, my knowledge of PHYs is close to zero.
I assumed that my PHY is supported after @tony-josi-aws told me to look in phyHandling.c , where I saw a definition of PHY_ID_MV88E6071, and also xPhyDiscover() returned 4, which, as Tony said, means that
From my reviewing of the code, the way FreeRTOS+TCP implements access to a PHY is not chip specific, but it accesses “general registers”, which are supposed to be on every supported PHY (and they are also present on MV88E6071, but not with direct access) , and configures theses supported PHYs using those general registers.
without access to the PHY chip documentation, there is not a whole lot to add at this point, I am afraid. Have you tried contacting Marvell support to find out if they have working sample code for FreeRTOS? Alternatively you could check whether any commercially available board that uses the same PHY has such code.
I guess that’s the next thing to do. This chip is rather old, it doesn’t even appear on their website. I hope they will support it.
After rewriting the above functions, I’ve managed to receive eNetworkUp event in the vApplicationIPNetworkEventHook_Multi() callback.
Does this mean that the network is up and running?
I have the ipconfigREPLY_TO_INCOMING_PINGS defined to 1 but the board doesn’t reply to ping requests.
What should I check next?
Thanks.
@RAc @tony-josi-aws
I walked through FreeRTOSIPConfig.h again and deleted some defines that I copied from other examples and now the ping works.
Thank you @tony-josi-aws and @RAc for your help.
Thanks for reporting back.