• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 104 subscribers
  • Views 2354 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.

Concerto TCP/IP memory stack

Sabina Greenberg101872
Expert 2780 points

Hi,
We work with with Concerto (F28m35H52C1 , Sys/BIOS 6/33.3.33, MCU sdk 1.00.47, Tools 3.23 ) with TCP/IP. TCP/IP is running on ARM and takes about 90% of the memory (C0 and S0). We would like to reduce TCP/IP memory by changing buffer size in the buffer tab ( PageSize to 1024 and FrameBufferSize to 512). After this changes TCP/IP stoped working at all. Application is not returned from the function accept(lSocket, (struct sockaddr*)&client_addr, &addrlen).  We have the following questions:

1. is it possible to reduce TCP/IP memory ?
2.If yes  - how to do it. - it seems that we do something wrong here...

Thanks,Sabina

 

  • 0
    TI__Mastermind 22025 points

    Sabina,

    I believe users can adjust the memory usage of the TCP/IP stack, but I'm not an expert on this software.  I'm going to move this thread over to the BIOS forum, and someone there should be able to help you.

    Regards,

    Trey

  • 0
    TI__Mastermind 45025 points

    Hi Sabina,

    First off I'd like to point you to the official MCUSDK 1.0 release!  I recommend that you replace your beta MCUSDK with the 1.0 release that just came out:

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/index.html

    Now ... can you provide a bit more information?  Did you create your app from an existing MCUSDK example?  If so, which one did you pick for your starting point?

    Will your app be using a lot of the peripherals (and drivers) that the MCUSDK supports for Concerto?  If you provide some more details on what the end goal of your app is, this would help us to better help you.

    Sabina Greenberg101872 said:
    We would like to reduce TCP/IP memory by changing buffer size in the buffer tab ( PageSize to 1024 and FrameBufferSize to 512). After this changes TCP/IP stoped working at all

    Yes it is possible to reduce the memory foot print.  However, the NDK is very sensitive to memory changes.  I wouldn't recommend changing the PageSize or FrameBufferSize yet.

    First, I would suggest to change the sizes of the TCP send and receive buffers.  This can be done in the configuration by right clicking on "TCP"  and using it, and then checking the buffer sizes there.  Note that once the TCP module is "used" (green check mark next to it in the overview page of ndk/Global) it will run some code that reduces the buffer size automatically based on your hardware (M3 in your case).  So, if TCP was not "checked" (used) before, you probably had send and receive buffer sizes of 8K.

    Steve

  • 0 in reply to Steven Connell
    Expert 2780 points

    Hi Steve,

    Now we are using msudk 1.0.0.68. Redusing TX/RX buffers size to 512 (from 2048)  doesn't influence to the memory size at all. We started our application from an empty Sys/BIOS project  + msudk package. Our application used periperials on c28(IO, A/D, PWM). We use MSUDK for TCP connection between Concerto and PC.  

    The changes that reduce TCP memory(TCP continue working after this change)  is the following:
    TX/RX buffers size = 512 and PageSize = 768. With this configuration we have 32K free instead of 16k.
    The question is: what is the relation between frame buffer size, number of frames  and Tx/RX buffers size?  Why any changes of Frame buffer size destroy TCP working?

    Thanks,Sabina

  • 0 in reply to Sabina Greenberg101872
    TI__Mastermind 45025 points

    Sabina,

    First off:

    Sabina Greenberg101872 said:
    We started our application from an empty Sys/BIOS project  + msudk package

    It's actually recommended that you start with an existing MCUSDK example (perhaps tcpEcho since you are doing networking).  The MCUSDK uses special builds of SYS/BIOS, XDCtools, NDK, IPC, etc. that are located under C:\ti\mcusdk_1_00_00_68\products.  If you start with a SYS/BIOS example, your application will not be using these versions.

    I also have a question ... do you expect to use HTTP in your application?

    Sabina Greenberg101872 said:
    Redusing TX/RX buffers size to 512 (from 2048)  doesn't influence to the memory size at all.

    Correct.  This is because these buffers are dynamically allocated at run time.  So, although this won't reduce the NDK's foot print itself, it will allow you to reduce the SYS/BIOS heap size (by the amount you reduced these buffer sizes by) and that will give you more memory overall.

    You can further reduce the heap size by using the Runtime Object Viewer (tools -> ROV) to check how much stack is being used for NDK tasks.  You can open ROV from the CCS tools menu.

    - use ROV to check stack usage of the NDK main network task.  This task's stack size is configurable.  Run you app to completion and then halt and check the stack usage in ROV to see how much stack you're actually using.  You may find that you are not using very much compared to the total amount of stack available (2048 by default).  For example, I was able to shrink it down to 1152 in a networking app that I'm running on Concerto that has heavy TCP/IP transferring going on.

    - Similarly for the default stack sizes for tasks of low, medium or high priorities.  Check the usage of you any tasks that you create with the NDK TaskCreate() API and see if you can reduce the stack sizes there.

    - Again, reducing stack sizes for dynamically created NDK tasks won't reduce the NDK footprint, but it will allow you to reduce the size of the SYS/BIOS heap which will allow you to save memory overall.

    Sabina Greenberg101872 said:
    The question is: what is the relation between frame buffer size, number of frames  and Tx/RX buffers size?  Why any changes of Frame buffer size destroy TCP working?

    The nature of the TCP protocol requires a transmit buffer.  It's used for reshaping data or retransmitting data due to TCP window size changes or lost packets for example.

    The TCP receive buffer is used to reconstruct the data received from packet buffers (more on those below). It's possible to eliminate this buffer depending on your application by using the SOCK_STREAMNC socket option.  However, this should only be done if your application will receive data in large bursts.  Please see section 3.1.1 "Enhanced No-Copy Socket Operation" in the NDK API guide.

    The frame buffer size (1536) is the size of an Ethernet frame. This is the maximum amount of data that can go out onto the wire as a packet.  While this is configurable, I wouldn't recommend lowering this number as 1536 is the minimum size of an Ethernet version 2 frame and this size is pretty standard.  I'm guessing this is why you saw your transfers stop working.

    The number of frames is the total number of Ethernet frames in the Packet Buffer Manager buffer pool available.  (I expect that shrinking this number will affect network throughput performance)

    For more information on the PBM and NDK memory allocation system, please refer to the NDK User's Guide and API Guide (spru523h.pdf and spru524h.pdf), which are included in your NDK installation.

    Steve

  • 0 in reply to Steven Connell
    Expert 2780 points

    Hi Steve,

    Thanks for so good explanation.

    We managed to reduce TCP stack(tcp/ip continue working) with the following configuration:
    Tcp.transmitBufSize = 512;
    Tcp.receiveBufSize = 512;
    Tcp.receiveBufLimit = 512;
    Global.pktSizeFrameBuf = 1552;
    Global.pktNumFrameBufs = 6;
    Global.memRawPageCount = 8;
    Global.memRawPageSize = 768;
    it seems that we can reduceTCP/IP stack more by changing Global.pktNumFrameBufs  parameter .

    _mmcheck() command tell us the following memory status:
    18:48   ( 56%)  14:96   ( 87%)  1:128   ( 16%) 4:256  ( 66%)  1:512   ( 66%)  0:1536 0:768 (6144/ 6144   mmAlloc: 40/0/2,   mmBulk: 4/0/2)
     1 blocks alloced in 512 byte page
    16 blocks alloced in 48 byte page
    1 blocks alloced in 128 byte page
    8 blocks alloced in 96 byte page
    6 blocks alloced in 96 byte page
    3 blocks alloced in 256 byte page
    2 blocks alloced in 48 byte page
    1 blocks alloced in 256 byte page

    A question: Do you see any problem with the above setting - or it can be used in our application.

    Thanks a lot for your hepl,Sabina

     

  • 0 in reply to Sabina Greenberg101872
    Prodigy 50 points

    I use LM3S9B92 chip and have similar problems. I am basing on tpcEcho example and I have added http support, registered index.html file on efs but web server did not find that file. I checked that problem exists in mmAlloc NDK function which fails and blocks file registration. I assume that there are memory problems. I tried to use different NDK configuration but usually it ends with memory access exception or unpredictable behavior. Before I recompile NDK with debug options and dig into it, I am posting this and ask if anyone can suggest me what is going on and if it is possible to have SYS/BIOS + TCP + Http on LM39S9B92.

    Regards

    Marek

     

  • 0 in reply to Marek Borowski
    TI__Guru* 96960 points

    Hi Marek,

    You can take a look at the attached PPT (and other files are referenced in the lab). Regarding the "magic" numbers in the ppt, refer to the above posts by Steve. Note: we are working on making the size management better in the next MCU SDK release.

    7367.MakingHTTPServer.pptx

    0876.default.html

    2318.default_withCGI.html

    7776.greetings.html

    Todd

  • 0 in reply to ToddMullanix
    Prodigy 50 points

    Thank you for suggestions. I managed to run tcp/ip and http server, but I had to increase heap to 32k decreasing PBM buffers to 8. It works however system crash due to lack of memory after hitting ctr+R in web browser few times. NDK consume all memory. What about the resources for rest of system ? Space for my program ? I was excited when I was saw that packages first time but now It's sorry to say, I cannot treat NDK for devices like LM3S9D96 other as curiosity at this stage. It's time to come back to uIP and its 3kB needs for RAM :-) waiting for memory optymalized NDK version.

    Update 2012.08.31

    I changed connections limit from 8 to 1. (Usually we don't need many connections). It helped a lot and solved refresh crash issue.

     

     

  • 0 in reply to Marek Borowski
    Intellectual 320 points

    I'm working with Concerto device and I have the same problem with NDK. I don't now how reduce the memory footprint of NDK because I want to create tasks and I need memory for stacks. I would know the best configuration of all buffers in .cgf file in order to optimize the memory. I'm working with tcp_echo example. 

    Tanks!   

  • 0 in reply to xawme88
    Prodigy 50 points

    I eventually solved problem by replacing NDK with lwIP. It also needs some stack tuning like limit buffers e.g. TCP_MSS to 512 bytes but it works using half of memory that NDK used.  However, it looks like TI dropped 96kB RAM microcontrollers line and  I am forced to move to STM32F4xxx. It has 192kB of embedded RAM and with lwIP it should more than enough.  Disadvantage is that we lose good development tools and supported OS, but 32kB RAM used in new TI F4 series is far too less to think seriously of network usage.

    Regards

    Marek

     

    Below my NDK configuration I hope it's last one used.

     

     

    Global.IPv6 = false;Ip.autoIp = false;

    Ip.address = "192.168.100.11";

    Ip.mask = "255.255.255.0";

    var http0Params = new Http.Params();

    http0Params.maxCon = 2;

    var http0 = Http.create(http0Params);

    Memory.defaultHeapSize = 38000;

    Task.idleTaskStackSize = 768;

    Program.stack = 1024;

    var Tcp = xdc.useModule('ti.ndk.config.Tcp');

    Tcp.transmitBufSize = 2048;

    Tcp.receiveBufSize = 2048;

    Tcp.receiveBufLimit = 2048;

    Global.lowTaskStackSize = 1792;

    Global.normTaskStackSize = 1792;

    Global.highTaskStackSize = 1792;

    Global.ndkThreadStackSize = 1792;

    Global.pktSizeFrameBuf = 512;

    Global.pktNumFrameBufs = 8;

    Global.memRawPageCount = 8;

    Global.stackInitHook = '&addWebFiles';

    Global.stackDeleteHook = '&removeWebFiles';

     

    Ip.socketMaxConnections = 2;

    Ip.socketBufMinTxSize = 512;

    Idle.idleFxns[0] = "&blinkLed";

    var clock0Params = new Clock.Params();

    clock0Params.instance.name = "clock0";

    clock0Params.period = 1000;

    Program.global.clock0 = Clock.create("&addSecond", null, clock0Params);

    BIOS.heapSize = 32000;

    BIOS.cpuFreq.lo = 160000000;

    BIOS.libType = BIOS.LibType_Instrumented;

    BIOS.runtimeCreatesEnabled = true;

    Global.memRawPageSize = 1024;

  • 0 in reply to Marek Borowski
    Intellectual 320 points

    This configuration reduces usage of memory but my application doesn't work properly. I'm using tcp_echo example with http server and some other tasks and timers. I only have 21 kb free in SRAM (Concerto M3). I'm looking for some solution in order to increase memory free.

    Thanks!  

  • 0 in reply to xawme88
    TI__Mastermind 26780 points

    Jaume,

    Besides the steps earlier in this thread for reducing memory usage by NDK, have you looked at the more general steps listed in the SYS/BIOS User’s Guide (Appendix D, Minimizing the Application Footprint)?  The user’s guide is in the “docs” subdirectory of your SYS/BIOS install.  The latest guide is posted here: http://www.ti.com/lit/ug/spruex3l/spruex3l.pdf

    Scott