• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 1722 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.

Redefining ASSERT

code2e
Prodigy 250 points
Other Parts Discussed in Thread: SYSBIOS, CC2650

Hi all,

I'm porting some old code from a different processor, and during some renaming I started to get an error that I don't know what to do with. I've decided to rename the old asserts from the other code to ASSERT_alternate and leave the TI asserts to be "ASSERT."

Somewhere along the way I received this error: 

ASSERT    C:\FilepathToProject\src\sysbios\rom_sysbios.aem3<rom_sysbios.obj>

error #10234-D: unresolved symbols remain
error #10010: errors encountered during linking; "project.out" not built

The .aem3 file is unreadable.

What is the rom_sysbios.obj object? 

Where do the TI ASSERT macros get defined?

Thanks!

  • 0
    TI__Guru* 96960 points

    What device and TI-RTOS version are you using?

    I'm going to assume it's a CC26xx or CC13xx device. The rom_sysbios.obj file is the obj file for the TI-RTOS kernel items that are not in the ROM. The TI-RTOS kernel is historically called SYS/BIOS. The kernel code is not directly calling ASSERT (or at least I could not find it). I'm assuming it is pulling it in from driverlib (the kernel uses some of driverlib). I see ASSERT in driverlib's debug.h file, but it's a #define...not a function, so that should not be causing the problem. I don't see ASSERT in the .obj or in the mapfile (which makes sense since it's a define).

    Can you attach your .cfg file (please attach and not copy/paste)?

    Todd

  • 0 in reply to ToddMullanix
    Prodigy 250 points
    Thanks Todd! I can't attach the full file, but here is something that looks promising. It seems to get automatically set in every build, and has something to do with storage in ROM. Does this get set automatically? I think you're right that SYS/BIOS pulls ASSERT functionality from driverlib, I've seen assert swimming about in those files before.

    //BIOS.assertsEnabled = true;
    BIOS.assertsEnabled = false;

    Also, I'm fairly certain that the cause was due to a automatic rename operation that took place. I kept it to only program files that I had created (or tried) but the operation broke assert functionality across the board for all CC2650 applications and example programs.
    I ended up having to reinstall Code Composer Studio & tiRTOS for the CC26xx, which ended up working. Sometimes when uninstalling specific software with the CCS tool and reinstalling it will cause buggy behavior. At one point CCS tried to uninstall the tiRTOS software under my command and somehow the files remained, but CCS claimed that the software was not installed and I could not reinstall it because the installer saw the directory present there. This is the only reason I conducted a full reinstall.

    Thanks for the reply!