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.

CC2640: How to change hwiStackSize as reported in ROV

Part Number: CC2640

I have a projectZero based project using BLE stack 2.2.1

ROV>hwi reports an hwiStackSize of 1024 but hwiStackPeak peaks at 456.

I would like to try an hwiStackSize of 512 but I can not find a place to set this.

I do not have a .cfg file like SimplePeripheral uses for this.

Where can I make this change?

Dale

  • Hey Dale,

    I don't see a projectZero project inside the BLE stack 2.2.1. The following recommendation uses SimplePeripheral as a base. In this SDK, it looks like the .cfg file is located in the source directory and may not have been imported to your workspace. Try changing the cc2640.cfg file located ../../../../../src/common/cc26xx/kernel/cc2640/config/cc2640.cfg. Note, if you are using IAR this will not have an affect and you must go to IAR's project options to configure this.

  • Hi Ammar,

    It has been so many years since the project was begun that I have to go from memory.  I think that I added BLE stack 2.2.1 manually to my projectZero if that is possible.

    Perhaps that is why I do not have an appBLE.cfg file as is suggested in CC26x0 SimpleLinkTm Bluetooth® low energy Software Stack 2.2.x Developer's Guide ( https://www.ti.com/lit/ug/swru393e/swru393e.pdf ).

    In Section 3.11.3 it says I should have a appBLE.cfg file with the ability to set hwi stack as:

    "For CCS, the RTOS system stack is defined by the Program.stack parameter in the appBLE.cfg RTOS configuration file:"

    • /* main() and Hwi, Swi stack size */
    • Program.stack = 1024; 

    The cc2640.cfg file that is in my C:\ti\simplelink\ble_sdk_2_02_01_18\src\common\cc26xx\kernel\cc2640\ directory does not have the above lines so I did not try your suggestion.

    Any ideas how I can properly reference a appBLE.cfg file in my project (I found one here: C:\ti\tirex-content\simplelink\ble_cc26xx_2_01_00_44423_cloud\Projects\ble\ProjectZero\CC26xx\CCS\Config)

  • If your project doesn't have a reference to a .cfg file, I would take the one found in your project and drop it in to your workspace.

    Using simple_peripheral as a reference, you can see that there aren't any explicit calls to the .cfg file in the project properties, so I think doing the above will suffice. I would try that, modify the Program.stack size and then build/flash the project. Finally, check ROV to confirm that your project is referencing the .cfg file correctly.

  • Here is a screenshot that shows that I have tried to do as you suggest but it does not look like ROV is telling me that the appBLE.cfg file I added to my workspace is being referenced since ROV still shows hwiStackSize as 1024:

    Did I put the appBLE.cfg into the correct folder of my workspace?

    Else, what next?

  • Also, in my app_ble_uartlog.cfg is this but as you can see by my code comment it has no affect on hwiStackSize:

    /* ================ Program configuration ================ */
    /*
     *  Program.stack is ignored with IAR. Use the project options in
     *  IAR Embedded Workbench to alter the system stack size.
     */
    if (typeof NO_ROM == 'undefined' || (typeof NO_ROM != 'undefined' && NO_ROM == 0))
    {
      Program.stack = 512; //20021-13 DALE changed stack size to 512 from 1024 
      					   //BUT this did not change the ROV>hwi hwiStackSize of 1024
      Program.argSize = 0;
    }
    else
    {
    Program.stack = 512;
    }

    I am unable to put a breakpoint in this code, does that mean the code is never executed during a debug session?

  • On a lark, I decided to move my modified app_ble_uartlog.cfg file from the TOOLS directory of my project structure and put it in the TOOLS directory of the HaloLogger221Stack project.

    When I did this, I got this CSS message which I said Yes to:

    But I still hand no success in changing the hwiStackSize.

    So, I decided to move the app_ble_uartlog.cfg file back to my projects' TOOLS directory.  At this point the HaloLogger221Stack project would not build, so I used file explorer to move the workspaces' HaloLogger221Stack folder to the recycle bin and put a copy of a backup HaloLogger221Stack folder into its place in the workspace structure.

    Then, when I successfully cleaned and built the projects I immediately noticed that I had about 500 more bytes of free SRAM space and I was excited when ROV>hwi confirmed that hwiStackSize was now 512 Slight smile

    Also, when I remove my edit to the app_ble_uartlog.cfg file, the hwiStackSize remains at 512 Slight smile

    I can't explain this but somewhere deep in the bowels of the building process and my 'lark' excursion there is an answer that I feel no need to find, do you?

  • Well the above solution worked for a month but then between two builds the hwiStackSize went from 512 to 1024 without me changing anything in the code.

    This shows the 512 byte extra SRAM use:

    How can I tell if my project is truly referencing the app_ble_uartlog.cfg file from the TOOLS directory of my project structure?

    Thanks,

    Dale

  • Hey Dale,

    Perhaps the answer might be in the Console build output when you build the project. Do you see any instance where the .cfg file is referenced? This way we can potentially tell what the compiler is referencing.

    You may also right click on the .cfg file placed in your project. As an example, you can see the resolved location, see below:

    In the above screenshot, you'll see the "resource does not exist", which indicates a bad variable is set, which may happen if versions, install paths, etc. are changed. What do you see on your end when checking the properties of the .cfg in your project?

    Can you clarify what version of CCS you are using? Along with the compiler version?

  • A clean build seems to reference it in the Console output.  I have attached a zip file of that output.

    CleanBuildResultingIn_hwiStackSize_of_1024.zip

    Here are the properties of the .cfg file:

    Using CCS Version: 7.0.0.00042 and compiler TI v5.2.6

  • Hey Dale,

    I apologize for this, I know it can be frustrating. The log you sent was helpful, I know the project is linking the .cfg. I'm not really sure what could be going on here. I would advise you to try importing your project to a new workspace to reset.

    When you make the change in your .cfg file, also make sure to do a full rebuild on both the app and stack projects. The default projects contain an app_ble.cfg as I alluded to earlier, but the one in the project essentially links to the .cfg file in the SDK directly. I would search for a .cfg file inside your SDK and, as a debug step, copy that .cfg file out of your SDK entirely so CCS has no choice but to use the referenced one. I suspect there is some issue with the environment (perhaps a CCS setting or something in the workspace).

    I was able to test this on a newer version of CCS 11 (I had to take extra steps to install the correct compiler version and link in all the dependencies though) and saw the change take effect as expected. 

  • " I would advise you to try importing your project to a new workspace to reset."

    This made no difference. Here is the clean build (both App and Stack) console output:

    After_importing_to_new_workspace_CleanBuildResultingIn_hwiStackSize_of_1024.zip

    "I would search for a .cfg file inside your SDK and, as a debug step, copy that .cfg file out of your SDK entirely"

    1. First I assume you mean 'move', not 'copy'
    2. I want to be sure that I move the correct file, there are 456 instances of the file on my computer.  Narrowing that down to my SDK directory leaves 76 instances.  I assume my SDK directory is 'C:\ti\simplelink\ble_sdk_2_02_01_18' which I determined from this Resources>Linked Resources>Path Variables list: 
    3. But then I do not see the app_ble.cfg in the Resources>Linked Resources>Linked Resources list: 
    4. How do I find the correct path and know for SURE that I am moving the correct app_ble.cfg?

  • As a debug step, can you import a new example project (try simple_peripheral) from the SDK and try the steps above to change the HWI stack size? Let's rule out any issue in the SDK and/or CCS.

    I want to be sure that I move the correct file, there are 456 instances of the file on my computer.  Narrowing that down to my SDK directory leaves 76 instances.  I assume my SDK directory is 'C:\ti\simplelink\ble_sdk_2_02_01_18' which I determined from this Resources>Linked Resources>Path Variables list:

    The only file I am referring to move out (you are correct I did mean move) is in the following directory: C:\ti\simplelink\ble_sdk_2_02_01_18\src\common\cc26xx\kernel\cc2640\config\cc2640.cfg. You'll notice that all the app_ble.cfg files point to this file as the single RTOS config file in the SDK.

    How do I find the correct path and know for SURE that I am moving the correct app_ble.cfg?

    The .cfg file should show up in the linked resources list (as it does for the default example). The build output shows the .cfg file being built. I'm unsure why you are seeing this issue as the Console build output would be the final piece of evidence needed to verify the proper .cfg is linked. I suspect there must be an issue in the environment somewhere (whether it be CCS, the SDK, or in the project).

  • 1. I started a new workspace and imported simple_peripheral from C:\ti\simplelink\ble_sdk_2_02_01_18\examples\cc2650lp\simple_peripheral

    I clean built it and started a debug session (loaded onto my custom board), at this point I did not select 'Resume (F8)' since I did not know what chaos the program would do if I actually ran it on my custom board.  The ROV tab shows hwiStackSize as 1024.

    The file C:\ti\simplelink\ble_sdk_2_02_01_18\src\common\cc26xx\kernel\cc2640\config\cc2640.cfg shows:

    if (typeof NO_ROM == 'undefined' || (typeof NO_ROM != 'undefined' && NO_ROM == 0))
    {
      Program.stack = 1024;
      Program.argSize = 0;
    }
    else
    {
      Program.stack = 512;
    }

    So, I had expected to see hwiStackSize as 512.

    I even changed the relevant  C:\ti\simplelink\ble_sdk_2_02_01_18\src\common\cc26xx\kernel\cc2640\config\cc2640.cfg contents to:

    if (typeof NO_ROM == 'undefined' || (typeof NO_ROM != 'undefined' && NO_ROM == 0))
    {
      Program.stack = 512; //dale 1024 to 512
      Program.argSize = 0;
    }
    else
    {
      Program.stack = 512;
    }

    But still ROV shows  hwiStackSize as 1024.

    2. Back to my project, I moved cc2640.cfg out of C:\ti\simplelink\ble_sdk_2_02_01_18\src\common\cc26xx\kernel\cc2640\config but ROV still shows hwiStackSize as 1024

    3. "The .cfg file should show up in the linked resources list (as it does for the default example)."

    I take it that you previously noticed neither app_ble_uartlog.cfg, app_ble.cfg OR cc2640.cfg shows up in my linked resources (here is the FULL link resources list again):

    Could this be the problem?  How does one add a linked resource item?

  • Hey Dale,

    It's a bit concerning that the default SDK project shows this behavior. It might be an issue with CCS rather than a project setting. I would suggest posting this issue in the CCS forum to see if they are able to help.

    In the meantime, you may try updating to a newer version of CCS to see if the issue resolves itself.

  • I have been unable to respond until now.

    I have spent countless days and paid for many consultant hours to bring this project into a more modern environment without luck. I think I will stick to the environment that it currently runs in and was developed on. 

    I will start a brief post in the CCS forum and put a link to this topic.

    Here is a link to the CCS topic: https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1072701/codecomposer-unable-to-change-hwistacksize-using-the-projects-cfg-file 

  • Hey Dale,

    I went ahead and edited your post, it looks like the link to the CCS topic was just a link to this thread.

    I'll follow the CCS thread as well to try and narrow down what could be the issue here. I'll close this thread for now. If it locks, we can continue this discussion by hitting the "Ask a related question" button from this page.