CODECOMPOSER: Migrating a DSP/BIOS application, errors "ISA revision, which is not compatible"

Hi Nathan,

Our SME on this topic of DSP BIOS to SYS BIOS migration is currently out of the office and will respond in greater detail when she returns on Dec 15.  In the meantime however, please review our Application Report entitled: Migrating a DSP/BIOS 5 Application to SYS/BIOS 6.  Please do continue to share you experience as you make progress with this migration. 

Regards,

Krishna

Krishna,

Thank you for letting me know and pointing me at the migration document again. I found that "SYS/BIOS 6 uses a larger stack than DSP/BIOS 5, as well as having a slightly larger footprint". 

I discovered that the RAM name had changed and fixed the stack error with this code in the .cfg file:

//SYS/BIOS 6 uses a larger stack than DSP/BIOS 5, as well as having a slightly larger footprint.
Program.stack = 0x200; //decrease the system stack size. 

// Put the stack in a separate area
Program.sectMap[".stack"] = new Program.SectionSpec()
Program.sectMap[".stack"] = "M01SARAM";

It seems all the things placed in "L03SARAM" no longer fit.

Here are my latest errors:

#10010 errors encountered during linking; "XXXXXX.out" not built
#10099-D program will not fit into available memory, or the section contains a call site that requires a trampoline that can't be generated for this section. placement with alignment/blocking fails for section ".cinit" size 0x11bcpage 0.  Available memory ranges:
#10099-D program will not fit into available memory, or the section contains a call site that requires a trampoline that can't be generated for this section. placement with alignment/blocking fails for section ".econst" size 0x255dpage 0.  Available memory ranges:
#10099-D program will not fit into available memory, or the section contains a call site that requires a trampoline that can't be generated for this section. run placement with alignment/blocking fails for section "HMemData" size 0x386bpage 0.  Available memory ranges:
#16008-D file "../C28x_FPU_fastRTS/V100/lib/rts2800_fpu32_fast_supplement.lib<atan2_f32.obj>" specifies ISA revision "C28FPU32", which is not compatible with ISA revision "C2700" specified in a previous file or on the command line
#16008-D file "../C28x_FPU_fastRTS/V100/lib/rts2800_fpu32_fast_supplement.lib<cos_f32.obj>" specifies ISA revision "C28FPU32", which is not compatible with ISA revision "C2700" specified in a previous file or on the command line
#16008-D file "../C28x_FPU_fastRTS/V100/lib/rts2800_fpu32_fast_supplement.lib<FPUmathTables.obj>" specifies ISA revision "C28FPU32", which is not compatible with ISA revision "C2700" specified in a previous file or on the command line
#16008-D file "../C28x_FPU_fastRTS/V100/lib/rts2800_fpu32_fast_supplement.lib<sin_f32.obj>" specifies ISA revision "C28FPU32", which is not compatible with ISA revision "C2700" specified in a previous file or on the command line
#16008-D file "../C28x_FPU_fastRTS/V100/lib/rts2800_fpu32_fast_supplement.lib<sqrt_f32.obj>" specifies ISA revision "C28FPU32", which is not compatible with ISA revision "C2700" specified in a previous file or on the command line
...

Still no idea where references to C2700 could be coming from, the project has never used that family.

Those "ISA revision" errors usually indicate a mismatch between the --float_support compiler option in your project and the --float_support setting used to build the .lib in question. How is --float_support set in your project? Is it FPU32?

It looks like you need to edit your linker command file to find room for those sections. There's some guidance on editing linker files here if you need it. I'd also recommend using the Memory Allocation tool in CCS to visualize what memory you have available.

Whitney

Hello Whitney,

Thank you for getting back to so promptly on your return.

I'm glad you pointed me at the Memory Allocation view, that looks very useful, and I believe I can resolve the memory allocation issues now. 

As for the compatibility, everything I can find has been set to fpu32:

I have Runtime Support Library set to <automatic>

In XDCtools settings, Target is ti.targets.C28_float

The original author of the system tells me that he "used precompiled libraries for the C28. The libraries were included to speed up FPU functions." 

I am using those same library files, I believe.

Good eye! It seems that was the problem. I don't know why the build was grabbing that one, but after excluding that library from the build manually, it builds without errors!