• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 51 subscribers
  • Views 62 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.

Original question:

CC2642R: Capture RSSI based on CC2642

CC2642R: Memory Issues of CC2642

junjie Deng
Prodigy 90 points

Part Number: CC2642R
Other Parts Discussed in Thread: SYSCONFIG

Dear TI Support Engineer,
I am currently working with the rtls_coordinator project. I need to implement passive connections and RSSI value collection via BLE advertising, alongside several custom application tasks. To reduce memory footprint, I would like to check if unused tasks inside the project can be disabled.
The application currently crashes during runtime with a memory allocation failure in the execution path: ICall_createRemoteTasks → Task_create → Memory_alloc.
Could I disable unused modules via SysConfig to cut down memory consumption?
Best regards,
 
Deng Junjie
  • 0
    TI__Genius 9390 points

    Hi !

    When building the rtls_coordinator project for the CC2642, I see that I am using only 16% of RAM (12536 bytes out of 77857). Could you re-build your project and run "View > Memory Allocation" to see what is your memory usage ?

    Another thing might be that you are not allocating enough memory for your heap. Do you know what heap strategy you are using and what is your heap size ? Can you share your map file ?

    If you want to optimize the memory of your application, removing unused modules like UART in SysConfig will cut down memory consumption. I don't recommend removing threads, as they are all necessary for the application. You can try to look at this chapter of the user guide if you think the issue is that you do not have enough heap (which I don't think is the issue).

    Kind regards,
    Lea

  • 0 in reply to Lea
    Prodigy 90 points
    Hello,
    The figure below shows my memory allocation diagram.
    The automatic allocation strategy I adopted is recorded in my map file:
    20013c00  heapEnd
200089d8  heapStart


    The heap size is approximately 44 KB.
    However, several of my custom tasks still fail to be created under this configuration.
    We implement dynamic task creation at runtime.
    Looking forward to your reply.
    Deng Junjie
  • 0 in reply to junjie Deng
    TI__Genius 9390 points

    Hi !

    When using CCS, you should be able to see the heap usage of your application with the RTOS object viewer. Can you show me the heap-related data of the RTOS object viewer when the application fails to allocate a task ? How much are you trying to allocate for this task ? Do you make any heap allocation before this task creation ?

    Kind regards,
    Lea

  • 0 in reply to Lea
    Prodigy 90 points
    Hi Lea,
    The ROV tool cannot recognize my project built with TI-RTOS; it only displays FreeRTOS modules and shows no TI-RTOS modules at all. My project is developed based on the rtls_coordinator example from SDK 8.32, using the TI-RTOS7 kernel with the ticlang compiler.
    Preliminary calculations indicate that our tasks and message queues alone require a minimum of 25 KB of heap memory, not accounting for overhead from various scattered dynamic memory allocations.
    Our primary issues are not limited to insufficient heap memory — we also encounter stack overflow detected by Task_checkStacks during runtime. The full call stack is provided below:
    thread_can_tx_handle (allocated stack size: 1024 bytes)
    → can_hw_send_msg
    → sya_can_send → CAN_write (drives the external TCAN455X chip via SPICC26X2DMA)
    → os_sem_wait → SemaphoreP_pend → Task_restore → Task_schedule
    → Task_checkStacks → Error_raiseX
    The Task_checkStacks stack verification error triggers at line 481 in Task.c during task switching. The CAN transmit thread is created via os_thread_create with only a 1024-byte stack allocated. The CAN driver communicates with the external TCAN455X CAN transceiver through the SPICC26X2DMA SPI peripheral with DMA support. Before entering the CAN_write function, the call stack of the can_hw_send_msg chain already occupies nearly the full stack capacity. The subsequent SPI DMA transfer logic consumes additional stack space, ultimately causing the stack overflow fault.
    I have two questions for your advice:
    1. What typical stack depth is consumed by the CAN_write → TCAN455X → SPICC26X2DMA call path? Is a 1024-byte stack generally sufficient for a CAN TX thread on this platform? If insufficient, what stack size would you recommend configuring?
    2. I do not require RTLS functionality. Can I disable RTLS to reduce overall memory footprint? My application only needs BLE features and RSSI acquisition.
    Best regards
    DengJunJie
  • 0 in reply to junjie Deng
    TI__Genius 9390 points

    Hi !

    I don't know what is the stack depth recommened for such things. The steps I recommend you to take would be to increase the stack by a lot, run your function and see the stack peak of your task in the RTOS object viewer. The RTOS object viewer does not work for tirtos on CCS 20 but should work as expected in CCS 12.

    As for the RSSI. the BLE stack can get the RSSI from using the HCI_ReadRssiCmd function with the index of your connection. If you don't need RTLS you can remove it from SysConfig.

    Kind regards,
    Lea