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.

BSS sizes using TI-RTOS

Other Parts Discussed in Thread: SYSBIOS

Hi,

We've just switched over from using the NDK/NSP/SysBIOS individual packages to the new TI-RTOS combined package on an LM4F processor. Using the old stack, when I just have the usual Sys/BIOS features we are using enabled (BIOS, Task, Timer, HWI, Memory, Error Handling, Timestamp), compiling in Release mode and looking at the .map file, our BSS is of length 0x1794. 

With the new stack, in the same configuration, the BSS appears to be exactly the same size. So, it looks like everything is working so far. And then...

As soon as I enable any networking feature (TCP, UDP, or IP) my BSS balloons to 0xeca8. The funny thing to me is, if I enable IP and it grows to that size, and then I enable TCP and UDP both, the BSS size does not change. It is still of length 0xeca8. Not only does it seem like this might be pulling in all the NDK features regardless of whether I check the box or not, it is also quite large (our BSS maximum size is 0x8000 according to the linker).

I also get a message that the NIMUDeviceTable is undefined, which is apparently a symbol in the NDK (inside TI-RTOS). I am not sure if this is related.

I have a few questions:

1. Am I using the new TI-RTOS package correctly? Since this appears to be a collection of existing packages including Sys/BIOS and the NDK, I assumed it did not need much more configuration than those.

2. Why does enabling IP, TCP, UDP, or any other networking feature use the same amount of space, and so much space? As I noted, it seems quite large even considering the buffer sizes for something like TCP.

3. What can I do to reduce my BSS size so that I can get my project to compile?

  • Hi Benjamin,

     

    First a couple quick questions...what is the version of TI-RTOS are you using? Also what device are you using?

    I expect the network buffers are accounting for the majority of the BSS space.

    When you used NDK/NSP/SYSBIOS, was the application working? Did you use the graphical configuration for the NDK? If not, how did you specify the network buffers.

    Can you attach the mapfiles from both applications (TI-RTOS one and NDK/NSP/SYSBIOS)?

    The NIMUDeviceTable is currently specified in the EMAC driver in TI-RTOS. Did you do a useModule of ti.drivers.EMAC in the .cfg? This should have brought the EMAC library into the application.

     

    Todd

  • Hi Todd,

    We are using version 1.1.0.25, which seems to be the latest on the website. 

    We had not yet enabled the networking features under the old NDK/NSP/SysBios packages, as there was a bug in the NDK where miniPrintf was not defined and caused compilation to fail. Using the newest NDK (2.22.00.06), I verify that I no longer have this miniPrintf problem, but I do see the same error that I get under TI-RTOS.

    I've attached the files from the two builds so you can look at them - in both cases I enabled only TCP, no other networking features.

    I did not specify to build EMAC. One of the things I am concerned about is how the memory size does not change if I add/remove any networking features. I do not need EMAC and it should not be included - is there any way I can vet what's being included? It seems like it may be included a lot of features I don't need which is blowing out my SRAM.

    5001.ProjectNDK.txt

    If the network buffers are accounting for this space, how can I rework my BSS/features/code so that I can fit into my SRAM? Can I reduce the network buffers from 50kb (0xeca8 - 0x1794 = 0xD514 bytes added when I add in just TCP and my part only has 0x8000 bytes of BSS space total) to something more reasonable?

    Thanks,

    Ben

  • Ben,

    Can you attach the NDK/NSP/SYSBIOS mapfile also? I only see the TI-RTOS one. Can you attach the .cfg file for the TI-RTOS one also?

    The version of TI-RTOS that you have is shipping a newer NDK (2_22_01_14), so I'm surprised about the miniPrintf error. Can you attach the error you are getting?

    Are you planning on using IPv6? I noticed that it was in the mapfile. Removing that saves some space.

    Todd

  • Hi Todd,

    That's strange, it indicated that it attached both files. Let me try again.

    Here is the NDK/NSP/SysBios file:

    1321.ProjectNDK.txt

    And here is the TI-RTOS one

    1222.ProjectTIRTOS.txt

    Here is the config for the TI-RTOS as you requested:

    2626.app.cfg

    I left TCP enabled in this one, so this build does not work.

    The mini-printf error was in NDK 2_21, which we had previously. This is why we had not enabled TCP before switching to TI-RTOS. I had to upgrade our old build to the new NDK which you saw here (2.22) in order to prove that I got the same error as I did when using TI-RTOS. Sorry for being unclear about that.

    Yes, we do plan to use IPv6, it is a key requirement for our project. That shouldn't be in the map file though, as I had only enabled TCP - no IP layer at all should have been enabled. I just checked and the IP box remains unchecked after enabling TCP - was IP enabled anyway for some reason? That would confirm my suspicion that more things are being enabled than I am checking boxes for. Is there a way to stop that?

  • Hi Ben,

    When you say you are using TI-RTOS, do you mean that you checked the TI-RTOS product in Project Properties?

    You are getting the unresolved symbol because you are not adding the EMAC driver in the .cfg file. The following adds the driver

    var EMAC = xdc.useModule('ti.drivers.EMAC');

    When you select TCP, other required parts are brought in (e.g. IP).

    You can reduce your RAM usage by changing some items in the NDK. For example, you can reduce the stackSize

    And the number of packets:

    Note: I included the TIRTOS module in my .cfg file

    Todd

  • Hi Todd,

    Yes, I am using TI-RTOS in the way you specified, by selecting it in the RTSC window. 

    I didn't select EMAC because we don't have our EMAC driver yet - a third party is creating this for us. Is there a stubbed version that would let us verify that we compile?

    If I select TCP, and this automatically brings in IP and EMAC, why aren't the boxes checked on those products? Either it should automatically check those boxes so I know those products are in, or it should complain to me that they are not checked - secretly including them means I have difficulty figuring out what's going on and have to make forum posts like this one.

    Thanks for the description of how to reduce the network stack size - do you think this would reduce memory by that much? I'll try the suggestions and post if it's not sufficient.

    Thanks,

    Ben

  • Ben,

    The NDK has some granularity, but the main stack is a single unit. This was done to allow the code to fit into small embedded systems. There is a clear demarcation line between the Ethernet driver and the stack (NIMU interface). Also in the Global module, you can select the stackLibType to include (or exclude) NAT, PPP, and PPPOE.

    Todd