• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 741 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/TM4C129ENCPDT: TI NDK gets hanged while using multiple TCP clients

Renil Raju
Prodigy 190 points
Part Number: TM4C129ENCPDT

Tool/software: TI-RTOS

Hi all,

I am new to TI e2e forum. I am currently working on one Serial(RS232) to Ethernet converter project.

My working environment as follows:

1. Controller - TM4C129ENCPDT

2. TI RTOS Version : 2.1.0.03

3. NDK version : 2.24.0.11

My prototype board is having one RS232 port and one ethernet board. And currently 5 TCP servers are running for 5 TCP connections from slave devices.

I have to push whatever data coming from RS232 to 5 TCP slaves and vice versa. The maximum data length at one instant, I am assuming as 255 bytes. 

This project is working fine with small amount of data traffic on TCP connection. I mean if I am pushing data at different time intervals at a minimum time delay of 2-3 seconds with maximum of 10 bytes.

But when I am repeatedly pushing data(255 bytes), the all TCP tasks are getting blocked after a few seconds.

Can anyone tell me what would be the issue.

Thanks and Regards,

Renil Raju 

 

  • 0
    TI__Mastermind 30830 points
    Is there anything preventing you from upgrading to the newest TI-RTOS product that support tiva?

    software-dl.ti.com/.../index.html

    That way we can rule out bugs that have been addressed in the two years since 2.01 was released.

    Alan
  • 0 in reply to Alan DeMars
    Prodigy 190 points
    Hi Alan,

    Thanks for your reply.

    Currently we are doing all our project based on "TI RTOS Version : 2.1.0.03". So if I am migrating to latest versions, I think this will create issues for supporting the older projects.

    Could you please tell me is this a Known issue for TI RTOS version 2.1.0.03 or not ?

    And In my current project, I'm continuously pushing serial data to TCP clients. If I make any delay will it solve this problem?

    Thanks and Regards,

    Renil
  • 0 in reply to Renil Raju
    TI__Mastermind 30830 points
    I reviewed the release notes from the NDK releases:

    software-dl.ti.com/.../

    Nothing stands out.

    Is it possible you're running out of PBMs? You need to service the receive side periodically so that the pool of available PBMs doesn't get starved.

    Does this forum discussion help in any way?:

    e2e.ti.com/.../490959

    Alan
  • 0 in reply to Alan DeMars
    Prodigy 190 points

    Hi Alan,

    Thank you so much for your reply.

    The problem was,  I was pushing the data directly from UART to TCP clients continuously and in my code I was using 20 mS of fixed delay for

    UART read timeout.

    So whenever the lower baud rates were used, it will divide the data into parts and it was sending to TCP one by one. Now I changed the program logic so that it will calculate the timeout required from the configured UART parameters and so this will wait for the entire data set and will transmit as one block.

    This above logic  temporarily solved my problem but I am not sure this was the actual problem.

    Alan could you please have a look at my PBM configuration and suggest me an optimum buffer size selection. The maximum data size from UART to TCP clients will be 255 bytes at one shot.

  • 0 in reply to Renil Raju
    TI__Mastermind 30830 points
    If you set the 'readTimeout' to zero, UART_read() will only return when the number of bytes requested have been received. Would this work for you?
  • 0 in reply to Alan DeMars
    Prodigy 190 points
    Hi Alan,

    I am Sorry for my late reply.

    Now the problem is solved by using the UART Read Callback function method and it is working as expected.

    Thank you so much for your support during the discussion.

    Thanks and Regards,

    Renil Raju