• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 51 subscribers
  • Views 909 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/CC2642R: ROV task info corrupted in SBP OAD project

Koby Fruchtnis28
Intellectual 690 points
Part Number: CC2642R
Other Parts Discussed in Thread: SYSBIOS, CC2640R2F

Tool/software: TI-RTOS

Running SDK 2.10, SBP OAD project (Simple BLE Peripheral, OAD), in RELEASE mode, the ROV Task info gets corrupted, after this code from main():

  /* Start tasks of external images - Priority 5 */
  ICall_createRemoteTasks();
#endif

Here is the corruption message from the ROV Task view:

Error: java.lang.Exception: Target memory read failed at address: 0x2000477c, length: 76 This read is at an INVALID address according to the application's section map. The application is likely either uninitialized or corrupt.

In particular, the curruption occurs after calling 

ICall_createRemoteTasks
ICall_createRemoteTasksAtRuntime

With Debug configuration, this corruption does not happen.

  • 0
    TI__Mastermind 33460 points
    Hi Koby,

    This is a known issue when using an auto sized OSAL heap. The debug configuration will use HeapMem + HeapTrack so this does not occur.
    There are a couple workarounds posted here: processors.wiki.ti.com/.../CC2640R2_Porting_Projects

    Even the though the above page is for CC2640R2, it also applies to CC2642.
  • 0 in reply to Sean2
    Intellectual 690 points

    Thanks Sean2,

    In the link you have provided the problem is described so:

    When using ROV Classic and auto sized heap, the ROV may generate an exception about reading from and INVALID address. This is related to this XDCTOOLS issue. CCS users are encouraged to use ROV2. For IAR and CCS users using ROV classic, a workaround may be applied by adding the highlighted lines to the package.xs file located at \kernel\tirtos\packages\ti\sysbios\heaps\package.xs.

    To my understanding, the problem only occurs with ROV classic, while I'm using ROV2 (Tools->Runtime Object View).

    So, this known issue is slightly different than my own.

    Also, I come across the same problem in DEBUG configuration in one of my own projects, without any optimizations.

    to solve my issue, do you suggest I add the code to \kernel\tirtos\packages\ti\sysbios\heaps\package.xs, as suggested, even if I use ROV2?

  • 0 in reply to Koby Fruchtnis28
    TI__Mastermind 33460 points

    Hi Koby,

    "To my understanding, the problem only occurs with ROV classic, while I'm using ROV2 (Tools->Runtime Object View)."

    This is correct for CC2640R2F, as in the linker files for CCS on CC2640R2F there is a workaround in place for ROV2:

    /*******************************************************************************
 * ROV
 * These symbols are used by ROV2 to extend the valid memory regions on device.
 * Without these defines, ROV will encounter a Java exception when using an
 * autosized heap. This is a posted workaround for a known limitation of
 * RTSC/rta. See: bugs.eclipse.org/.../show_bug.cgi
 *
 * Note: these do not affect placement in RAM or FLASH, they are only used
 * by ROV2, see the BLE Stack User's Guide for more info on a workaround
 * for ROV Classic
 *
 */
__UNUSED_SRAM_start__ = 0x20000000;
__UNUSED_SRAM_end__ = 0x20005000;

__UNUSED_FLASH_start__ = 0;
__UNUSED_FLASH_end__ = 0x1FFFF;

    Please note that the numbers above are for the CC2640R2F, if you wish to use this workaround for CC26x2, then you will need to adjust the __UNUSED_SRAM_end__ to accound for the 80kB of SRAM in CC26x2 and the __UNUSED_FLASH_end_ to adjust for the 352kB of FLASH in CC26x2.

    Unfortunately it appears that this ROV2 workaround has been removed from the CCS linker files (cc13x2_cc26x2_app.cmd) on CC2642R1.

    I will report this to our R&D team. In the meantime, yes I am recommending that you use the patched .xs file on CC26x2. 

  • 0 in reply to Sean2
    TI__Mastermind 33460 points

    Hi Koby,

    A couple more bits of information

    - I am able to reproduce the issue myself
    - I am able to confirm that the workaround works, HOWEVER, the end address must be modified to 0x20014000 instead of 0x200005000 as in the workaround for CC2640R2F.
    - I have reported this to the R&D team via a ticket.

    - Based on my review of the cause, I redact my statement about the issue not occurring in debug configurations. It can happen anywhere an autosized heap is used.