F28069 interrupt vector copy fails after upgrade to CCS6.1

Dave,

Do you still have your CCSv5.2 installation? If so you could adjust your project in CCSv6.1 to use the compiler from CCSv5.2. If the program then works as expect then we know it is something with the compiler toolchain and we can pull in a compiler expert to take a look.

There is info on how to change the version of the compiler CCS is using here:
processors.wiki.ti.com/.../Projects_and_Build_Handbook_for_CCS

Regards,
John

Good idea - I did not keep my old CCS installation but I re-installed CCS 5.3.00090 (this was actually my old version, not 5.2 as stated previously), which includes compiler/tools v6.1.0.

I switched the compiler back to v6.1.0 from v6.4.2 (included in CCS 6.1.0.00104. The call to memcpy(&hwi_vec_runstart, &hwi_vec_loadstart, (Uint32)&hwi_vec_loadsize); ran fine under v6.1.0.

After switching back to v6.4.2, the same call sends the processor off into the weeds.

I did some more digging, looking at the location 0x3DC000 in the .map file. Both toolchains link the _hwi_vec_loadstart symbol into this location in flash, and there don't appear to be any other differences between the .map files.

Thanks,
Dave

Think I uncovered a big piece in the puzzle... The symbols were different in the map file between the two toolchains - under v6.1.0 the linker symbol is __memcpy_ff(), while under v6.4.2 it's memcpy. I looked at both in the disassembler:

For v6.1.0:

        __memcpy_ff():
3e74aa:   FF5A        MOVL         P, ACC
3e74ab:   92AB        MOV          AL, @PL
3e74ac:   C5A4        MOVL         XAR7, @XAR4
3e74ad:   8EA4        MOVL         XAR0, @XAR4
3e74ae:   EC07        SBF          7, EQ
3e74af:   9CFF        ADDB         AL, #-1
3e74b0:   88A9        MOVZ         AR6, @AL
3e74b1:   9285        MOV          AL, *XAR5++
3e74b2:   9687        MOV          *XAR7++, AL
3e74b3:   000EFFFE    BANZ         -2,AR6--
3e74b5:   92AB        MOV          AL, @PL
3e74b6:   88A9        MOVZ         AR6, @AL
3e74b7:   A9A9        MOVL         @ACC, P
3e74b8:   0FA6        CMPL         ACC, @XAR6
3e74b9:   EC10        SBF          16, EQ
3e74ba:   93AA        MOV          AH, @PH
3e74bb:   EC0E        SBF          14, EQ
3e74bc:   A9A9        MOVL         @ACC, P
3e74bd:   9DFF        ADDB         AH, #-1
3e74be:   5CA8        MOVZ         AR4, @AH
3e74bf:   76BFFFFE    MOVL         XAR6, #0x3ffffe
3e74c1:   9285        MOV          AL, *XAR5++
3e74c2:   9687        MOV          *XAR7++, AL
3e74c3:   000EFFFE    BANZ         -2,AR6--
3e74c5:   9285        MOV          AL, *XAR5++
3e74c6:   9687        MOV          *XAR7++, AL
3e74c7:   000CFFF8    BANZ         -8,AR4--
3e74c9:   8AA0        MOVL         XAR4, @XAR0
3e74ca:   0006        LRETR        

For v6.4.2:

        memcpy():
3e7347:   767E7347    LCR          memcpy
3e7349:   0006        LRETR        

It appears that v6.4.2 is linking in a stub??

Investigation continues...

Thanks,

Dave

I did some additional digging in the linker's .map output file. The memcpy function is being linked, in both cases, from rts2800_fpu32.lib. The src/ directory for the library appears to include a non-stub memcpy implementation, but I'm unable to build the library itself using the mklib.exe utility.

Is there a project / linker setting that needs to be changed in order to avoid linking in a stub for memcpy under the v6.4.2 compiler?

Thanks,
Dave

Hi David - I'll ask one of the compiler team members to take a look.

David R. said:

Is there a project / linker setting that needs to be changed in order to avoid linking in a stub for memcpy under the v6.4.2 compiler?

Yes.  You are building with a 6.4.x compiler but linking against a library from a older version of the compiler.  The compiler and the library must come from the same compiler installation.  You cannot mix them.  I'm not sure how this happened.  In most CCS projects the build variable ${CG_TOOL_ROOT} is used everywhere so that this problem cannot occur.  Your project must do something different.  I wonder what that is, and why.

Thanks and regards,

-George

George, thank you for taking a look... Here is a screenshot of my linker settings page for libraries and paths. The runtime libraries appear to be linked relative to ${CG_TOOL_ROOT}.

Here is the linker output from the console (which seems to indicate that ${CG_TOOL_ROOT} points to the correct toolchain and is being correctly expanded):

'Invoking: C2000 Linker'
"C:/ti/ccsv6/tools/compiler/ti-cgt-c2000_6.4.2/bin/cl2000" -v28 -ml -mt --cla_support=cla0 --float_support=fpu32 --vcu_support=vcu0 --advice:performance=all -g --define=IOP_FCM --diag_warning=225 --display_error_number --diag_wrap=off -z -m"FCAPU-IOP-CCSv6.map" --stack_size=0x300 --warn_sections -i"C:/ti/ccsv6/tools/compiler/ti-cgt-c2000_6.4.2/lib" -i"C:/ti/ccsv6/tools/compiler/ti-cgt-c2000_6.4.2/include" -i"C:/ti/bios_5_42_00_07/packages/ti/rtdx/lib/c2000" -i"C:/ti/bios_5_42_00_07/packages/ti/bios/lib" --reread_libs --display_error_number --diag_wrap=off --xml_link_info="FCAPU-IOP-CCSv6_linkInfo.xml" --rom_model -o "iop-ccsv6.out" {{long-list-of-object-files here}} "../2806x_BootROM_API_TABLE_Symbols_fpu32.lib" "../F2806x_Headers_BIOS.cmd" "../rts2800_fpu32.lib" -l"./mainIOPcfg.cmd"  -l"rts2800_fpu32.lib" 

I thought it might be possible that a memcpy stub was being linked in from the DSP/BIOS libraries somewhere, but (given the .map file's indication that the _memcpy function is coming from rts2800_fpu32.lib, I don't think this is the case:

003e4e92    00000003     rts2800_fpu32.lib : memcpy.obj (.text)

If you DM me your TI e-mail address, I can zip up and send the project. Can't post it publicly though.

Thanks,
Dave

George - Thank you - it looks like this solved the issue - the v6.1.0 linker must have been more tolerant of having this file present in the source tree.

Cheers,
Dave