Hi Kumar
First of all it is correct that the jumpers on the EVB must be set up correctly since the DSUB connector is used also for the CAN bus.
UART2_EN must be set with 1-2 and 3-4 on
UART2/CAN must be set with COM_SELA, COM_SELB and COM_SELC all at 1-2
In the uTasker project you can define which UART is used when opening the serial interface:
Eg:
SerialHandle = fnOpen( TYPE_TTY, ucDriverMode, &tInterfaceParameters );
In TTYTABLE tInterfaceParameters you can define the mode of the interface (stop bits, speed etc., whether it used flow control, high/low water markers and whether is uses DMA, plus a few other things too)
The actual physical interface is selected by the value of tInterfaceParameters.Channel
- 0 will use UART0
- 1 will use UART1
- 2 will use UART2
In your hardware setup file (app_hw_m5223x.h) make sure also that resources for 3 UARTs are defined
#define NUMBER_SERIAL (3)
to ensure that the operating system reserves resources for using all 3 interfaces.
Regards
Mark
P.S. Note that CAN is also supported in the project and its use is very similar.
CAN_handle = fnOpen( TYPE_CAN, FOR_I_O, &tCANParameters );
Details are give in the CAN documention: http://www.utasker.com/docs/uTasker/uTaskerCAN.PDF
First of all it is correct that the jumpers on the EVB must be set up correctly since the DSUB connector is used also for the CAN bus.
UART2_EN must be set with 1-2 and 3-4 on
UART2/CAN must be set with COM_SELA, COM_SELB and COM_SELC all at 1-2
In the uTasker project you can define which UART is used when opening the serial interface:
Eg:
SerialHandle = fnOpen( TYPE_TTY, ucDriverMode, &tInterfaceParameters );
In TTYTABLE tInterfaceParameters you can define the mode of the interface (stop bits, speed etc., whether it used flow control, high/low water markers and whether is uses DMA, plus a few other things too)
The actual physical interface is selected by the value of tInterfaceParameters.Channel
- 0 will use UART0
- 1 will use UART1
- 2 will use UART2
In your hardware setup file (app_hw_m5223x.h) make sure also that resources for 3 UARTs are defined
#define NUMBER_SERIAL (3)
to ensure that the operating system reserves resources for using all 3 interfaces.
Regards
Mark
P.S. Note that CAN is also supported in the project and its use is very similar.
CAN_handle = fnOpen( TYPE_CAN, FOR_I_O, &tCANParameters );
Details are give in the CAN documention: http://www.utasker.com/docs/uTasker/uTaskerCAN.PDF
Hi Kumar
I haven't heard of any problem with UART2. The driver code is the same for all UARTs apart from the register accesses.
Here are some ideas and how to debug.
1. If you use the uTasker simulator your can simulate the UARTs and do the same test on your PC - conect the COM port of the PC to the terminal(emulator). You can map the COM port to the UART in app_hw_m5223x.h
#define SERIAL_PORT_2 '1' will map UART2 to COM1
If the result is identical it is a code problem but if it isn't it may be a low level driver problem. In the simulator code problems can be easily tracked down and corrections simply tested.
2. Try in Interrupt and DMA modes (DMA support can be removed globally by removing #define SERIAL_SUPPORT_DMA or on a per channel basis by removing the DMA flag when opening the interface.
tInterfaceParameters.ucDMAConfig = 0; // remove UART_TX_DMA;
3. Which write method do you use? fnWrite(serial_handle, buffer, length); or
fnDebugMsg("Hello World\r\n" );
The result in both cases is that a certain length of data is copied into the output buffer. What you are seeing with "xxxxxxHello World" is that the start pointer is before the start of the string and also the length corresponds to the start of the pointer up to the end of the string which you want to send. This means that it is not that a counter of a pointer are off but these at least match up to the end of the string.
Can you show your write code?
4. With the simulator or BDM you can quite easily follow the write to where the characters are placed into the output buffer. After the copy you can expand the structure to see its state. I have attached a screen shot in the uTasker simulator showing this after writing the message to UART 2.
- fnWrite() calls entry_tty(), which takes the switch CALL_WRITE
- pointer ptTTYQue is set to the output TTYQUE structure.
- fnFillBuf() will be called to place the data into the output circular buffer
- Once this has been performed, compare your structure with mine.
A. check that your input buffer (ptBuffer) is really pointing to the string expected and the length of copied data (Counter) is identical to the length of the string.
B. check that the structure is correct. In my screen shot you can see that the string is 0x0a characters in length (variable chars) and that the string has been set to the beginning of the buffer (circular buffer 0x100 in length with get pointer pointing to it).
Regards
Mark
I haven't heard of any problem with UART2. The driver code is the same for all UARTs apart from the register accesses.
Here are some ideas and how to debug.
1. If you use the uTasker simulator your can simulate the UARTs and do the same test on your PC - conect the COM port of the PC to the terminal(emulator). You can map the COM port to the UART in app_hw_m5223x.h
#define SERIAL_PORT_2 '1' will map UART2 to COM1
If the result is identical it is a code problem but if it isn't it may be a low level driver problem. In the simulator code problems can be easily tracked down and corrections simply tested.
2. Try in Interrupt and DMA modes (DMA support can be removed globally by removing #define SERIAL_SUPPORT_DMA or on a per channel basis by removing the DMA flag when opening the interface.
tInterfaceParameters.ucDMAConfig = 0; // remove UART_TX_DMA;
3. Which write method do you use? fnWrite(serial_handle, buffer, length); or
fnDebugMsg("Hello World\r\n" );
The result in both cases is that a certain length of data is copied into the output buffer. What you are seeing with "xxxxxxHello World" is that the start pointer is before the start of the string and also the length corresponds to the start of the pointer up to the end of the string which you want to send. This means that it is not that a counter of a pointer are off but these at least match up to the end of the string.
Can you show your write code?
4. With the simulator or BDM you can quite easily follow the write to where the characters are placed into the output buffer. After the copy you can expand the structure to see its state. I have attached a screen shot in the uTasker simulator showing this after writing the message to UART 2.
- fnWrite() calls entry_tty(), which takes the switch CALL_WRITE
- pointer ptTTYQue is set to the output TTYQUE structure.
- fnFillBuf() will be called to place the data into the output circular buffer
- Once this has been performed, compare your structure with mine.
A. check that your input buffer (ptBuffer) is really pointing to the string expected and the length of copied data (Counter) is identical to the length of the string.
B. check that the structure is correct. In my screen shot you can see that the string is 0x0a characters in length (variable chars) and that the string has been set to the beginning of the buffer (circular buffer 0x100 in length with get pointer pointing to it).
Regards
Mark
Hi Kumar
A TCP connection will also be closed if the other side is not responding and a transmission TCP frame is repeated too often. The iReset flag is set either when this happens or when the application (your interface) decides that it doesn't want to regenerate data.
[Check how your application is responding to the TCP_EVENT_REGENERATE event. It should resent any non-acked data. If your application would prefer to work with buffered TCP you can alternatively use a TELNET based connection (in RAW mode) which will buffer data and perform windowing, flow control and all retransmissions autonomously.]
I think that it would be useful if you could record the connection close/reset using Ethereal and send this to me. If your board is sending TCP frames which are not acknowledged this will be visible and about 20s later, after a few repetitions, the board will close the connection, sending a RST rather than the FIN because the connection is already dead.
From the data it should be possible to verify this and identify the root cause.
Regards
Mark
A TCP connection will also be closed if the other side is not responding and a transmission TCP frame is repeated too often. The iReset flag is set either when this happens or when the application (your interface) decides that it doesn't want to regenerate data.
[Check how your application is responding to the TCP_EVENT_REGENERATE event. It should resent any non-acked data. If your application would prefer to work with buffered TCP you can alternatively use a TELNET based connection (in RAW mode) which will buffer data and perform windowing, flow control and all retransmissions autonomously.]
I think that it would be useful if you could record the connection close/reset using Ethereal and send this to me. If your board is sending TCP frames which are not acknowledged this will be visible and about 20s later, after a few repetitions, the board will close the connection, sending a RST rather than the FIN because the connection is already dead.
From the data it should be possible to verify this and identify the root cause.
Regards
Mark
Hi Kumar
The use of direct TCP socket can not be mixed with the TELNET solution so it is best to remain with your present solution until you have understood the problem that you have.
The TELNET solution requires opening a TELNET based socket rather that a TCP socket. The TELNET based socket includes all TELNET stuff between the actual TCP socket and the application and it is this which handles much of what your application will presently be handling. A TELNET based socket makes application programming much easier since it handles windowing, retransmission, flow control etc. in a transparent manor. The down side is that it is not so stream-lined as a direct TCP socket since it requires a buffer to be allocated for the tranmitted data. However the user has the choice to obtain the most comfortable, and efficient mix for the project in hand. To learn more about the TELNET support simply activate TELNET support in the uTasker demo project. You can then connect to the board using TELNET and all debug messages are then sent over the TELNET connection. The debug output function fnDebugMsg("Hello World" ); is automatically diverted from the UART handle to the TELNET socket handle when the connection is established and back to the UART when the connection is disconnected. See how the TELNET based socket is configured in debug.c.
Since you are presently using a direct TCP socket, your application must handle the regenerate case by regenerating the last TCP frame data. This is often easy to do if the data is fixed (for example data in FLASH) but is more complicated when the data is volatile since it means a copy needs to be kept until its transmission has been acknowledged. Web server sockets for example don't need to back up transmitted data because it is in the file system and can be simply regenerated (it doesn't have to make a backup in case of frame loss). Other data such as debug data is generated in a more random manor and so can not be simple regenerated without making a backup of it in RAM. For such cases the TENLET based method is the simplest to use. A direct socket is possible but the application is then responsibe for the detailed work, which can be quite complicated if high speed bulk transfer is a criteria.
Therefore check how you are handling the regenerate case. If the applicatioin doesn't regenerate, the TCP connection will in fact understand this as a request to close the connection (which will also be visible in the Ethereal recording). Note that you can not use fnSendBufTCP() if using a direct TCP socket since it has no buffered support. The normal fnSendTCP() must be used. There is then another question - assuming that the cause of the closed connections can be explained by packet loss - why do you have possibly a high level of packet loss in your test network? In a LAN, TCP packet loss is normally so low that you will almost never encounter it.
Regards
Mark
P.S. You can read about the TCP window management performed by the TELNET based socket in the uTasker documentation directory in the file uTaskerTELNET.doc
The use of direct TCP socket can not be mixed with the TELNET solution so it is best to remain with your present solution until you have understood the problem that you have.
The TELNET solution requires opening a TELNET based socket rather that a TCP socket. The TELNET based socket includes all TELNET stuff between the actual TCP socket and the application and it is this which handles much of what your application will presently be handling. A TELNET based socket makes application programming much easier since it handles windowing, retransmission, flow control etc. in a transparent manor. The down side is that it is not so stream-lined as a direct TCP socket since it requires a buffer to be allocated for the tranmitted data. However the user has the choice to obtain the most comfortable, and efficient mix for the project in hand. To learn more about the TELNET support simply activate TELNET support in the uTasker demo project. You can then connect to the board using TELNET and all debug messages are then sent over the TELNET connection. The debug output function fnDebugMsg("Hello World" ); is automatically diverted from the UART handle to the TELNET socket handle when the connection is established and back to the UART when the connection is disconnected. See how the TELNET based socket is configured in debug.c.
Since you are presently using a direct TCP socket, your application must handle the regenerate case by regenerating the last TCP frame data. This is often easy to do if the data is fixed (for example data in FLASH) but is more complicated when the data is volatile since it means a copy needs to be kept until its transmission has been acknowledged. Web server sockets for example don't need to back up transmitted data because it is in the file system and can be simply regenerated (it doesn't have to make a backup in case of frame loss). Other data such as debug data is generated in a more random manor and so can not be simple regenerated without making a backup of it in RAM. For such cases the TENLET based method is the simplest to use. A direct socket is possible but the application is then responsibe for the detailed work, which can be quite complicated if high speed bulk transfer is a criteria.
Therefore check how you are handling the regenerate case. If the applicatioin doesn't regenerate, the TCP connection will in fact understand this as a request to close the connection (which will also be visible in the Ethereal recording). Note that you can not use fnSendBufTCP() if using a direct TCP socket since it has no buffered support. The normal fnSendTCP() must be used. There is then another question - assuming that the cause of the closed connections can be explained by packet loss - why do you have possibly a high level of packet loss in your test network? In a LAN, TCP packet loss is normally so low that you will almost never encounter it.
Regards
Mark
P.S. You can read about the TCP window management performed by the TELNET based socket in the uTasker documentation directory in the file uTaskerTELNET.doc
Hi Kumar
Any activity at the socket (either direction) should retrigger the timeout timer.
In case of a timeout it shouldn't be a major problem for an application since both sides know that the connection has timed out and it will be automatically re-established when data is to be sent (sockets can be defined to works as both listener and client if required so that any side can establish the connection when needed).
At the moment I don't understand exactly the problem with the UART and where in the chain data is getting lost.
It may be an idea to start a new thread if this topic is to be analysed so that the subject is clear for any other uses's wishing to follow it. Otherwise you can also send more details (and code is necessary) to the uTasker support email address.
Regards
Any activity at the socket (either direction) should retrigger the timeout timer.
In case of a timeout it shouldn't be a major problem for an application since both sides know that the connection has timed out and it will be automatically re-established when data is to be sent (sockets can be defined to works as both listener and client if required so that any side can establish the connection when needed).
At the moment I don't understand exactly the problem with the UART and where in the chain data is getting lost.
It may be an idea to start a new thread if this topic is to be analysed so that the subject is clear for any other uses's wishing to follow it. Otherwise you can also send more details (and code is necessary) to the uTasker support email address.
Regards
