The RX600_RX62N-RSK_Renesas demo webserver runs correctly when I directly connect the RSK to a computer. However, when I attach everything to my network, the webserver no longer serves pages to my browser. However, I can ping the RSK. The only modification I made to the project was the IP address so it is compatible with my network. Any ideas?

Could it be that the IP address change requires the netmask to change too? I don't know if that would effect PING though.

Nope, the default mask of 255.255.255.0 is valid.

Another stab. Could it be that the Ethernet MAC is somehow set to promiscuous mode, and therefore trying to processes every single packet on the network, and failing to keep up when it is connected to the main network?

Because PING works, the ethernet must be up, so the usual problems of bad auto negotiation etc can't apply.

Which FreeRTOS version are you using?

The demo note said the app was tested only with a direct connection but *should* work with other connections. I was hoping it was something simple but there must be a bigger issue here. I guess I will have to dig into the MAC code. I am new to this device so that is why I am looking for help.

I am using FreeRTOS version 7.1.0.

The MAC is not in promiscuous mode.

I have experimented with this today, here is what I did and what I found:

+ Checked the promiscuous mode bit, and concur your findings that it is not set.

+ Tried the webserver on a point to point connection, works fine.

+ Plugged the RX62N into a wired office network, through a Cisco switch, and connected to it from a WiFi computer through a WiFi access point. Again, the web server worked fine.

+ Went back to a point to point connection, and this time forced a connect at 100/full, 100/half, 10/full and 10/half (speed/duplex), and in all cases found that I could connect to the RX62N device without any problem.

So - I have been unable to replicate your error. However, when I plugged the board into the office network it was going though a switch, which means it will not be able to see the heavy network load, only the broadcast and unicast traffic to itself. I have no way of setting up a large network without going through switches.

Regards.

I appreciate all your effort in trying to reproduce the issue. I did some more digging and discovered that I unknowingly had a proxy configured on the computer I was running the browser. When I disabled the proxy I was able to talk to the device. This computer was connected to the same switch as the RSK. However, when I tried to communicate to it using other computers not directly connected to that switch it failed. It smells like a network issue to me, except for one thing. I have a Renesas RPBRX62N demo board running a webserver on the same switch as the RSK and I can access that fine - from my computer with or without the proxy server and from any other computer on the office network. That demo code is based on the uIP stack as well. If it were entirely a network issue I wouldn't expect to be able to communicate to that board either.

One more bit of information. When I try to connect from a computer not directly connected to the switch, the uIp stack executes the retransmit code near line 795 of FreeRTOS-uIP\uip.c:

/* If the connection has outstanding data, we increase the
connection's timer and see if it has reached the RTO value
in which case we retransmit. */
if( uip_outstanding(uip_connr) )
{
uip_connr->timer = uip_connr->timer - 1;
if( uip_connr->timer == 0 )
{
// this gets executed...

Maybe there a timeout value I can try increasing??

In the file uiopt.h, I changed the value of UIP_RTO from 3 to 6 and now I can communicate with the RSK for all scenarios that previously were failing. I'm a little bit leary since the code says "This should not be changed". However, it seems to be working. I will test it more to be sure.

I believe I have found the root issue. In uIP_Task.c, the periodic timer is created with a period of 500 mS. The other sample projects I have based on uIP have a 50 mS periodic timer. When I change the periodic timer period to 50 mS, everything works fine with the original value of UIP_RTO of 3. The following is the change I made in the function prvInitialise_uIP:

xPeriodicTimer = xTimerCreate( ( const signed char * const ) "PeriodicTimer",
( 50 / portTICK_RATE_MS ), // ***changed, was 500***
pdTRUE, /* Autor-reload. */
( void * ) uipPERIODIC_TIMER,
prvUIPTimerCallback
);

Good info - thanks. I will look into why that is so and update as necessary. Half a second is obviously too long.

Regards.