• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 52 subscribers
  • Views 691 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/CC2640R2F: SimpleLink CC2640R2F maybe out of data memory?

Andreas65932
Intellectual 280 points

Part Number: CC2640R2F

Tool/software: TI-RTOS

Hi!

I have some problem with my SimpleLink application based on simple_peripheral example of SimpleLink CC2640R2 SDK Version 1.35.0.33.
Compiler version TI v16.9.1.LTS with optimization level off (for debugging).
Firmware runs on custom hardware with CC2640R2, without 32kHz crystal.
I created one additional Task (Task B) with stack size of 600 Bytes.
Within this task I communicate with a I2C device so I added I2C driver. The size of the application framework for this I2C device is impressive

(sorry I can't tell you what type of I2C device I am using here because this is confidential), if I look at Code Composer's Memory Allocation window I get this result:

simple_peripheral_cc2640r2lp_app: SRAM 15721 Bytes (96%) out of 16368 Bytes
simple_peripheral_cc2640r2lp_stack: SRAM 1040 Bytes (5%) out of 17408 Bytes

The problem is that this complete big firmware image doesn't work as expected, though it seems there is some memory left free.
If I run the code without making any calls to the large I2C device framework (but the additional task for it is still there), nothing is being

linked in from it, code und data size is reduzed and remaining functionality (Bluetooth advertising, pairing connections etc.) works as expected.
Same if I uncomment the call to SimpleBLEPeripheral_createTask() but call the big I2C device framework. Now the I2C device works as expected, but of course without Bluetooth functionality.
So I guess this has something to do with data size used by the firmware image.
I am confused by the output of Code Composer's Memory Allocation window. It shows 100% SRAM with 16368 Bytes respectively 17408 Bytes while from

the datasheet the overall physical SRAM memory of the CC2640R2 is 20kBytes.
Perhaps some data memory gets overwritten? How to interpret these SRAM data readings? Where is the rest of the 20kBytes gone?

ROV output with suspicious stack peak sizes:

Thank you for help!

Andreas

  • 0
    TI__Genius 11740 points
    Hi Andreas,

    Based on your problem description and overall SRAM usage, my guess is that your problem is due to the ICall HEAP being unable to allocate memory.

    In a normal build, typically, the ICall HEAP is the last thing to allocated - it takes the remaining RAM and calls that the ICall HEAP. This is the HEAP that everything in the stack uses, tx buffers, rx buffers, etc. If there isn't sufficient RAM, then you're going to experience the issues you described. (Where the stack task runs without ever pending)

    Anyway- We have a section in the Software User's Guide regarding how to enable HEAPMgr Metrics, I'd give that a shot and see two things - first what is the size of the heap? and second if there's any failed allocations.

    software-dl.ti.com/.../gen-debugging.html

    Regards,
    Rebel
  • 0 in reply to A. Rebel
    Intellectual 280 points
    Thank you, this way I found my heap failure.