TWR-K60D100M Ethernet Connection Problem

[mikekay]

I would be very grateful of some advice with the following problem.

I cannot establish a connection between the TWR-K60D100M and my local network using the TWR-SER board Ethernet interface.

I have tried both the ‘eth_to_serial’ and ‘httpsrv’ MQX RTCS examples, plus I have created a new MQX project using the wizard selecting the ‘Add RTCS Support’, ‘Basic Application’, IP type set to ‘DHCP’. The latter of these projects outputs the following info:

Waiting for ethernet cable plug in ... Cable connected

Contacting DHCP server ...

RTCS failed to bind interface with IPv4, error = 1D04

The defines in the main.h are:

#define ENET_IPADDR IPADDR(192,168,1,200)

#define ENET_IPMASK IPADDR(255,255,255,0)

#define ENET_GATEWAY IPADDR(192,168,1,1)  tried also 192,168,0,1

I have also tried a number of IP addresses which are within the router’s range of IP addresses.

The problem seems to be that the TWR-K60D100M is not being issued with an IP address.

The hardware jumpers are set as followers (as per the tower documentation):

TWR-K60D100M               J10 Pins 2-3

TWR-SER                          J2 Pins 3-4 (CLK_SEL)

                                           J3 Pins 2-3 (CLKIN_SEL)

                                           J12 Pins 9-10 (ETH_CONFIG)

I have checked the boards are mounted correctly to the elevator boards (primary/secondary).

Software versions are:

CodeWarrior 10.6.4.

MQX 4.2

I have built the twrk60d100m bsp, psp, rtcs and shell libraries which are stored at:

C:\Freescale\Freescale_MQX_4_2\lib\twrk60d100m.cw10gcc\

I can run the simple ‘Hello’ example no problem.

I also have a Freescale license so no problem with compiler limitations.

Thanks in advance,

Mike.

[DavidS]

Hi Mike,

Seems like your jumpers are correct.  Attached is ZIP of pictures of my TWR-K60D100M and TWR-SER cards for direct comaprison.

Please also be careful that when you assemble the tower the white stripes of the cards connect to the primary (white) riser.

I loaded up the web_hvac_twrk60d100m MQX4.2 project using CW10.6 and ran is successfully.

Waiting for Ethernet cable plug in ... Cable connected

DHCP bind ...

Shell (build: Feb  1 2016)

Copyright (c) 2013 Freescale Semiconductor;

shell>

shell> Successful!

shell>

shell> ipconfig

Eth#     : 0

Link     : on

MTU      : 1500

MAC      : 00:00:5e:a8:01:ca

IP4      : 192.168.0.42 Type: DHCP

IP4 Mask : 255.255.255.0

IP4 Gate : 192.168.0.1

IP4 DNS  : 209.18.47.61

IP6      : DISABLED

Link status task stopped

shell>

shell> ping 192.168.0.1

Pinging 192.168.0.1:

Press [q] to cancel.

Reply from [192.168.0.1]: time=15ms

Reply from [192.168.0.1]: time=8ms

Reply from [192.168.0.1]: time=5ms

Reply from [192.168.0.1]: time=5ms

shell>

Regards,

David

[mikekay]

Hi David,

Thanks for your reply.

I have also compiled the web_hvac demo and the response is below:

I don't get the message 'DHCP bind' and I notice the Type: Manual?

RTCSCFG_IPCFG_ENABLE_DHCP          1      is set in user_config.h

Any other suggestions?

Thanks

Mike.

Shell (build: Feb  1 2016)

Copyright (c) 2013 Freescale Semiconductor;

shell>

shell> ipconfig

Eth#     : 0

Link     : on

MTU      : 1500

MAC      : 00:00:5e:a8:01:ca

IP4      : 192.168.1.202 Type: MANUAL

IP4 Mask : 255.255.255.0

IP4 Gate : 192.168.0.1

IP4 DNS  : 0.0.0.0

IP6      : DISABLED

Link status task stopped

shell>

[DavidS]

Hi Mike,

Is your gateway address correct?  Should it be 192.168.1.x ?

I'll attach ZIP with the files I have "touched".  Back yours up and try mine.

I had forgotten I had modified the web_hvac to do DHCP so the rtcs.c and hvac.h were modified.  Just look for "//DES" to find the spots.

I'm including my user_config.h too.  I didn't #define RTCSCFG_ENABLE_DHCP in it.  By default it gets set.  But I did define it in hvac.h for the application to use.  Maybe unnecessary????

Regards,

David

[mikekay]

Hi David,

I'm fairly confident our configuration settings match and that my original settings should work with DHCP. I tried the tower on a different router and initially it bound straight away leading me to think it could be a router problem (although other devices connect to the router OK). However, after several attempts at connecting to this alternative router the same error code came up. So I went back to using the original router and made several attempts to bind. It turns out it does bind but only after a number of attempts. Once bound, the success rate of a Ping command varies from 0 (all time-outs) to 100% when four packets are sent. I did wonder, the fact that it occasionally works, the problem might be related to the synchronisation requirement when operating the MAC in RMII mode. But, the hardware configuration settings are set as per the documentation. Some progress, but much frustration!

Best regards,

Mike.

[DavidS]

Hi Mike,

Any progress?

The only time I have seen weird ping results are with the following two independent cases:

- The K60 MAC clock domain not synchronized with the Ethernet PHY clock domain.  The solution is to ensure the same clock is used to clock the PHY and the processor as the Tower schematics show.

- Having two tower kits on the same LAN that have the same MAC address being used (the MQX Ethernet examples hack in a MAC address to use so if multiple tower kits in the system running the same code then there are multiple devices with the same MAC which is bad.

- sprinkling holy water on device sometimes helps ;-)

Regards,

David

[mikekay]

Hi David,

I've not resorted to the holy water just yet! :smileylaugh:

I've loaded the firmware onto a colleague's TWR-K60D100M and his tower binds immediately the Ethernet cable is plugged in. The jumpers settings on both towers match. I believe we have narrowed the problem down to the processor board as we confirmed the serial board from my tower works with his tower. I have scoped the 50MHz clock on both towers at jumper J10 (pins 2 and 3 linked) and the amplitude and wave-shapes match. Again, some progress!

Regards,

Mike.

[mikekay · Accepted solution]

Hi David,

I eventually got it to work :smileyhappy:

I have always supplied power to the tower from the USB debug port on the processor board.

I just happened to connect another USB cable to the Mini-B connector on the elevator board (with SW1 set to USB) and the tower binds straight away and ping commands are successful.

Thanks for your help with this.

Best regards,

Mike.

[DavidS]

Great news.  Thanks for sharing the fix.

Really thought the holy water would have fixed it though!

Regards,

David