Hi Bert
Your connection looks good but I would expect the menu to be sent as soon as the connection is established.
In your recording there is nothing happening although the serial interface is blocked (which is normal when TELNET is active).
Here is the TELNET output that I see when I test:
Serial number: 00-00
Software version V1.3.010
Device identification: uTasker Number 1
Main menu
===================
1 Configure LAN interface
2 Configure serial interface
3 Go to I/O menu
4 Go to administration menu
5 Go to overview/statistics menu
help Display menu specific help
quit Leave command mode
In fact there are also a couple of TELNET commands sent to negotiate the echo mode before the menu is displayed, also these are not being sent in your case.
I have played through some scenarios and the most probably is that you don't have enough HEAP memory for the buffered connection to operate:
Perhaps you could check the following:
In the TELNET listener function fnTELNETListener() in debug.c the successful connection establishment causes the event TCP_EVENT_CONNECTED to arrive:
case TCP_EVENT_CONNECTED: // TCP connection has been established
ucTelnetMode = 0;
// we start negotiation of the telnet session and say that we will perform echo (only when not a binary TCP connection)
usTelnet_state = ES_STARTING_COMMAND_MODE; // connection starts in command mode
return fnTelnet(Telnet_socket, GOTO_ECHO_MODE); // try to set echo mode
I believe that this is taking place because the state is being set to ES_STARTING_COMMAND_MODE, which would cause the UART connection to be blocked (which you have seen).
The function fnTelnet() will then send a TELNET "WILL ECHO" negotiation, which is however not visible in your recording.
In fnTelnet() in telnet.c something must therefore be going wrong.
TELNET *TELNET_session = fnGetTelnetSession(Telnet_socket);
if (!TELNET_session) return APP_ACCEPT; // not found, simply return accepted by application
switch (iCommand) {
case GOTO_ECHO_MODE:
fnSendNeg(TELNET_session, TELNET_WILL, TELNET_ECHO);
TELNET_session->usTelnetMode |= TELNET_WILL_ECHO; // mark that we want to echo
return APP_SENT_DATA;
Check that the TELNET session is found. I could only really explain it not being found if its internal data structures are somehow getting corrupted during the TCP connection phase; If TELNET_session is zero it would return without doing anything, but I don't expect this to be the case.
fnSendNeg() builds and sends the negotiation telegram via TCP, using fnSendBufTCP().
Coming back to the point about heap memory: TELNET uses buffered TCP (note the use of fnSendBufTCP()) which requires a transmit buffer. This is created on first use, which is in fact when the first negotiation message is send.
Look in fnSendBufTCP() in tcp.c:
if (!tcp_tx) { // we get working space from heap only when we actually use it (we assume such sockets are never released)
if ((tcp_tx = (TCP_TX_BUFFER*)uMalloc(sizeof(TCP_TX_BUFFER))) == 0) {
return 0; // couldn't get required memory from heap!
}
If there is not enough heap memory available to create the buffer the message will not be sent. This seems to be the most probably explanation for your case. If you step through the uMalloc() call it may be returning zero. You can then see how much more heap memory is required to allow it to be successful (OUR_HEAP_SIZE can be increased to allow it to function). The question is then why the heap size has to be increased. This may be due to you adding other code which uses heap and so it is important to always monitor the use of heap (and RAM generally) since it is a precious resource in chips with limited resources.
Good luck
regards
Mark