CCS/LAUNCHXL-CC26X2R1: ROV Target memory read failed error with xdc v3.61.02.27

It looks like my snapshot didn't make it through so I'm attaching the file here:

Hi,

Can you confirm you have done the modification described in the warning section of the document you shared?

Regards,

Yes, I had verified the information in the warning section.  SDK v4.20 already had the patch implemented so I didn't need to add anything.  Below is the function from SDK v4.20

\kernel\tirtos\packages\ti\sysbios\heaps\package.xs

function init()
{
    /* Add HeapMem's primaryHeap addresses range to ROV's memory sections */
    if (xdc.om.$name == "rov") {
        var HeapMem = xdc.module('ti.sysbios.heaps.HeapMem');
//        if (xdc.om['ti.sysbios.heaps'].HeapMem.$used) {
            var Program = xdc.useModule('xdc.rov.Program');
            var HeapMemCfg =  Program.getModuleConfig(HeapMem.$name);
            if  (HeapMemCfg.primaryHeapBaseAddr != null) {
                var base = Program.getSymbolValue(HeapMemCfg.primaryHeapBaseAddr.substr(1));
                var end = Program.getSymbolValue(HeapMemCfg.primaryHeapEndAddr.substr(1));
                /* Retrieve the MemoryImage java object. */
                var Model = xdc.module("xdc.rov.Model");
                var memReader = Model.getMemoryImageInst();

                /* retrieve the sections list and add a new section */
                var sections = memReader.getSections();
                sections.addSection(base, end-base);  
            }
//        }
          /* Retrieve the MemoryImage java object. */
          var Model = xdc.module("xdc.rov.Model");
          var memReader = Model.getMemoryImageInst();

          /* retrieve the sections list and add a new section */
          var sections = memReader.getSections();
          sections.addSection(0x20000000, 0x20005000);
    }
}

~dawn

Hi Dawn,

It looks like memory corruption is happening someplace. I expect a Task object is getting clobbered.

1. Can you do a ROV->BIOS->Scan for Errors?

2. How long do you let it run before you get the invalid read. Can you stop it sooner and see if you might be getting close to blown either the System stack or a task stack.

Todd

Hi Todd,

This was good information.  ROV->BIOS->Scan for Errors gives me the same error; however, I stepped through my startup code and after executing ICall_createRemoteTasks(), the error occurs.

I traced into the function and it's creating the iCall task stack with a size of 4096 bytes.  The 4096 bytes is coming from ti\simplelink_cc13x2_26x2_sdk_4_20_00_35\source\ti\ble5stack\icall\inc\icall_addrs.h.

Does the iCall stack need to be that big?

Dawn

Hi Dawn,

I'm not too familiar with the ICall code (my focus is the kernel). I'd bump up the stack size(s) and see if that helps. You can reduce it accordingly afterwards.

Todd

Hi Todd,

I tried increasing the ICALL stack size from 4K to 5K and I tired reducing it to 2K.  In both cases, I still get the ROV error.  I happens when

task = Task_create(ICall_taskEntry, &params, NULL);

is called in ICall_createRemoteTasksAtRuntime().

If I just let the system run, I know iCall is running because I can see advertisements and I can connect.  Could you forward this to someone who might be familiar with iCall so see if they know if there is anything special with the iCall stack?

Thanks,

Dawn

One last thing to check. What is the stack size of the task being created in the call? Are you supplying the stack or letting the kernel allocate it (e.g. is arams->stack set or not) How much memory is left in the heap (ROV->HeapMem). It could be that you are running out of memory.

The params->stack is set to 0 so it must not be supplied.  The stack size is 4K.  Here's a snapshot of the params:

When I bring up ROV>HeapMem>Basic, it says "No data to display".  ROV>HeapMem>Raw shows:

To me, this looks like the heap is not created yet.  If that's true, I don't know how anything is working correctly.  What are your thoughts?

Dawn

I should also mention that I have a printf statement in my App code to display how much heap we have and then later how much we are using and the printf shows:

Using Heap: OSAL. Heap Size = 58696 (bytes)

Dawn

Hi Dawn,

Can you look in ROV->HeapMem->Detailed?

Todd

Hi Todd,

After I run to a breakpoint before the iCall task is created, I see:

After the iCall stack is created, I see:

Dawn

Hi Dawn,

I expect you are using the heap from the BLE stack instead of the kernel (HeapMem). I'm moving this to the BLE team.

Todd

Hi Dawn,

Have you followed the section of the debugging guide related to Heap Issues? It would be interesting to see the result of the function ICall_getHeapMgrGetMetrics(). 

In addition, could you try to increase the stack dedicated to the tasks related to BLE? 

Regards,

Hi Clément,

Yes, we followed that section when we created the project under SDK v3.10 and now we have this problem with SDK v4.20.

We use the heap metrics in our debug build to alert us of memory leaks and how much of our heap we are using.  We print statements to the debug window and the first time the monitor runs, it prints the following...

Using Heap: OSAL. Heap Size = 58696 (bytes)

Subsequent runs to the monitor show:

Heap High Water Mark = 11056 bytes
Heap Usage = 18% used)

Our monitor uses ICall_getHeapStats(&stats).    I also checked on HEAPMGR_SIZE and it shows 58688.

I also increased the iCall task stack size to 5K bytes and had the same issue with ROV.  It's my assumption that this is the "stack dedicated to the tasks related to BLE".  Is that what you mean?

Dawn

Hi Dawn,

Can you verify if the issue happens with the out of the box simple_peripheral example? (in other words, can you run the same debug tests on the unmodified simple_peripheral example?)

Regards,