TMS320F28377S: Upgrade project based on controlSUITE to CCSv10

What did you do to migrate it? Did you make many changes to the code? Update the compiler version?

Is it going straight to the ESTOP as soon as it loads or are you able to get it to go to main() first? If you do a Reset and a Restart, can you get it to go to main()?

Whitney

I didn't change code and upgraded to latest version. (ccs v10.2.0.00009)

It is going straight to the ESTOP as soon as it loads.

What happens when you do a Reset and a Restart? If you go to Tools -> Debugger Options -> Auto Run and Launch Options, is it configured to run to main on a program load or restart?

Since you're getting an ITRAP, can you confirm using the memory browser or disassembly window that your code has actually been loaded?

Do other applications (like C2000Ware examples) load and run okay on this hardware? Is it just this application that is having this trouble?

Whitney

Hello.

Regarding this issue, I've followed up on it. 

First, if the TI's example code loaded at the same hardware, it runs OK.

We are moving to the latest CCS to use a new motor library from CCSV6(compiler 5.12) to 20.12...

The main problem is not starting from the main() entry point when the code begins.

If I set the breakpoint in the entry of main(), it never reaches this point and any other breakpoints in the code.

After this, it enables me to hang the breakpoint if I stop and re-run the code. At this time, I can handle the code and measured something such as LED toggle, and look at the system running properly.

The question is why the code is not running from the main entry and some abnormal behavior.

Is this relevant to the cmd file to make memory and section? we modified and remade the cmd files.

Thanks a lot.

Do you get any errors when you place the breakpoints? If you check the Breakpoints panel in CCS does it show the breakpoints are active?

It's possible the changes to the cmd files could be the cause. When you switched compiler versions did you also change from COFF ABI to EABI or is it still COFF?

In your CodeStartBranch.asm file (or equivalent) can you try disabling the watchdog?

Whitney

Hi.

I checked the compiler option and found the "Legacy COFF". I changed it to the EABI, however, compiler errors occurred. Refer to the below console message. I changed the EABI setting to another example project(blinky_cpu01) and errors occurred as well. Thanks a lot.

==============================================================

building target: "INVERTER.out"
Invoking: C2000 Linker
"C:/ti/ccs1030/ccs/tools/compiler/ti-cgt-c2000_20.2.4.LTS/bin/cl2000" -v28 -ml -mt --cla_support=cla1 --float_support=fpu32 --tmu_support=tmu0 --vcu_support=vcu2 -O1 --opt_for_speed=3 --fp_mode=strict --fp_reassoc=on --advice:performance=all --define=CPU1 --define=_FLASH -g --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi --check_misra="8.1,16.3,16.5" -z -m"INVERTER.map" --stack_size=0x300 --warn_sections -i"C:/ti/ccs1030/ccs/tools/compiler/ti-cgt-c2000_20.2.4.LTS/lib" -i"C:/Users/seungwook.ahn/workspace_v10/INVERTER/lib" -i"C:/ti/ccs1030/ccs/tools/compiler/ti-cgt-c2000_20.2.4.LTS/include" --reread_libs --diag_wrap=off --display_error_number --no_warnings --xml_link_info="INVERTER_linkInfo.xml" --rom_model -o "INVERTER.out" "./src/AbsoluteEncoder.obj" "./src/Accelerometer.obj" "./src/Adc.obj" "./src/Brake.obj" "./src/CRC32.obj" "./src/DRA_ecat.obj" "./src/DSP28xxx_SectionCopy_nonBIOS.obj" "./src/DigitalInput.obj" "./src/Digital_Pll.obj" "./src/F2837xS_Adc.obj" "./src/F2837xS_CodeStartBranch.obj" "./src/F2837xS_CpuTimers.obj" "./src/F2837xS_DefaultISR.obj" "./src/F2837xS_Dma.obj" "./src/F2837xS_EPwm.obj" "./src/F2837xS_EQep.obj" "./src/F2837xS_Emif.obj" "./src/F2837xS_GlobalVariableDefs.obj" "./src/F2837xS_Gpio.obj" "./src/F2837xS_I2C.obj" "./src/F2837xS_Mcbsp.obj" "./src/F2837xS_PieCtrl.obj" "./src/F2837xS_PieVect.obj" "./src/F2837xS_Sci.obj" "./src/F2837xS_Spi.obj" "./src/F2837xS_SysCtrl.obj" "./src/F2837xS_TempSensorConv.obj" "./src/F2837xS_usDelay.obj" "./src/FTSensor.obj" "./src/Flash.obj" "./src/HallSensor.obj" "./src/Homing.obj" "./src/IndexCheck.obj" "./src/Inverter.obj" "./src/JointTorqueSensor.obj" "./src/LSPBTrajectory.obj" "./src/ModuleData.obj" "./src/MotorOffset.obj" "./src/ParameterTables.obj" "./src/Parameters.obj" "./src/RingBuff.obj" "./src/SpeedObserver.obj" "./src/Variable.obj" "./src/can.obj" "./src/can_open_object_dictionary.obj" "./src/cc.obj" "./src/dac.obj" "./src/easy2833x_sci_FIFO_v8.6.obj" "./src/eeprom.obj" "./src/esc.obj" "./src/esc_sdo.obj" "./src/fault.obj" "./src/filter.obj" "./src/flange.obj" "./src/interrupt.obj" "./src/main.obj" "./src/os_100m.obj" "./src/sc.obj" "../lib/F021_API_F2837xS_FPU32.lib" "../src/F2837xS_Headers_nonBIOS.cmd" "../src/flash_programming_cpu1_FLASH.cmd" -l"C:/ti/ccs1030/ccs/tools/compiler/ti-cgt-c2000_20.2.4.LTS/lib/rts2800_fpu32.lib" -llibc.a
<Linking>
fatal error #16000: object files have incompatible formats ("C:/ti/ccs1030/ccs/tools/compiler/ti-cgt-c2000_20.2.4.LTS/lib/rts2800_fpu32.lib<boot28.asm.obj>" = TI-COFF, "./src/AbsoluteEncoder.obj" = ELF)

>> Compilation failure
makefile:203: recipe for target 'INVERTER.out' failed
gmake[1]: *** [INVERTER.out] Error 1
gmake[1]: Target 'secondary-outputs' not remade because of errors.
makefile:199: recipe for target 'all' failed
gmake: *** [all] Error 2

**** Build Finished ****

That's okay--stick with COFF for now. I think it's better not to introduce another difference between the working project and this failing one until we find the issue. If you want to migrate later, there's a good guide here.

Can you try comparing the .map files between the old working application and the new one to see if there were any significant differences that could explain the issue?

See if Ki's suggestion in this thread helps at all:

e2e.ti.com/.../3256068

Whitney

Hi.

I checked the .cmd file and found something weird. Please refer to the below script.

...

RAMGS2          : origin = 0x00E000, length = 0x001000

...

Flash28_API:
{
-l F021_API_F2837xS_FPU32.lib(.econst)
-l F021_API_F2837xS_FPU32.lib(.text)
} LOAD = FLASHL,
RUN = RAMGS2, // the memory location ?? -- @
LOAD_START(_Flash28_API_LoadStart),
LOAD_END(_Flash28_API_LoadEnd),
RUN_START(_Flash28_API_RunStart),
PAGE = 0, ALIGN(4)

ramfuncs : LOAD = FLASHF, // ramfuncs
RUN = RAMGS2, // the memory location ?? -- @
LOAD_START(_RamfuncsLoadStart),
LOAD_SIZE(_RamfuncsLoadSize),
LOAD_END(_RamfuncsLoadEnd),
RUN_START(_RamfuncsRunStart),
RUN_SIZE(_RamfuncsRunSize),
RUN_END(_RamfuncsRunEnd),
PAGE = 0, ALIGN(4)

...

The ramfuncs running location is the same as the FLASH28_API location as RAMGS2.

I checked the map file.

...

ramfuncs 0 00090000 00000090 RUN ADDR = 0000e7b8
                   00090000 00000090 F2837xS_SysCtrl.obj (ramfuncs)

...

If you see the RUN ADDR, it doesn't start from 0000e000.

The size of "7b8" is the same as the FLASH28_API section size.

The map file shows 

...

Flash28_API
* 0 000ba000 000007b5 RUN ADDR = 0000e000

...

I guess this duplicated memory location could make an abnormal loading problem. I'll research more.

Thanks.

This seems okay to me. I don't see any reason why there would be a problem with both of those sections executing out of the same RAM.

How is the application supposed to be getting from the flash entry point to _c_int00? Are you using the F2837xS_CodeStartBranch.asm file from C2000Ware or some custom code?

Whitney

Hi. Thanks for your reply.

With regarding .asm files, we modified the codestart section as below.

==============<F2837xS_CodeStartBranch.asm>===============================

WD_DISABLE .set 1 ;set to 1 to disable WD, else set to 0

.ref copy_sections
.global code_start

.sect "codestart"

code_start:
.if WD_DISABLE == 1
LB wd_disable 
.else
LB copy_sections 
.endif

.if WD_DISABLE == 1

.sect "wddisable"
wd_disable:
SETC OBJMODE 
EALLOW 
MOVZ DP, #7029h>>6 
MOV @7029h, #0068h 
EDIS
LB copy_sections

.endif

.end

========<DSP28xxx_SectionCopy_nonBIOS.asm>===============

.ref _c_int00
.global copy_sections
.global _cinit_loadstart, _cinit_runstart, _cinit_size
.global _const_loadstart, _const_runstart, _const_size
.global _econst_loadstart, _econst_runstart, _econst_size
.global _pinit_loadstart, _pinit_runstart, _pinit_size
.global _switch_loadstart, _switch_runstart, _switch_size
.global _text_loadstart, _text_runstart, _text_size

.sect "copysections"

copy_sections:

MOVL XAR5,#_const_size 
MOVL ACC,@XAR5 
MOVL XAR6,#_const_loadstart 
MOVL XAR7,#_const_runstart 
LCR copy 

MOVL XAR5,#_econst_size 
MOVL ACC,@XAR5 
MOVL XAR6,#_econst_loadstart 
MOVL XAR7,#_econst_runstart 
LCR copy 

MOVL XAR5,#_pinit_size 
MOVL ACC,@XAR5 
MOVL XAR6,#_pinit_loadstart 
MOVL XAR7,#_pinit_runstart 
LCR copy 

MOVL XAR5,#_switch_size 
MOVL ACC,@XAR5 
MOVL XAR6,#_switch_loadstart 
MOVL XAR7,#_switch_runstart 
LCR copy 

MOVL XAR5,#_text_size
MOVL ACC,@XAR5 
MOVL XAR6,#_text_loadstart 
MOVL XAR7,#_text_runstart
LCR copy 

MOVL XAR5,#_cinit_size
MOVL ACC,@XAR5 
MOVL XAR6,#_cinit_loadstart 
MOVL XAR7,#_cinit_runstart 
LCR copy 

LB _c_int00 

copy:
B return,EQ 

RPT AL 
|| PWRITE *XAR7, *XAR6++ 

return:
LRETR 

.end

===================================================================

It seems to be no problem, in my opinion. The previous memory section address collision was not a problem.

I changed and arranged some memory sections, but the result was the same. 

I tested this working project in the CCSV6 that is an old version compiler(15.12...). After the XDS110 JTAG update, the same problem occurred with the main entry issue. So I think this is not a tool-related problem.

I noticed two times the code start from the main entry while trying to debug with some compiler options. However, it never appeared again. I did not regenerate the phenomenon again even if I set the compiler option the same.

Well... I will try to start the project from scratch step by step with our own source. It takes more time. But this is a significant issue to migrate it.

Thanks a lot.

Okay, hopefully migrating step-by-step will narrow down which part of the code is introducing the issue. Let me know if you need further help.

Whitney