FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [October 2012 Threads] FreeRTOS RX62N EMAC Packets of zeroes Posted by Steven J. Ackerman on October 4, 2012 Using FreeRTOS v7.1.0. Demo RX600_RX62N-RSK_Renesas.
This usually works OK except under heavy incoming traffic to my MAC/IP I occassionaly receive a packet of all zeroes from ulEMACRead() in response to a uipETHERNET_RX_EVENT. Using Microsoft Network Monitor this packet doesn't appear on the wire.
Has anybody else seen this ?
Steven J. Ackerman, Consultant
ACS, Sarasota, Florida
http://www.acscontrol.com
RE: FreeRTOS RX62N EMAC Packets of zeroes Posted by Richard on October 4, 2012 I can't say I ever recall seeing such a thing.
How are you defining 'heavy' traffic in this case? It is perfectly possible to overwhelm a small microcontroller with very heavy traffic it can't physically keep up with, but it should fail gracefully, in that, it should just miss packets and not do anything daft.
Regards.
RE: FreeRTOS RX62N EMAC Packets of zeroes Posted by Steven J. Ackerman on October 4, 2012 Richard-
Thanks for your reply. I have written a VNC server app that runs on the RX62N. If the connected VNC client sends a large number of client pointer event messages due to rapid mouse movement, then I will receive the packet of all zeroes. It happens somewhat randomly.
Unfortunately one of the received RBF messages to set the client pixel format uses a zero as the message identifier and then my connection structure gets hosed.
I'm suprised that this gets through the FreeTCPIP stack since I wouldn't think that the CRC was correct - but it comes into my application from the newdata() notification as a valid received packet.
Steven J. Ackerman, Consultant
ACS, Sarasota, Florida
http://www.acscontrol.com
RE: FreeRTOS RX62N EMAC Packets of zeroes Posted by Richard on October 4, 2012 “I'm suprised that this gets through the FreeTCPIP stack ” If you cannot see the packet on the wire, then maybe it isn't getting through the stack (because it doesn't exist) but you are seeing a symptom of something else going wrong - maybe in the MAC driver/DMA interface. I was going to suggest capturing a recording of the packets using Wireshartk, and then playing them back into the RX device so you could step through and see what happens, but if the packet isn't on the wire, then it can't be recorded. Regards.
RE: FreeRTOS RX62N EMAC Packets of zeroes Posted by Steven J. Ackerman on October 4, 2012 OK - that's what I thought. Do you know who wrote the EMAC for the Renesas RX62 ?
RE: FreeRTOS RX62N EMAC Packets of zeroes Posted by Richard on October 5, 2012 “Do you know who wrote the EMAC for the Renesas RX62” Um..probably me. Regards.
RE: FreeRTOS RX62N EMAC Packets of zeroes Posted by Steven J. Ackerman on October 5, 2012 Richard- So in looking at this closer, it may be that either EMAC or FreeTCPIP is confused. Looking at the packet that is being presented to my application as newdata() and ack() the packet contents looks like part of the 16-bit frame buffer image that I had previously sent to the client - the screen has black (00 00), red (f8 00) and white (ff ff) pixels. The message header is not present in the payload, but it is only sent in the first packet of the frame buffer update response. This packet should never come back to the server, it is outgoing to the client only. The first MAC address is the VNC server (my device), the second MAC address is the VNC client (my PC), the source IP address is my PC (192.168.1.110) the destination IP is my device (192.168.1.200), the port numbers are correct. Here's the packet:
ADDRESS +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F ASCII
00002364 02 01 23 45 67 89 00 19 D1 22 14 D3 08 00 45 00 ..#Eg...."....E.
00002374 00 2E 68 6A 40 00 80 06 0D D9 C0 A8 01 6E C0 A8 ..hj@........n..
00002384 01 C8 11 94 17 0C 5C 5B 05 A6 00 24 BC 9C 50 18 ......\[...$..P.
00002394 FF FF DD C2 00 00 00 00 00 00 00 00 00 00 00 00 ................
000023A4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000023B4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000023C4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000023D4 00 00 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000023E4 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000023F4 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 FF FF FF FF ................
00002404 FF FF FF FF FF FF 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002414 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002424 00 F8 00 F8 00 F8 00 F8 FF FF FF FF FF FF FF FF ................
00002434 FF FF 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002444 00 F8 00 F8 00 F8 00 F8 FF FF FF FF FF FF FF FF ................
00002454 FF FF 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002464 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002474 00 F8 00 F8 FF FF FF FF FF FF FF FF FF FF FF FF ................
00002484 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002494 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000024A4 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000024B4 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 FF FF ................
000024C4 FF FF FF FF FF FF FF FF 00 F8 00 F8 00 F8 00 F8 ................
000024D4 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000024E4 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000024F4 00 F8 00 F8 00 F8 00 F8 00 F8 FF FF FF FF FF FF ................
00002504 FF FF FF FF FF FF FF FF 00 F8 00 F8 00 F8 00 F8 ................
00002514 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002524 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 FF FF ................
00002534 FF FF FF FF FF FF FF FF FF FF 00 F8 00 F8 00 F8 ................
00002544 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002554 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002564 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002574 FF FF FF FF FF FF FF FF FF FF 00 F8 00 F8 00 F8 ................
00002584 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002594 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000025A4 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000025B4 00 F8 00 F8 FF FF FF FF FF FF FF FF FF FF FF FF ................
000025C4 FF FF 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000025D4 00 F8 00 F8 00 F8 00 F8 00 F8 00 00 00 00 00 00 ................
000025E4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000025F4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00002604 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00002614 00 00 00 00 00 00 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002624 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002634 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002644 FF FF FF FF FF FF FF FF FF FF 00 F8 00 F8 00 F8 ................
00002654 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002664 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 FF FF FF FF ................
00002674 FF FF FF FF FF FF FF FF FF FF 00 F8 00 F8 00 F8 ................
00002684 00 F8 00 F8 00 F8 00 F8 00 F8 FF FF FF FF FF FF ................
00002694 FF FF FF FF FF FF 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000026A4 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000026B4 00 F8 00 F8 00 F8 FF FF FF FF FF FF FF FF FF FF ................
000026C4 FF FF FF FF FF FF 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000026D4 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000026E4 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000026F4 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002704 00 F8 FF FF FF FF FF FF FF FF FF FF 00 F8 00 F8 ................
00002714 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002724 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002734 00 F8 00 F8 00 F8 00 F8 FF FF FF FF FF FF FF FF ................
00002744 FF FF FF FF FF FF FF FF FF FF 00 F8 00 F8 00 F8 ................
00002754 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002764 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002774 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
00002784 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
00002794 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000027A4 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000027B4 00 F8 00 F8 FF FF FF FF FF FF FF FF FF FF 00 F8 ................
000027C4 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000027D4 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 00 F8 ................
000027E4 00 F8 00 F8 00 F8 00 F8 00 .........
This packet doesn't appear on the wire, but my application receives this via FreeTCPIP as newdata() and ack() - which I guess that it would be looking at the header, but the contents are not a message that I would expect to receive from the VNC client (Tight VNC Viewer). Any ideas why this would be happening ? Have you seen anything like this before ? Thank you for any insight.
RE: FreeRTOS RX62N EMAC Packets of zeroes Posted by Steven J. Ackerman on October 6, 2012 Richard- OK - I think I see what is going on. In my rfb application, I'm checking for ack() then newdata(). In ack(), if I'm in the middle of sending the frame buffer then I prepare the next packet for sending, updating appdata and uip_len. When I exit ack() then newdata() is next and it looks like I've received what I've just sent. I'm going to try reversing the order of these calls, checking for newdata() first, then ack() to see if that will correct the problem. Any newdata() received while connected after initial handshaking doesn't generate any responses - other than the return ACK. Another interesting anamoly has appeared however. When I brought this hardware home to work on this weekend, and hooked it up to my LAN, the EMAC code is now stopping in the following function:
static void prvResetEverything( void )
{
/* Temporary code just to see if this gets called. This function has not
been implemented. */
portDISABLE_INTERRUPTS();
for( ;; );
}
This doesn't happen on the work LAN - can you please provide some insight as to why this is coded this way and why this would be happening on one LAN and not the other ?
Thank you !
RE: FreeRTOS RX62N EMAC Packets of zeroes Posted by Richard on October 6, 2012 I've never seen that function called, but as I remember it is called in response to error bits being set in the MAC registers (just from memory). If you go to where the function is being called, and set a break point on it, you should be able to see the cause.
Regards.
RE: FreeRTOS RX62N EMAC Packets of zeroes Posted by Steven J. Ackerman on October 8, 2012 Richard- Turns out that it is not a MAC error - just an indication that a fragmented packet has been received. In your function prvCheckRxFifoStatus() if FP0 is not set it indicates that a starting or continuous packet has been received:
static unsigned long prvCheckRxFifoStatus( void )
{
unsigned long ulReturn = 0;
if( ( pxCurrentRxDesc->status & ACT ) != 0 )
{
/* Current descriptor is still active. */
}
else if( ( pxCurrentRxDesc->status & FE ) != 0 )
{
/* Frame error. Clear the error. */
pxCurrentRxDesc->status &= ~( FP1 | FP0 | FE );
pxCurrentRxDesc->status &= ~( RMAF | RRF | RTLF | RTSF | PRE | CERF );
pxCurrentRxDesc->status |= ACT;
pxCurrentRxDesc = pxCurrentRxDesc->next;
if( EDMAC.EDRRR.LONG == 0x00000000UL )
{
/* Restart Ethernet if it has stopped. */
EDMAC.EDRRR.LONG = 0x00000001UL;
}
}
else
{
/* The descriptor contains a frame. Because of the size of the buffers
the frame should always be complete. */
if( ( pxCurrentRxDesc->status & FP0 ) == FP0 )
{
ulReturn = pxCurrentRxDesc->size;
}
else
{
/* Do not expect to get here. */
prvResetEverything();
}
}
return ulReturn;
}
Looking at the Renesas ethernet driver function _eth_fifoRead() this code copies the partial frame data when FP0 is not set:
/******************************************************************************
* Function Name: _eth_fifoRead
* Description : Receives data and updates E-DMAC descriptor
* Arguments : p - pointer to descriptor
* : buf - pointer to data to receive
* Return Value : Number of bytes received for this descriptor
* : -1 Descriptor busy
* : -2 Frame error
******************************************************************************/
int32_t ( ethfifo *p, int8_t buf[])
{
int32_t i, temp_size; /* byte counter */
ethfifo *current = p;
if( (current->status & ACT) != 0)
{
/**
* Current descriptor is active and ready to receive or receiving.
* This is not an error.
**/
return (-1);
}
/**
* Current descriptor is not active.
* Process the descriptor and data received.
**/
else if( (current->status & FE) != 0)
{
/**
* Frame error.
* Must move to new descriptor as E-DMAC now points to next one.
**/
return (-2);
}
else
/* We have a new data w/o errors to process. */
{
if ((current->status & FP0) == FP0)
{
/* This is the last descriptor. Complete frame is received. */
temp_size = current->size;
while (temp_size > BUFSIZE)
{
temp_size -= BUFSIZE;
}
}
else
{
/**
* This is either a start or continuos descriptor.
* Complete frame is NOT received.
**/
temp_size = BUFSIZE;
}
/* Copy received data from receive buffer to user buffer */
for (i = 0; i < temp_size; i++)
{
buf = current->buf_p;
}
/* Return data size received */
return (temp_size);
}
}
Unfortunately the Renesas ethernet driver code is structured differently than EMAC.c and it's not clear to me how I could assemble these fragments before returning from ulEMACRead().
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|
