AR8035 vs KSZ9031RNX Topic is solved

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
User avatar
RedDave
Experienced Member
Posts: 77
Joined: Fri Oct 05, 2018 4:26 pm

AR8035 vs KSZ9031RNX

Postby RedDave » Thu Aug 06, 2020 12:23 pm

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: 1836
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Thu Aug 06, 2020 1:41 pm

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: 1836
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Thu Aug 06, 2020 3:38 pm

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

Postby RedDave » Fri Aug 07, 2020 10:38 am

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

Postby RedDave » Fri Aug 07, 2020 11:58 am

Code and schematic attached.

Code
EthernetTest.zip
XMOS section of schematic
EthernetTest.png
Ethernet PHY schematic
EthernetTest.pdf
You do not have the required permissions to view the files attached to this post.
User avatar
mon2
XCore Legend
Posts: 1836
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Aug 07, 2020 4:36 pm

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
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
Please review and post your results
You do not have the required permissions to view the files attached to this post.
User avatar
mon2
XCore Legend
Posts: 1836
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Sun Aug 09, 2020 5:57 pm

phy_addr_source.png
phy_addr_hardware.png
You do not have the required permissions to view the files attached to this post.
User avatar
RedDave
Experienced Member
Posts: 77
Joined: Fri Oct 05, 2018 4:26 pm

Postby RedDave » Mon Aug 10, 2020 10:33 am

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

Postby RedDave » Mon Aug 10, 2020 1:21 pm

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.

Who is online

Users browsing this forum: No registered users and 3 guests