I just found an important bug in Coldfire Lite when compiled for the 52259 CPU. This bug will make the board hang during initialisation!
The bug is located in MCF52259_sysinit.c , near the end of the function void mcf52259_ePHY_init(void):
This is the original version:
while(!(fec_mii_read(FEC_PHY0, 0x10, ®0))) // read PHY status register { reg0=0; }; DUPLEX_phy_r17_dpm = (int)((reg0&0x0004)>>2); // 1=full,0=half duplex...used in ifec.c do //FSL read PHY status register { fec_mii_read(FEC_PHY0, 0x10, ®0); }while (!(reg0&(PHY_R1_LS))); //FSL exit while loop when Link Status up
This is what should be there:
while(!(fec_mii_read(FEC_PHY0, PHY_REG_SR, ®0))) // read PHY status register { reg0=0; }; DUPLEX_phy_r17_dpm = (int)((reg0&0x0004)>>2); // 1=full,0=half duplex...used in ifec.c do //FSL read PHY status register { fec_mii_read(FEC_PHY0, PHY_REG_SR, ®0); }while (!(reg0&(PHY_R1_LS))); //FSL exit while loop when Link Status up
The actual value of PHY_REG_SR is 0x01. This means that, in the original version of MCF52259_sysinit.c, the program is reading the wrong register (0x10, which actually corresponds to PHY_REG_IR, the PHY interrupt register).
I have checked out my "bug report" a little more closely. The original ePHY_init routine was written with only the52259EVB board in mind. This board uses a different PHY compared to the DEMO board. Both PHYs have a different register set, which means that the init routine for the EVB may not work for the DEMO board.
So I made a modification to make the init routine compatible with both EVB and DEMO boards, based on the board selection in processor.h
The first piece of code shows the original code from the init routine, the second piece is my new version.
while(!(fec_mii_read(FEC_PHY0, 0x10, ®0))) // read PHY status register { reg0=0; }; DUPLEX_phy_r17_dpm = (int)((reg0&0x0004)>>2); // 1=full,0=half duplex...used in ifec.c do //FSL read PHY status register { fec_mii_read(FEC_PHY0, 0x10, ®0); }while (!(reg0&(PHY_R1_LS))); //FSL exit while loop when Link Status up
I still believe the original code contains a bug, by the way. There is a reference to a bit called PHY_R1_LS (link status) in PHY register 0x10.The link status bit is available in register 0x10, but not at the bit position PHY_R1_LS, which actually belongs to the PHY basic status register at adress 0x01.
do //FSL read PHY status register { fec_mii_read(FEC_PHY0, PHY_REG_SR, ®0); }while (!(reg0&(PHY_R1_LS))); //FSL exit while loop when Link Status up #if M52259EVB while(!(fec_mii_read(FEC_PHY0, 0x10, ®0))) // read DP83640 PHY status register { reg0=0; }; DUPLEX_phy_r17_dpm = (int)((reg0&0x0004)>>2); // 1=full,0=half duplex...used in ifec.c #else // M52259DEMO while ((reg0 & 0x1c) == 0) { while(!(fec_mii_read(FEC_PHY0, 0x1f, ®0))) // read KSZ8041NL PHY control 2 register { reg0=0; }; }; DUPLEX_phy_r17_dpm = (int)((reg0&0x0010)>>4); // 1=full,0=half duplex...used in ifec.c #endif
In my new version, I switched the link status detect and the full/half duplex readout. I think it makes more sense to wait for the link to become active before figuring out if the link is full or half duplex.
Checking the duplex had to be done differently in the EVB and DEMO boards because of the different PHY chips used. See the corrsponding data sheets for th actual registers/bits used.
- Marc
I have checked with an enginner on this matter, and here is his response:
The M52259EVB has a National Semi DP83640 Ethernet PHY.
14.1.10 PHY Status Register (PHYSTS)
This register provides a single location within the register set for quick access to commonly accessed information.
TABLE 23. PHY Status Register (PHYSTS), address 0x10
I went checking for the new version. I found ColdFire_TCP-IP_Lite_Rev3.2 which is available since the beginning of February and which is the version I have been testing with.
I also found ColdFire_Lite_M52259EVB.
There appear to be quite a number of differences between the two. I'm not sure which is the one you're referencing to though, but the files in the archive which contains ColdFire_Lite_M52259EVB appear to be older then the files in the revision 3.2 archive.
Maybe I should check through all the files with differences and keep the best from both!
Contacting the engineer seems like a good idea to me too...
I'll have the engineer contact you at your Gmail address.
---Tom