Hello,
I need to make sure that my LPC2478 will configure its DHCP only after the physical insertion of the Ethernet cable into the controller (it seems that TCPNet cannot handle a situation where a DHCP enabled controller is startup without a network connection, thus the need to configure TCPNet again or for the firs time once the cable is inserted. Note: of the controller already got an IP address, then had his cable disconnected, there is no problem). It seems that simple interrupt detection won't do the job. Any ideas?
I recall this issue a while back and asking Keil at the time, in the end i monitored the Link State and speed lines between the transceiver and the magnetics with a few spare GPIO.
cheers Darren
I've recently re-implemented the Ethernet driver that Keil supplied (as part of TCPnet) for the LPC3250.
I did not want to but, to be blunt, I could not accept the functionality it provided.
The main reason: it only checked the link type on the startup and, if there were no connection during this time, then there would be a VERY long timeout (due to crude software delays).
Additionally, after it had decided that there was no connection, it would attempt to configure the interface for 10Mbit/half duplex - Unfortunately, the code was wrong and there would sometimes be no communication. (I notified Keil of this and notice that they have now fixed that part of their driver.)
You say "... it seems that TCPNet cannot handle a situation where a DHCP enabled controller is startup without a network connection ...".
I initially though that, but subsequently found that TCPnet does correctly retransmit DHCP messages, but they were not being sent to the cable because the PHY/MAC setup was incorrect.
My replacement driver added a timeslot that I called from the task which maintains the TCP operation. This provides the driver with the ability to maintain a decent PHY auto-negotiation sequence. The DHCP operates well regardless of the initial connection state and the startup does not include un-necessary delays.
I'm not familiar with the LPC2478, though suspect that the Keil supplied network module operates in a similar manner to that of the LPC3250.
If you want more details, let me know
Thank you both for your valuable input.
@IB Shy,
I'm going to try the latest RL-ARM release (4.13). If it still does not work, I'll be asking for your guidance what to do :-)
To my understanding, your extension of the driver executes some parts of the "init_ethernet" in order to setup everything when a cable is inserted. Can you give some more details? For example, how did you conclude that such a call is necessary? Or, if the essential parts of the code are compact, can you post it here?
What I assume right now is that you detected the link as done in "init_ethernet", and if detected, you just perform the configuration. If so, I can do it myself...
Tamir,
The 'init_ethernet' gets called during the initialisation of the TCPnet. The Keil implementation (through conditional compilation) configures the PHY and MAC.
If auto-discrimination is selected, the routine waits for either 1) success or 2) a large timeout. If success, then fine. If timeout, then assume some fixed parameters and continue as it sees fit.
My code triggers the auto-discrimination of the PHY (if that is the required option) and then exits. The timeslot is then called periodically to check the status of the PHY. If a new connection is made, it reads the parameters and sets the MAC accordingly. If a connection is lost, it re-triggers an auto-negotiation.
The timeslot also takes a snapshot of Ethernet parameters (speed, duplex, connection). These details are available through a 'status' call so I can check them within the main application.
I used a timeslot (that is called from the same task that maintains the TCP) because I do not know what the TCPnet does internally [thanks to the crazy pricing of Keil's TCPnet sourcecode!] and I did not want to interfere with it's workings. It could have been done in ways other than a timeslot, but I think it all turned out rather neat. I need to do a little more checking, but so far it looks like a worthwhile effort.
Sorry, but I think code is too big to post here.
IB Shy,
I get it more or less. Just one more thing: what exactly do you mean by "timeslot" ?
I use the word timeslot to describe a function that is called repeatedly from a supervisory loop.
My TCPnet supervisory loop is similar to the following:
static TASK void TaskTcpPoll(void) { for (;;) { ETHERNET_Timeslot(); // Maintain the Ethernet link main_TcpNet(); // Maintains the TCP TCPCLIENT_Timeslot(); // Maintain the TCP client(s) TCPSERVER_Timeslot(); // Maintain the TCP server(s) UDPSERVER_Timeslot(); // Maintain the UDP server(s) } os_dly_wait(1); // Wait a while } }
Thanks a lot for your help!