NetBurner Community Forum

How can I determine if my mod5270 has the new Micrel ethernet PHY? Right now I can only see the version number on my board. What version number of the mod5270 did they introduce this new part? Thanks.

the following should help:

#if 1 // extracted from ~/MOD5270B/system/ethervars.h
// PHY ID is composed of both register 2 and 3 from the PHY management registers.
// The following are the masks used to extract the manufacurer OUI, the model or the version number
#define PHY_ID_OUI_MASK (0xFFFFFC00)
#define PHY_ID_MODEL_MASK (0x000003F0)
#define PHY_ID_VERSION_MASK (0x0000000F)

#define MICREL_OUI_ID (0x00221400)
#define DAVICOM_OUI_ID (0x0181B800)
#define NATIONAL_OUI_ID (0x20005C00)
#define AMD_OUI_ID (0x00225400)

#define MICREL_8721B_ID (0x0210)
#define MICREL_8041NL_ID (0x0110)
#define DAVICOM_9161_ID (0x0080)
#define AMD_79C874_ID (0x0210)
#define NATIONAL_83848C_ID (0x0090)
#define NATIONAL_83640_ID (0x00E0)
extern DWORD PHY_ID;
#endif
// returns PHY_info in following format"
// PHY info: Manuf=<name> Model=<name> Ver=N
void NB_PHY_Info(char *PHY_info)
{
char sOUI[16]="Unknown";
char sModel[16]="Unknown";
bool match=false;
#define NPHY_OUI 4
#define NPHY_MODEL 6
const struct {
DWORD id;
char *oui;
} phy_oui[NPHY_OUI]={
{MICREL_OUI_ID,"MICREL"},{DAVICOM_OUI_ID,"DAVICOM"},
{NATIONAL_OUI_ID,"NATIONAL"},{AMD_OUI_ID,"AMD"}};
const struct {
int oui;
DWORD id;
char *model;
} phy_model[NPHY_MODEL] = {
{0,MICREL_8721B_ID,"MICREL_8721B"},
{0,MICREL_8041NL_ID,"MICREL_8041NL"},
{1,DAVICOM_9161_ID,"DAVICOM_9161"},
{2,NATIONAL_83848C_ID,"NATIONAL_83848C"},
{2,NATIONAL_83640_ID,"NATIONAL_83640"},
{3,AMD_79C874_ID,"AMD_79C874"}};

for (int ioui=0;ioui<NPHY_OUI;ioui++)
if ((PHY_ID & PHY_ID_OUI_MASK) == phy_oui[ioui].id) {
strcpy(sOUI, phy_oui[ioui].oui);
for (int imodel=0;imodel<NPHY_MODEL;imodel++)
if ((phy_model[imodel].oui == ioui) &&
((PHY_ID & PHY_ID_MODEL_MASK) == phy_model[imodel].id)) {
strcpy(sModel,phy_model[imodel].model);
match=true;
break;
}
if (match)
break;
}

siprintf(PHY_info,"PHY info: Manuf=%s Model=%s Ver=%d", sOUI, sModel,
(PHY_ID & PHY_ID_VERSION_MASK));
}

Thanks very much greengene.
We have a field problem, which we have not been able to recreate in our lab (and I do not yet have access to a failing unit). Recently customers reported the inability to connect over Ethernet. IPSETUP does not find the Netburner card. Cables, static IP address and netmask are all correct. It turns out that disabling and re-enabling the PC Ethernet hardware causes the attached Netburner to wake up and work properly. Has anyone else seen a similar problem?

Are you running any javascripts on the netburner?
I have a 5270B running that I have trouble connecting via Ethernet sometimes with some PCs. I have to re-start the browser and then reset the 5270B otherwise IPSetup doesn't see the card. It looks like get handlers for the javascript are hanging the interface to one PC, but it could be something else. It also seems only to affect older IE versions. I haven't tracked it down yet.

Ed

No javascripts running on the Netburner.
The problem occurred using two different PCs. Not sure what browsers they were using.
Initially we suspected the customer technical staff had PC cable or IP setup problems. I sent them a wireless router configured to DHCP the proper IP/mask settings. This made it as easy to connect to Netburner as connecting to Starbuck's WiFi. This too failed at the customer side.
The Ethernet interface is thoroughly tested during manufacture, and we have never seen this prior to shipping product.

we've had similar problems. have you gone to the new(er) NNDK? 2.5.3 or newer?
NB did work in the Enet stack and it appears to have helped.

Our NetBurner release_tag file content is “rel21_rc3a”. (My guess is that this means version 2.1.) I noticed a 5/2/11 Product Change Notice for part number CFV2-66CR that says a replacement component Micrel KSZ8721BLI requires NetBurner 2.5.2 or later. (I searched for a PHY Product Change Notice for my MOD5270, but did not find anything.) I have now disassembled two of our products returned due to network failures and both contain the Micrel KSZ8721 PHY parts. (My stable system here in our lab has a Davicom PHY part.) As I look at my NetBurner device driver code I see it supports four PHY:

// PHY ID Register #2 bits with the last 4 revision number bits being dont cares
#define MICREL_ID (0x1610)
#define DAVICOM_ID (0xB880)
#define AMD_ID (0x5610)
#define NATIONAL_ID (0x5C90)

The Micrel part listed is the KSZ804. So the KSZ8721 part, on our newly purchased MOD5270 hardware, is apparently not supported with our old NetBurner code. I’ve tried downloading the latest tools release, but I get a login error message saying my username or password is incorrect. I seem to remember that when I registered, I was asked to enter the serial number of my NNDK-MOD5270-KIT. I thought this would give me access to NetBurner updates, but apparently not.

I’ll poke around to find what kind of service I need to purchase for NetBurner updates. I have another problem in that I still cannot reliably recreate the Ethernet problem in our lab. I would like to show that recompiling with the new NetBurner software fixes the problem. My fear is that I’m dealing with more than one problem. I don’t want to refresh our field machines and inventory only to find this problem reappear later.

As far as I can tell from the datasheets of the Micrel parts, the MICREL_ID 0x1610 matches the KSZ8721.

To recognise a KSZ804 would require ID = 0x1400.

So it looks like the KSZ8721 is the supported Micrel part, and KZS804 is not supported.

I am interested in this because we use MOD5270B and we are still using Rel24_rc2.

From my ethervars.h:
I have never checked which PHY is on the board(s) because I have never experienced a problem with the PHY failing to work.

In short, I don't think your problem is related to the PHY not being supported by the software.

You are absolutely right. I read the spec wrong. As old as my software is, it should be correctly recognizing the PHY.
Thank you.

After I explain the problem(s) you might dismiss everything, thinking, ‘This guy can’t read a spec and he doesn’t know how to use a computer.’ Unfortunately it’s not quite that simple.
Our contract manufacturer sets a default static IP address before shipping our product. In some installations the customer needs to change this default. In the problem cases it appears the customer tech support used laptops without external power adapters. The power settings on the battery operated laptops deactivate the Ethernet port (resulting in the attached Netburner holding link LEDs off). Disabling and enabling the battery operated laptop Ethernet interface overrides the power management, energizes the laptop Ethernet, making it look like the Netburner card has suddenly come active.
But wait, you say, what about the Starbuck solution? It turns out we have a second problem in that some product was sent out without a default static IP address. This was the case in the one time I sent out my router. The customer attached my wireless router, connected using WiFi, but instead of running IPSetup they tried pinging the default IP address and failed.
Thanks again for the help.
If necessary, warn customers about laptop power settings.