• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 827 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.

CC2640R2F: HeapMgr failure: unable to trap HAL Assert

ScanLabs
Expert 5125 points
Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2640

Hello Champions,

I'm working with a "modified" SimplePeripheral sdk 1.40 .

Adding HEAPMGR_METRICS I noticed that when a conncetion is enstablished  both HeapmgrMemAlo and HeapmgrMemFreeTotal are corrupted.

Before a connection is established:

After a connection is established

In order to trap the HAL assertion I added the predefined symbols :

EXT_HAL_ASSERT

MEM_ALLOC_ASSERT

and registered in the main.c the Asser Handler :

RegisterAssertCback(AssertHandler);

Forcing multiple ICall_malloc(500); I can break into AssertHandler and able to see the stackframe , so the platform is well instrumented.

Letting the Peripheral to run , I don't get any Assert when the Heap variables get corrupted .

What I'm missing ? My doubt is that somewhere on the code multiple ICall_free are called.

How I can debug ?

Thank you,

Paolo

  • 0
    TI__Guru 57865 points
    Hi Paolo,
    What changes have you made to the sample app? Significant ones?
  • 0 in reply to J Lindh
    TI__Expert 5125 points

    HI Joakim,

    customer's application is quite complex.

    Now let us focus on how I can trap an assert when Heap metrics get corrupted , I need to understand where inthe code and why Heapmgr has issues .

    Behavior is fully replicable, before connection heap metrics are good, after they are no more useful and system start becoming instable meaning Write on Characteristic need more retry from the Master or Connection is suddely dropped .

    Thank you,

    Paolo 

  • 0 in reply to ScanLabs
    TI__Mastermind 23440 points
    Hi Paolo,

    It's likely that some process is corrupting the heap by overwriting its bounds or also double freeing.

    It's not very easy to catch the heap corruption as it happens since any writes to memory are totally unsupervised, but it can at least be detected after the fact by adding some checks to rtos_heaposal.h manually. Once found, if you find the address where data is written when it shouldn't be you can maybe add a hardware watchpoint (maybe with data match) to get a breakpoint when the write happens on the memory bus. You should probably disable write buffering to catch this.

    See dev.ti.com/.../debugging-index.html and the debug chapter in general.

    If you have enough flash space, you could also use the RTOS HeapTrack module as the heap provider. It is designed to check for errors more aggressively, and will also show you the allocations individually in the RTOS Object View (ROV) in CCS. Please refer to the debug chapter linked above.

    Best regards,
    Aslak
  • 0 in reply to Aslak N.
    TI__Expert 5125 points
    Hi Aslak,

    I have issue enabling ROV HeapTrack .
    Standing to the documentation it should be enough to add:

    #define HEAPMGR_CONFIG=0x82

    I've added this on Project's predefined symbols both on Stack and app . icall.c is now including "rtos_heaptrack.h"
    When ROV is connected , HeapMem.Detailed shows No info "No data to display"
    What I'm missing ?

    Paolo
  • 0 in reply to ScanLabs
    TI__Mastermind 23440 points
    Hi Paolo,

    Then the documentation is unfortunately wrong.

    1. Open the TOOLS/app_ble.cfg file for the project
    2. Find the line utils.importFile("common/cc26xx/kernel/cc2640/config/ble_stack_heap.cfg");
    3. Replace it with the contents of C:\ti\simplelink_cc2640r2_sdk_1_40_00_45\source\ti\blestack\common\cc26xx\kernel\cc2640\config\ble_stack_heap.cfg
    4. Find the line var HEAPMGR_CONFIG = 0x80;
    5. Change it to = 0x82

    This procedure is needed because we don't want to change the global heap_cfg and it doesn't allow overriding from the outside, 2) the CFG file must be changed so that TI-RTOS is configured to use HeapTrack + HeapMem.

    When testing this I realize you also need to increase the stack size for the peripheral.c task: GAPROLE_TASK_STACK_SIZE=640 in the global precompiler defines should do it. HeapTrack uses more stack on allocations. Also increased simple_peripheral stack size to 800. Your mileage may vary. If you find you need to increase the blestack task's stack size, you can do this via changing icall_addrs.h line 133: #define ICALL_TASK_STACK_SIZES { 1000 }

    Best regards,
    Aslak