NE64 OpenTCP test setup

khumphri — Fri, 27 Jan 2006 21:24:03 GMT

This message contains an entire topic ported from a separate forum. The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value to you as you search for answers to your questions.

Posted: Tue Dec 6, 2005 7:24 pm

Hello Guys

I have downloaded the OpenTCP example as suggested earlier, colpiled it unser CW 3.1 and flashed the code into DEMO9S12NE64. I have also connected the DEMO9S12NE64 to my laptop ethernet port using a cross cable and the SCI to the serial port.

1.) I see there are a DEBUGOUT macros which should be printing the trace msg's to the serial port using 115200 baud. I had set up Hyperterminal to listen to the SCI data, when I trace/debug the code on the DEMO9S12NE64 I dont see any messages sent to the Hyperterminal, should I be passing any arguments to the compiler?

2.) In order to verify the set up is ok, I am using the static IP example provided. It has a default IP of 192.168.2.3 in the address.c file, I changed it to 192.168.1.25 and my laptop is 192.168.1.15, subnetmask is 255.255.255.0. With this I should be able to ping the DEMO9S12NE64 right? but I am getting a response time out.

Am I missing something critical here?

Posted: Tue Dec 6, 2005 7:43 pm

> 1.) I see there are a DEBUGOUT macros which should be printing the

> trace msg's to the serial port using 115200 baud. I had set up

> Hyperterminal to listen to the SCI data, when I trace/debug the code

> on the DEMO9S12NE64 I dont see any messages sent to the

> Hyperterminal, should I be passing any arguments to the compiler?

Maybe some conditional #define

> 2.) In order to verify the set up is ok, I am using the static IP

> example provided. It has a default IP of 192.168.2.3 in the address.c

> file, I changed it to 192.168.1.25 and my laptop is 192.168.1.15,

> subnetmask is 255.255.255.0. With this I should be able to ping the

> DEMO9S12NE64 right? but I am getting a response time out.

> Am I missing something critical here?

Addressing is fine. First check: does "link" LED lights up after connecting the cable ?

Posted: Tue Dec 6, 2005 7:58 pm

> Addressing is fine. First check: does "link" LED lights up after connecting

> the cable ?

Yes, after flashing when I hit "run" on the debugger, I see the link LED up as well as the Win 2000 network icon on the tray changes status from disconnected to connected.

Posted: Tue Dec 6, 2005 8:39 pm

> Yes, after flashing when I hit "run" on the debugger, I see the link

> LED up as well as the Win 2000 network icon on the tray changes status

> from disconnected to connected.

What about "act" LED during pinging? Now I would fire up ethereal for capturing ethernet traffic, to see what's going on the line, whether it's complete silence or some malformed traffic.

Posted: Wed Dec 7, 2005 8:00 am

I will use Etheral to trace the traffic to see whats going on. Meanwhile, is there any simple freeware DHCP server available for the Windows platform that you guys use? I googled up and found Turbo DHCP, but that does not show the connected clients.

Posted: Wed Dec 7, 2005 2:40 pm

> I will use Etheral to trace the traffic to see whats going on.

> Meanwhile, is there any simple freeware DHCP server available for the

> Windows platform that you guys use? I googled up and found Turbo

> DHCP, but that does not show the connected clients.

Tell Windows to "share your internet connection." It will issue an IP address to clients via DHCP. It will also NAT those devices to the outside world.

Posted: Tue Dec 6, 2005 8:40 pm

> 2.) In order to verify the set up is ok, I am using the static IP

> example provided. It has a default IP of 192.168.2.3 in the address.c

> file, I changed it to 192.168.1.25 and my laptop is 192.168.1.15,

> subnetmask is 255.255.255.0. With this I should be able to ping the

> DEMO9S12NE64 right? but I am getting a response time out.

> Am I missing something critical here?

be careful, the 9S12NE64 chip can't autoneg w/ gige ports (or at least the two gige switches I've tried).. (and if you're laptop has gige, you don't need the crossover cable)... This is a known issue and listed in the errata for the chip...

The code defaults to 100base-T half duplex, I believe to work around this issue..

Posted: Wed Dec 7, 2005 12:03 am

> be careful, the 9S12NE64 chip can't autoneg w/ gige ports (or at least

> the two gige switches I've tried).. (and if you're laptop has gige, you

> don't need the crossover cable)... This is a known issue and listed in

> the errata for the chip...

Does the autonegotiation code actually work? Some comments left among the bitrot suggests it wasn't complete. Considering it was disabled as shipped I left well enough alone and haven't revisited it.

> The code defaults to 100base-T half duplex, I believe to work around this issue..

In other words, if your laptop ethernet doesn't default to the same then the two are never going to meet as the box-stock OpenTCP doesn't autonegotiate at all. Manually cycle your laptop thru 10 and 100, full and half. One will hit.

Come to think of it I don't know how the semi-stupid 10/100 hub-not-switch figures things out with my setup. Initially set the #defines for 10-half, it works with the dumb hub buffering 10-half to 100-full. It *says* its a hub but I don't know how it can translate like that. Says its a hub but it always acts like a switch.

Posted: Wed Dec 7, 2005 12:55 am

> > be careful, the 9S12NE64 chip can't autoneg w/ gige ports (or at least

> > the two gige switches I've tried).. (and if you're laptop has gige,

> > you don't need the crossover cable)... This is a known issue and listed in

> > the errata for the chip...

> Does the autonegotiation code actually work? Some comments left among

> the bitrot suggests it wasn't complete. Considering it was disabled

> as shipped I left well enough alone and haven't revisited it.

I forget how much work I had to do to get it to work... The problem is that I had it "working" in default fixed mode, and then spent a week trying to figure out why it wasn't autoneg'ing, just to find out that it was the gige switch I was testing with..

So, yes, I got it working, and I think it wasn't too much.. lets see, I have (no diff, for some reason it thinks I changed the entire file): fix ne64driver by keeping the next page autoneg turned on.. for some reason this makes things work a lot better...

I also moved the starting PLL's till after setting up the autoneg or speed... Also, there is an errata that requires you to do an additional read after writting the to PHY for the changes to take place.. so in the MIIwrite function, you shouldn't take out the extra read at the end:

* This read is necessary as per Errata MSE9S12NE64_1L19S MUCts01900:

* Description

* At the end of a write cycle 3 additional MDC clocks must be supplied

* before the completion of the transaction.

* Workaround

* Follow a MDIO write with an MDIO read of any MDIO

* register.

also, the USE_SWLED code assumes a tight loop... I switched to properly using the wai instruction (w/ proper protection to make sure I don't go to sleep w/ a packet pending), and so had to adjust the timeout used by the SWLED (which you should use again, per errata)...

> > The code defaults to 100base-T half duplex, I believe to work around

> > this issue..

> In other words, if your laptop ethernet doesn't default to the same

> then the two are never going to meet as the box-stock OpenTCP doesn't

> autonegotiate at all. Manually cycle your laptop thru 10 and 100,

> full and half. One will hit.

If you aren't autoneg'ing you should always use half, unless you hard set the other size.. Because 100Base-T first came into use, switches weren't that common, it's standard that if you can't autoneg, the switch will assume half duplex.. and having a duplex mismatch is VERY bad...

and most phy's will link up no matter if it's half or full as long as the speeds match...

> Come to think of it I don't know how the semi-stupid 10/100 hub-not-

> switch figures things out with my setup. Initially set the #defines

> for 10-half, it works with the dumb hub buffering 10-half to 100-

> full. It *says* its a hub but I don't know how it can translate like

> that. Says its a hub but it always acts like a switch.

There are full switches, that can do full duplex, there are dual speed hub's (or switches) that hub each the 10 and 100mbit side and then _switch_ between the two sides... and then there are hubs, but they are only ever single speed..

Unless you are passing quite a bit of traffic, (which isn't usual with the microcontroller), you might have a duplex mismatch and not even realize it, just get wierd stalls.. but not ever really see a significant slow down.. the mismatch will be most noticable at 10/half...

So, short is that yes, autoneg works, but it may require mods.. I have tons of other mods in my tree, such as formating to compile on gcc, and also to make it handle being compiled with the following options:

CFLAGS += -Wall -Werror # Warnings

CFLAGS += -Wno-format-y2k

CFLAGS += -W -Wno-unused-parameter -Wstrict-prototypes\

-Wmissing-prototypes -Wpointer-arith

CFLAGS += -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch\

-Wshadow -Wcast-align -Wunused-parameter

(remember that -Wall isn't really all.. )..

I have:

#CFLAGS += -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls

as yet to do...

S12 / MagniV MicrocontrollersのトピックNE64 OpenTCP test setup

NE64 OpenTCP test setup