ask help on NDK2.0 for jumbo frame on c6455

Hi Weslly,

Which app are you running?  Are you running one of the network examples from NDK 2.0.0?  Also, please confirm that this is the version of the NDK you are using.

weslly li said:

Error: Unable to register the EMAC

This error message is coming out of the driver, from the call to NIMURegister().  Unfortunately, the NIMURegister() function can fail for a number of reasons.

Can you try an experiment?  Can you copy the file "ndk_2_0_0/packages/ti/ndk/src/stack/nimu/nimu.c" into your application project?  And then try to rebuild?  Are you able to build the nimu.c file as part of your project build?

If this works, then you can edit your local copy of nimu.c to add DbgPrintf() trace into the NIMURegister() function.  You should add print statements at each failure point in that function in order to gain some insight into why/where it's failing.

Again, this will only work if you are able to build a local copy of the nimu.c file as part of your application.

weslly li said:

NIMUIOCTL Failed with error code:

This is probably a result of the first error message.

Was this the EXACT message that you see being printed out?  I see a lot of error messages in the stack that have this message, however they are slightly different; the message gives more info.  For example, the parts in red:

\ndk\nettools\dhcp):                    "DHCPOpen: NIMUIOCTL (NIMU_GET_DEVICE_MAC) Failed with error code: %d\n",
dnscomn.c (ti\ndk\nettools\dns):                "DNSResolveByName: NIMUIOCTL (NIMU_GET_NUM_NIMU_OBJ) Failed with error code: %d\n",
dnscomn.c (ti\ndk\nettools\dns):                "DNSResolveByName: NIMUIOCTL (NIMU_GET_ALL_INDEX) Failed with error code: %d\n",

So, if such a part of the message was omitted somehow, we are missing an important clue.

In any case, error code 22 corresponds to EINVAL, and typically means "invalid argument."  Again, this is probably a result of the first error message, so we can come back to this one.

Steve

Hi, Steve,

Client example of NDK2.0.0 runs fine in non-jumbo frame mode. And i refered to "https://e2e.ti.com/support/embedded/tirtos/f/355/p/169168/620989#620989" and did some experiment:

first i tried to change memory allocation both in pbm.c and jumbo_pbm.c:

pbm.c:

//#define PKT_NUM_FRAMEBUF 192   (original)
#define PKT_NUM_FRAMEBUF 256

jumbo_pbm.c

//#define JUMBO_RAW_PAGE_COUNT 16    (original)
#define JUMBO_RAW_PAGE_COUNT (16*4)

still not fixed. So i added the _mmCheck in nimu_eth.c:

/* Register the device with NIMU */
if (NIMURegister (ptr_device) < 0)
{
printf ("Error: Unable to register the EMAC\n");
_mmCheck(0, &printf);
return -1;
}

here is the printf output:

TCP/IP Stack Example Client
Using MAC Address: 82-76-b5-fc-25-7e
Error: Unable to register the EMAC

7:48 ( 10%) 6:96 ( 18%) 1:128 ( 4%) 1:256 ( 8%)
1:512 ( 16%) 0:1536 0:3072
(15360/49152 mmAlloc: 16/0/1, mmBulk: 0/0/0)

1 blocks alloced in 512 byte page
7 blocks alloced in 48 byte page
5 blocks alloced in 96 byte page
1 blocks alloced in 128 byte page
1 blocks alloced in 256 byte page

So what does it mean? Any mem block not enough?

thanks,

Weslly

Hi Weslly,

Can you copy the file ethdriver.c into your application and rebuild?

If that builds successfully, please also update the code near the memory allocations in HwPktOpen() to print out some info.  I've highlighted this with a comment:

uint HwPktOpen( PDINFO *pi )
{
...
    /* Queue up some initialized receive buffers */
    for( i=0; i<PKT_MAX; i++ )
    {
        hPkt = PBM_alloc(ecfg.PktMTU);
        /* Couldnt allocate memory, return error */
        if (hPkt == NULL) {
            printf("HwPktOpen: error allocating memory (size %d)\n", ecfg.PktMTU);
            return 1;
        }
        rcv_pkt[i].AppPrivate   = (Uint32)hPkt;
        rcv_pkt[i].pDataBuffer  = PBM_getDataBuffer(hPkt);
        rcv_pkt[i].BufferLen    = PBM_getBufferLen(hPkt);
        Queue_push( &RxQueue, &rcv_pkt[i] );
    }

I'd like to see if you are failing at this same point and the allocation size that's being attempted

Steve

thanks, Steve,

By your suggestion, I found it's not failing at "hPkt = PBM_alloc(ecfg.PktMTU);", actually it's at " i = EMAC_open( 1, (Handle)0x12345678, &ecfg, &hEMAC );".

Then by digging deeper, I found it's because i didnt' call "DSK6455_I2C_init();" and  "DSK6455_EEPROM_read(0x00007F00, (Uint32)bMacAddr, 8);"  when i ported my program from the "client" example. After fix this, the initialization passed, and link status tells me fine now.

But I found my udp receive didnt' work in jumbo frame mode, here is my code:

rv = recvfrom(t_NetComHdl.s_recv, p, len, 0, (struct sockaddr*)&RemoteAddr, &len2);

it will block at this point, meaning receiving nothing. 

And if i justt undefine "_INCLUDE_JUMBOFRAME_SUPPORT", making it woking in non-jumbo frame mode, nothing else changed, then udp receive turns to work.

So what's the problem, am i still missing something.

thanks,

Weslly

Weslly,

Great news that you got past that initial problem!

weslly li said:

rv = recvfrom(t_NetComHdl.s_recv, p, len, 0, (struct sockaddr*)&RemoteAddr, &len2);

Can you take a Wireshark capture of this scenario and attach it here?  I'd like to see the packets you are trying to receive on the wire.

Also, with the capture, please tell me the IP address of the target and the other network host (maybe a PC you are sending UDP packets from?)

Steve

Hi, Steve,

Yes, the other end is a PC with a giga-bit eth-card. PC and c6455-baord are wire-connected directly, no passing any other device.

And some information list below:

(1)pc's ip: 192.168.8.238

(2)c6455's ip: 192.168.8.239

(3)c6455's mac addr: 00:01:02:03:04:05

Capture data for jumbo and non-jumbo mode both attached. Jumbo mode means including the MACRO "_INCLUDE_JUMBOFRAME_SUPPORT", and non-jumbo mode means excluding it. For both experiments, I clicked my pc's app to send a UDP packet. You can see it from non-jumbo.pcapng, but not in jumbo.pcapng. Seems pc actually didn't send this packet out when board is in jumbo mode? And it's bcause the ARP stuff is incorrect?

By the way, need i rebuild the NDK stack? You see, to solve the initial problem above, i added some source files "pbm.c jumbo_pbm.c ..." into my project, and changed something, then built together with other files. Is this way OK? Could it be the reason to cause this strange problem?

thanks a lot,

Weslly

3326.cap.rar

Weslly,

Thanks for attaching those capture files, that was very helpful, especially to have both cases.

I can see in the non-jumbo case, the PC sends an ARP request for the DM8148 (packet #24) in order to find the board's IP address.  The board responds in the next packet (#25).  At this point, the PC has the IP address, and so it is able to send the UDP packet (#26).  This all makes sense.

Looking at the jumbo case, we can see 2 different ARP packets of interest.

1. packet #7
   1. The board broadcasts a gratuitous ARP to the network
   2. The PC should have gotten this ARP and updated its ARP table with a MAC - IP address mapping for the board.
   3. Note that this packet is sent at time 8.6 seconds
2. packet #163
   
   1. PC sends out an ARP for the board's IP address
   2. Note that this happens much later, at time 211 seconds
   3. The board never responds to this ARP

Regarding the timings, it seems you sent the UDP packet ~200 seconds after running the NDK app on the board (the NDK sends that gratuitous ARP very early on in the stack bring up).

First, I'm wondering what would happen if you tried sending the UDP packet sooner in this case?  I'm guessing that the PC would have added an ARP table entry for the board in result of packet #7.  So in this case, it wouldn't need to ARP as was seen in packet #163.  Maybe you'll see the UDP packet in this case?

But even so, I think there is still an issue.  Why didn't the board respond to that ARP (#163)?

I think it may be worthwhile to put a break point into the NIMUReceivePacket() function (ndk_2_0_0/packages/ti/ndk/src/stack/nimu/nimu.c).  All packets received will pass through that function, so we should see if your PC's ARP packet #163 is reaching this code.

In particular, you should add a break point at the following line of code in bold (at line 265):

        case 0x806:
        {
            /* Received packet is an ARP Packet. */
            LLIRxPacket( ptr_pkt );
            break;
        }
Does the ARP packet reach this case?

weslly li said:

By the way, need i rebuild the NDK stack? You see, to solve the initial problem above, i added some source files "pbm.c jumbo_pbm.c ..." into my project, and changed something, then built together with other files. Is this way OK? Could it be the reason to cause this strange problem?

Are you still linking with the NDK's jumbo libs? (you mentioned this in your original post).

weslly li said:

i added some source files "pbm.c jumbo_pbm.c ..." into my project, and changed something

Which changes did you make?  Anything that could affect ARP?

If you don't think you need these changes, it may be better to remove them from your app, so that you link in the original code, that's in the jumbo libs.

Steve

Hi, Steve,

Sorry for late response, we are in the spring-festival holiday.

I gave it a try as you suggested, for this experiment, both non-jumbo and jubmo modes sent udp packet quickly after board initial up. And jumbo mode still got problem, please refer to the attechment.

And for the second suggestion, i added nimu.c into my project, rebuilt and set the points,  for non-jumbo mode, it reached that point meaning received  an arp packet. While in jumbo mode, it can't, by digger deeply, it cann't even enter NIMUReceivePacket<-EmacPktService<-NIMUPacketService. Seems stack cannot receive anything from the bottom?

Yes, I'm linking all the libs, including:

csl_c6455.lib

dsplib_a64P.lib

fastrts64x.lib

hal_eth_c6455_jumbo.lib

hal_eth_stub_jumbo.lib

hal_timer_bios.lib

hal_userled_c6455.lib

IQmath_c64xp.lib

IQmath_RAM_c64xp.lib

miniPrintf.lib

netctrl_jumbo.lib

nettool_jumbo.lib

os_jumbo.lib

stack.lib

TIBenchmarkRouting64plus.lib

And to fix initial "unregister..." problem in jumbo mode, i only need to include "jumbo_pbm.c" and change "JUMBO_RAW_PAGE_COUNT" from 16 to 64.  Here is printing message of running-up:

Using MAC Address: 00-01-02-03-04-05

EMAC should be up and running

EMAC has been started successfully

Registeration of the EMAC Successful

Network Added: If-1:192.168.8.239

Service Status: Telnet   : Enabled  :          : 000

Service Status: HTTP     : Enabled  :          : 000

Link Status: 1000Mb/s Full Duplex on PHY 0

But for non-jumbo mode, it's a little wired,  besides the above change in "jumbo_pbm.c", i also need to include "ethdriver.c" and change nothing to it, just build it with my project. If not,  initial problem appear again:

TCP/IP Stack Example Client

Using MAC Address: 00-01-02-03-04-05

Error: Unable to register the EMAC

Service Status: Telnet   : Enabled  :          : 000

Service Status: HTTP     : Enabled  :          : 000

This wired thing makes me consider if there are some dependency between ndk files,  so if i just put "jumbo_pbm.c" on the surface to build, while others inside the libs, may cause some weired problem i never know.

thanks,

Weslly

4834.wireshark_20160213.rar