Getting two DHCP clients

Just for added information here is the console output and the task screen shot at that point. The unit responds to pings correctly at this point:

Service Status: DHCPC    : Enabled  :          : 000
Service Status: DHCPC    : Enabled  : Running  : 000
Network Added: If-1:10.1.10.153
Service Status: DHCPC    : Enabled  :          : 000
Service Status: DHCPC    : Enabled  : Running  : 017
Service Status: DHCPC    : Enabled  : Running  : 000
00000.938 BindNew: Duplicate bindings ignored
00006.079 BindNew: Duplicate bindings ignored
00011.179 BindNew: Duplicate bindings ignored
00016.280 BindNew: Duplicate bindings ignored
00021.480 BindNew: Duplicate bindings ignored
00026.580 BindNew: Duplicate bindings ignored
00031.683 BindNew: Duplicate bindings ignored
00036.880 BindNew: Duplicate bindings ignored
00041.981 BindNew: Duplicate bindings ignored
00047.181 BindNew: Duplicate bindings ignored
00052.281 BindNew: Duplicate bindings ignored
00057.381 BindNew: Duplicate bindings ignored
Service Status: DHCPC    : Enabled  : Fault    : 002

Hi John,

      I'm taking a look at the data you've provided and will get back to you hopefully with a solution

Thanks,

Moses

Hi Moses,

         Thanks for the look as I need to resolve this. Seeing that it does not happen running the example code only we believe it must be some other system interaction with the NDK.

John C.

Hey Moses,

     Has anyone had a chance to look at this? We are trying to get several tcp ports running and we are seeing some strange things (ROV NDK debugger ip address is different from what is reported in the debugger console window). We need to resolve this to move on with further testing.

Thanks,

     John C.

This is my weekly request to TI for some feedback on this question.

Thanks,

    John C.

John,

       Really sorry about this. Lost track of this. Thanks for being persistent to bring it to our attention. I'm forwarding this to people who know more about this. I'll keep track of it to make sure your problem is solved.

Moses

Hi John,

Can you add the following line of code into the *.cfg file for the app that's showing this issue and tell me the result?

    var Global = xdc.useModule("ti.ndk.config.Global");
    print("NDK code generation set to: " + Global.enableCodeGeneration);

...

In your first screen shot (in your first post) you show a call to ConfigureDHCPClient().  Which function is that call being made in?  Do you know who calls it?

I think we need to find out where/who is creating that second DHCP client thread.  Can you put a break point at ConfigureDHCPClient()?  Does it get called more than once?  If so, once the break point hits, can you go to the address that's in register B3?  (B3 contains the return address, you can see this via the CCS register view).

If you copy the address that's in B3, and then paste it into the dis/assembly window and hit enter, it should take you to the assembly code of where ConfigureDHCPClient() was called.  Once there, keep scrolling up in that window until you see the symbol of the function you are currently located in.  Hint - click the mouse within the dis/assembly window in order to get the mouse cursor in there.  Then use the keyboard up/down arrow to navigate the assembly code (that window has refresh problems when using the window's scroll bars and will show you inaccurate assembly code ... using the keyboard avoids this).

Steve

Hey Steve,

            Here are some answers:

1. NDK code generation set to: true
2. The call to ConfigureDHCPClient() is being made from a task called "ethernet_task". It is a priority 10 (of 16).
   It is called from the GetAssignedIP() function which is copied from the ethernetip_adapter example located in sdk 1.1.0.4.
3. It is not called more than once.

After ConfigureDHCPClient() is called, there is a loop in GetAssignedIP() that waits until it gets a IP address. When it exits this loop with an address obtained from the network, there are two DHCP_clients. The GetAssignedIP() function is in the main.c file of the ethernetip_adapter example.

John C.

Steve,

     Have you found anything on this issue as my attempt at getting the ethernetip_adapter example from sdk 1.1.0.5 is not working and I need to resolve this issue.

Thanks,

     John C.

John,

I've been looking at your *.cfg file from your other thread.  I'm assuming it's the same one you're using for this issue, but let me know if I'm not correct.

I'm wondering why the call to ConfigureDHCPClient() is needed.  Based on your configuration, you have the default settings for the NDK, which results in it running as a DHCP client.

I think what may be happening is the NDK is generating the code to start up DHCP client, and additionally the ConfigureDHCPClient() function is creating a DHCP client, resulting in both.

Can you try commenting out the call to ConfigureDHCPClient()?  What happens if you do that?

Steve

Steve,

     The other thread is based on sdk 1.1.0.5 ethernetip_adapter example which ends up being completely
different from the sdk 1.1.0.4  ethernetip_adapter example. The reason for the call to ConfigureDHCPClient() is that in the 1.1.0.4 example uses it so you could run in either static or dhcp
mode. This ability is exactly the same as all the older lwip examples and what is used in our current product where we normally use static, but there are certain situations where dhcp is preferred.

     So the question in this thread is based on the 1.1.0.4 sdk example which uses the call to
ConfigureDHCPClient. If I don't call ConfigureDHCPClient, nothing happens. The DHCP client task is not created and no IP address is gotten.

John C.

John,

Can you please attach your *.cfg file as well as the generated *.c file that correspond to this project?

The generated *.c file should be in your project, deep down under the "Debug" or "Release" folder.  For example, in my project it's here:

Debug\configPkg\package\cfg\tcpEchoCC3100_pem4f.c

Thanks,

Steve

Steve,

         I've zipped the two files up. I'm not sure how much they will help as I really think this issue is occurring because of task priorities. I've had to do a lot of massaging of the NDK task settings to even get this to work. One of the main changes was to the ndkThreadPri which needed to be pushed up to a priority of 11 from 5. The ethernetip_adapter example does not have many tasks so how the ndk interacts with a system having 7 or 8 tasks is quite different.

John C.

6746.pst.zip

Hi John,

Thanks for attaching those files and above screen shot, they are indeed helpful.

That generated .c file contains the results of your configuration (*.cfg) file settings, translated into C code, so it shows me the end result.  So, I can see what code/settings are running for the NDK for this app.

Looking at the *.c file, I can see that it is indeed creating a DHCP client, in addition to the one created by the call to ConfigureDHCPClient():

This looks to be the reason for the 2 DHCP client tasks that you see in your app.  Each of the above CfgAddEntry() calls results in a call to TaskCreate(..., "DHCPclient", ...).

Which brings us back to this problem:

John Conover said:

If I don't call ConfigureDHCPClient, nothing happens. The DHCP client task is not created and no IP address is gotten.

The result you have found here is surprising to me.  I would have expected that if the code on the left is commented out, then the NDK config code on the right should still create its DHCP client task.

As you mentioned, I'm wondering about priorities, too.  I see that the ethernet_task is running at pri 10, but the NDK stack thread is running at the lower pri of 8.

A couple of things to try:

1. Using the original settings of this app (that lead to you seeing 2 DHCPclient tasks), can you please put break points at the ConfigureDHCPClient() and ti_ndk_config_ip_init() functions?  Make sure you hit the calls to CfgAddEntry() for each case.  Also, put a break point at the function dhcpState().  Which order do you see the break points hit?

2. Keeping the same break points, can you please comment out the contents of the ConfigureDHCPClient() function?  Then repeat.  Please confirm that you reach the ti_ndk_config_ip_init() function and the call to CfgAddEntry() within it.  If you don't see the break point at dhcpState()happen, please retry, but also put a break point at TaskCreate().  I want to check if you're hitting the create call for the dhcpState() function, in that case.

3. Again keeping same break points, please try changing the priority of the  ethernet_task function, so that the NDK stack thread has a higher priority.  E.g. set the ethernet_task pri down to 5 (same as NDK Normal Task Pri). Now what results do you see compared to the above?

Steve

Hey Steve,

              Answer to question 1:

- Hit ti_ndk_config_ip_init

- Then hit the call in the ConfigureDhcpClient() call in ethernet task.

- Then hit the dhcpState().

Question #2:

- Commented out calls too RemoveIpAddress() and ConfigureDhcpClient() in the ethernet task.

- Hit the break point in ti_ndk_config_ip_init() but not in dhcpState.

Console shows:

Service Status: DHCPC    : Enabled  :          : 000
Service Status: DHCPC    : Disabled :          : 000

- Restart and put a break in TaskCreate. I hit the task create break after the ti_ndk_config_ip_init().

I'm still seeing about changing the task priorities. We have 11 tasks and because sys/bios does not have the ability to do round robin of equal priority tasks, we have had to insure proper operation by giving each task its own priority. So with the NDK level task priories getting interjected into the middle of our own, things are a bit more complex than they need to be.

John C.

Question 3:

- Moved the ethernet task down to a priority 5, reach the TaskCreate breakpoint twice, but I never get an IP address and the dhcpClient task never shows up:

------------------------------------------------------------------------------------------------------------------------------------

Is it possible that because we specify two phy ports it is causing some internal conflict with the dhcp client?

config.phyAddr[0]    = 1; //CPSW_PORT0_PHY_ADDR_ICE2
config.phyAddr[1]    = 1; //CPSW_PORT1_PHY_ADDR_CIDRA
config.numberPorts    = 2;
config.resvd        = 1;
config.macModeFlags    = CPSW_CONFIG_MODEFLG_FULLDUPLEX | CPSW_CONFIG_MODEFLG_IFCTLA;
SetMacConfiguration(&config);

if(AddNetifEntryFn(CPSW_NETIF_INIT) == 0)
        BIOS_exit(0);

Thanks,

     John C.

Also tried ethernet task at a priority 4 with no change. Reach the TaskCreate breakpoint twice, but I never get an IP address and the dhcpClient task never shows up.

John C.

More to try ...

- when you hit the TaskCreate()call corresponding to DHCPState task creation, what happens in the ROV view if you "step out" or "step return"?  Do you see any new Task show up in the ROV Task view list?

- I'm wondering if the TaskCreate()call may be failing.  Can you also check that you hit the break point for the function DHCPOpen()?  And then after that, you hit its call to TaskCreate(), and return from it?  You should see the DHCPclient task after that TaskCreate() call; if not, the call may have failed.

Steve

More clues for you:

1 TaskCreate break:

     R0 = 0x800C794C => NS_BootFlash
     R1 = 0x800BD184 => "ConfigBoot"

2 DHCPOpen break

3 TaskCreate break:
     R0 = 0x800BED04 => dhcpState
     R1 = 0x800BC9AC => "DHCPClient"




In TaskCreate after the call to Task_Object_Create we have a DHCPclient task



Still further down after call to ServiceScan the DHCPclient task is gone:

John,

We need to debug what's going on.  I added some debug trace into the DHCP client code.  Can you please rebuild your app against the attached libraries?

Please be sure to back up the original ones in your NDK 2.23.02.03 install and then copy these ones in.  Then rebuild.

Once you do, please reply back with the trace output.

Steve

3716.dhcpdebug.zip

Hey Steve,

     Replaced these files and did a full rebuild of the project:

C:\ti\ndk_2_23_02_03\packages\ti\ndk\nettools\lib\nettool.aea8fnv
C:\ti\ndk_2_23_02_03\packages\ti\ndk\nettools\lib\nettool_ipv4.aea8fnv
C:\ti\ndk_2_23_02_03\packages\ti\ndk\nettools\dhcp\dhcpsm.c
C:\ti\ndk_2_23_02_03\packages\ti\ndk\nettools\dhcp\dhcpsock.c

Console output during run:

[CortxA8] 

00000.000 DHCPOpen(): Warning: HOSTNAME for DHCP client may be invalid!
Service Status: DHCPC    : Enabled  :          : 000
00000.000 dhcpSocketClose: enter
Service Status: DHCPC    : Disabled :          : 000

John C.

John,

I expected more ... can you please check the SysMin buffer in ROV?  There may be output in there that hasn't been flushed yet.

Steve

Steve,

     Does not seem to be any more in the buffer. I did a full rebuild of my project, but maybe I need to rebuild something else?

John C.

hmm... can you try adding the following *cfg file change to increase the SysMin buffer size, then rebuild and run again?

    SysMin.bufSize = 4096;

Also, put break points at these functions to verify that they are being run:

1. dhcpState

2. dhcpSocketOpen

Same console output. I get breakpoints on TaskCreate but none on dhcpState or dhcpSocketOpen.

John C.

John,

Ok, thanks for trying that.  I'm wondering if this point how hard it would be for you to scale back this project and share with me, so that I could reproduce the issue on my side.  Or, let me know how I can change the ethernet_ip example in order to reproduce the problem.

If not, I we can continue with me sending you updated libraries with new/updated debug traces.

Just let me know what you think ...

Steve

Hey Steve,

                We have run the ethernetip_example from SDK 1.1.0.4 on our board without this problem showing up. That was the main reason I thought it had something to do with the added complexity of more tasks running. If it's ok with you I'd like to give it a couple more tries with this current debug method. Also are there are any other "Debug" Tools in Code Composer that might help?

Thanks for your continued support,

John C.

Hi John,

Can you try the attached updates?  Note there are multiple libraries this time.  Again, please make sure your originals are backed up.

Steve

5430.dhcpdebug2.zip

Hey Steve,

     Sorry for the delay but I was working on getting stuff from the other thread (with the newer NDK) working (I can ping but can't get it to receive). I put in your changes and here is the output:

[CortxA8]

00000.000 DHCPOpen: enter
00000.000 DHCPOpen(): Warning: HOSTNAME for DHCP client may be invalid!
00000.000 DHCPOpen: CfgGetImmediate returned 0
00000.000 DHCPOpen: pNTP->len !=0
00000.000 DHCPOpen: Task create of DHCP Client task success
00000.000 ServiceSpawn: DHCPOpen returned success
Service Status: DHCPC    : Enabled  :          : 000
00000.000 DHCPClose: enter
00000.000 DHCPClose:  DHCP task non NULL, killing it...
00000.000 dhcpSocketClose: enter
Service Status: DHCPC    : Disabled :          : 000

John C.

John,

Ok thanks for trying that.  I am now suspecting that somewhere in the code of the app, the DHCP client is being removed.

I see in eip_ndk.c there is the following function:

EIP_VOID DisableDhcpClient()
{
        CfgRemoveEntry(0,dhcphandle);
}

Can you check if this is being called?

I made a test app to try to reproduce this, and by adding code to remove the DHCP client, similar to the above, and I was able to get output that's very close to what you pasted into your last post.

Steve

Hey Steve,

            I get the same console output and do not hit the break point. Tried both Hardware and normal breakpoints.

John C.

[CortxA8] 00000.000 DHCPOpen: enter
00000.000 DHCPOpen(): Warning: HOSTNAME for DHCP client may be invalid!
00000.000 DHCPOpen: CfgGetImmediate returned 0
00000.000 DHCPOpen: pNTP->len !=0
00000.000 DHCPOpen: Task create of DHCP Client task success
00000.000 ServiceSpawn: DHCPOpen returned success
Service Status: DHCPC    : Enabled  :          : 000
00000.000 DHCPClose: enter
00000.000 DHCPClose:  DHCP task non NULL, killing it...
00000.000 dhcpSocketClose: enter
Service Status: DHCPC    : Disabled :          : 000

Hi John,

Thanks for trying that.  I really feel that a call to CfgRemoveEntry(0, <dhcp client>); is being made somewhere in the app.

I've asked the Industrial SDK Team for help on how to strip out all of the custom DHCP client code from the ethernetip_adapter example.  I think the call may be happening somewhere in that custom code contained in the example, and hopefully we can strip it out and you can just rely on the "normal DHCP" client service that comes from the NDK configuration settings.

Steve

Hi John,

           Can you please try removing the DHCP client related calls from the Ethernet/IP example and try using .cfg file to configure DHCP client. Please comment out the following functions from eip_ndk.c  and use cfg file to configure DHCP Client

In case of ISDK 1.1.0.4

void DHCPReset( uint IfIdx, uint fOwnTask )

static void ServiceReport( uint Item, uint Status, uint Report, HANDLE h )

EIP_VOID ConfigureDhcpClient()

EIP_VOID DisableDhcpClient()

In case of ISDK 1.1.0.5 Comment out 

void CheckDHCPOptions()

void DHCPReset( uint IfIdx, uint fOwnTask )

static void ServiceReport( uint Item, uint Status, uint Report, HANDLE h )

         These APIs enable the application to  enable DHCP client during run time. This is a use case as per the Ethernet/IP spec.

Regards,

Prajith

Hey Prajith,

     I did not have any DHCP client calls in the current test setup for 1.1.0.4. I removed the functions from eip_ndk.c and rebuilt using test code from Steve with the same results. At this point we think it would be better to end this thread and shift our focus to getting the 1.1.0.5 build running. The 1.1.0.4 will work under a static, but without the DHCP ability, we have reliability concerns (it also as the issue running CPSW port 2 vs. the default port 1.) I'll open a new thread on 1.1.0.5 to see if we can fix not being able to recv() data on accepted sockets (though DHCP does seem to work.) Thanks for all the help.

John C.

[CortxA8]

00000.000 DHCPOpen: enter
00000.000 DHCPOpen(): Warning: HOSTNAME for DHCP client may be invalid!
00000.000 DHCPOpen: CfgGetImmediate returned 0
00000.000 DHCPOpen: pNTP->len !=0
00000.000 DHCPOpen: Task create of DHCP Client task success
00000.000 ServiceSpawn: DHCPOpen returned success
Service Status: DHCPC    : Enabled  :          : 000
00000.000 DHCPClose: enter
00000.000 DHCPClose:  DHCP task non NULL, killing it...
00000.000 dhcpSocketClose: enter
Service Status: DHCPC    : Disabled :          : 000