AR8035 vs KSZ9031RNX Topic is solved

Technical questions regarding the XTC tools and programming with XMOS.
Post Reply
User avatar
RedDave
Experienced Member
Posts: 77
Joined: Fri Oct 05, 2018 4:26 pm

AR8035 vs KSZ9031RNX

Post by RedDave »

We have been developing a PCB incorporating an XMOS device. The XMOS segment of the board using the bulk of the circuit from the explorerKit, including the AR8035 for the Ethernet. This has all worked fine.

The AR8035 is being made obsolete, so not good for a new product. On our latest version, we have taken the sliceKit Ethernet slice design including the KSZ9031RNX. I expected the code just to work, having read posts here. The only operational difference between the sliceKit and explorerKit is the port on which the ethernet reset is on. On our design we retain the XS1_PORT_1N of the explorerKit, so not change should be required.

When I run my test app, the Ethernet green LED lights, the amber LED blinks when there is activity on the cable. But I cannot Ping the device. In summary it seems to work in all ways except it not working. :(

Any suggestions as to how to go about diagnosing?


View Solution
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

You can buy the ar8035 from this vendor offshore:

https://www.win-source.net/hot-sales-an ... -al1a.html

We have sourced from them multiple times without any problems. Can share our contact details upon request. They are showing high volumes of the phy in stock.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

To save on review time, post more details.

There have been multiple Ethernet slice kits. After using google-fu, found that you are referencing the p/n XA-SK-GBE slicecard.

Where is your schematic for the Ethernet PHY?

What are the voltage rails for your Ethernet PHY?

Which ports did you map the Ethernet PHY onto in your custom design?

Which code are your referencing for this testing? Ideally reference only the XMOS proven appnotes for such initial tests.
User avatar
RedDave
Experienced Member
Posts: 77
Joined: Fri Oct 05, 2018 4:26 pm

Post by RedDave »

We aren't looking for a solution for a small number of components, but for a design that is sustainable for a few years. Designing with an obsolete part is not a route we want to go down. But thanks for that advice.

I'll post the code and schematic shortly. The app not that I originally referenced is AN00199.
User avatar
RedDave
Experienced Member
Posts: 77
Joined: Fri Oct 05, 2018 4:26 pm

Post by RedDave »

Code and schematic attached.

Code
EthernetTest.zip
(11.92 KiB) Downloaded 198 times
EthernetTest.zip
(11.92 KiB) Downloaded 198 times
XMOS section of schematic
EthernetTest.png
(95.85 KiB) Not downloaded yet
EthernetTest.png
(95.85 KiB) Not downloaded yet
Ethernet PHY schematic
EthernetTest.pdf
(350.7 KiB) Downloaded 273 times
EthernetTest.pdf
(350.7 KiB) Downloaded 273 times
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

1) Your version of the schematic has a few red "x" showing - are these lines which are floating or disconnected?

If yes, are the RX3..RX0 lines truly disconnected?

2) What is the confidence level on the SMD soldering of this component? It features a metal belly which should be grounded.

3) Power rails solid and match what is expected?

4) Insert some debug statements into the sample code to determine how far along it is able to run. Perhaps stuck in some loop?

5) Required 25Mhz clock operational? What is the voltage swing of this external 25Mhz clock?

6) Is the same (as shown in the schematic and XMOS ref designs) RJ45 with magnetics being used for this custom PCB?

7) It is too early to discuss PCB layouts but we recall that for our Gigabit USB designs, we had to follow special PCB layout guidelines for solid results. However, important to note.

8) Study the ref notes and search for any vendor specific registers that may be in the source code which will be show stoppers in migrating from the AR8035 to the KSZ9031RNX.

Ok...while writing this point of interest, review the PHY Driver source code:
AR8035_vendor_specific_register.png
(193.12 KiB) Not downloaded yet
AR8035_vendor_specific_register.png
(193.12 KiB) Not downloaded yet
The above code is working with a Vendor specific register of 0x11 which is correct for AR8035 and not valid for the Microchip (Micrel PHY).

Summary: The Ethernet PHY driver will need a thorough investigation to update and support the new Ethernet PHY.

9) What is your MAC address? Have they been written to the OTP of this fresh CPU on your PCB?

Suggest to run the original APPNOTE code on a known working set of tools -> extract the MAC address and compare the same code run results on your custom board. For this early stage of debugging, lots of printfs will be helpful to view the output from any calls relating to the PHY.
xmos_mac_address.png
(62.93 KiB) Not downloaded yet
xmos_mac_address.png
(62.93 KiB) Not downloaded yet
Please review and post your results
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

phy_addr_source.png
(30.41 KiB) Not downloaded yet
phy_addr_source.png
(30.41 KiB) Not downloaded yet
phy_addr_hardware.png
(217.4 KiB) Not downloaded yet
phy_addr_hardware.png
(217.4 KiB) Not downloaded yet
User avatar
RedDave
Experienced Member
Posts: 77
Joined: Fri Oct 05, 2018 4:26 pm

Post by RedDave »

I'll answer the soft/firmware related points and hand over to an electronic engineer for the rest.

4) The code runs and seems completely operational. I'll add some debug to ensure that it does indeed get through all configuration. The port itself seems operational, but does not reply to pings.
8) I will look into this.
9) I will investigate this as this seems a probable cause.

[And thank you very much for these investigation leads].
User avatar
RedDave
Experienced Member
Posts: 77
Joined: Fri Oct 05, 2018 4:26 pm

Post by RedDave »

Your later post seems to have cracked it. Setting the PHY address correctly fixes it (obvs). I'm surprised that my searches did not bring this up in any forum post, as this is the same value used on the reference design, and all the posts seem to suggest that the only difference between the ExplorerKit and this is the need to change p_eth_reset.

It took some work to get this to work and I will report here for future readers...

It appears that when the lib_ethernet library builds it optimises for the const values that are past but then does not rebuild when those values are changed. Is this a known bug?

From clean build with ar8035.xc

Code: Select all

...
const uint8_t phy_address = 0x0;
...
while (smi_phy_is_powered_down(smi, phy_address));
...
This does not work because PHY address is incorrect. The while loop is not left.

Change PHY address to 0x03. This still does not work, because (it seems) the library now has 0x0 compiled in to it. It needs to be cleaned in order for the new value to take effect.

I was in the strange position where the code below worked, but the commented code didn't.
i.e. taking the contents of the function and replacing the function with it. smi_phy_is_powered_down had the 0x0 compiled in.

Code: Select all

...
const uint8_t phy_address = 0x3;
...
// while (smi_phy_is_powered_down(smi, phy_address));
while (((smi.read_reg(phy_address, BASIC_CONTROL_REG) >> BASIC_CONTROL_POWER_DOWN_BIT) & 1));
...
Thanks mon2 for your time and assistance.
farangutan
New User
Posts: 2
Joined: Fri Feb 26, 2021 4:22 am

Post by farangutan »

First, a big "Thank You" to mon2 for the link to Winsource. I need 50 pieces of the AR8035 plus other bits of kit. Winsource can supply all of them. Currently many parts are becoming scarce. I'm thrilled to have another source for components.

Thanks also to RedDave for sharing the schematic using the KSZ9031.

Both of you have saved me many days of swearing at "Stock on hand: 0" messages. For now, I will stick with the AR8035 since the PCB layout is done. I will migrate to the KSZ9031for future XMOS work.
Post Reply