TMS320F28335-Q1: Firmware does not work after flashing to device

Weiliang,

If you find the function SmartBit_2833xSci_int_1(), then it should have a #pragma like this above it: to assign it to the section >TI.ramfunc

#ifdef __cplusplus
#pragma CODE_SECTION(".TI.ramfunc");
#else
#pragma CODE_SECTION(SmartBit_2833x..., ".TI.ramfunc");
#endif

Since you are also showing a "retain" section as well, I think you may find an additional #pragma retain in your code; this is needed in case of conditional linking, but I doubt you have that in your .cmd file.  I would try to remove this extra pragma, and see if this cleans things up.

Best,

Matthew

Hi Matthew,

Thanks for your reply and helping me to understand this problem. But in my code I did not have the #pragma as you pointed out, and neither my code nor linker file has the #pragma to define the retain section as well. All I did was that I turned on the option of --ramfunc in my CCS project property C2000 Compiler->Advanced Options->Runtime Model Options. Look like the retain section was added by the compiler automatically in compilation. In this case, how can I get rid of this retain section?

Best Regards,

Weiliang 

Weilang,

I need to check with our compiler team how the "runtime model option" can/should be used.  I am only familiar with manual pragma insertion for code section/data sections that need to be loaded to flash and ran from RAM. 

In the meantime, please take a look at this example in C2000Ware(C:\ti\c2000\C2000Ware_5_04_00_00\device_support\f2833x\examples\flash_f28335), that has the correct .cmd and #pragma, and memcopy functions inserted manually.  Since flash size is >> that RAM size, applications will typically only copy/run the most time critical functions from RAM.

Best,

Matthew

Weiliang Xu said:

All I did was that I turned on the option of --ramfunc in my CCS project property C2000 Compiler->Advanced Options->Runtime Model Options.

That is the same as putting every function in the program in the section .TI.ramfunc.  I can't think of any good reason to do that.  I'm surprised the link worked.

Thanks and regards,

-George

George,

Thanks for replying. The linker does work in this case, but the standalone firmware does not work, though. My understanding is that the linker just uses this option to configure the load and run addresses in flash and RAM. If I do not have the memory copy function in main, when the runtime support routine transfers its control to main at RAM, there is nothing over there to take the control.

Best Regards,

Weiliang

With regard to the option --ramfunc you said ...

Weiliang Xu said:

 My understanding is that the linker just uses this option to configure the load and run addresses in flash and RAM.

That's incorrect.  The --ramfunc option, applied at the level of a CCS project, causes every function to be in the section .TI.ramfunc.  For more detail, search for --ramfunc in the C28x compiler manual.  Arranging for .TI.ramfunc to have separate load and run addresses happens in the linker command file.  For an example, please search the article Linker Command File Primer for the sub-part titled Load at One Address, Run from a Different Address.  Most (or all?) of the linker command files supplied with C2000Ware configure .TI.ramfunc with similar code.

Weiliang Xu said:

If I do not have the memory copy function in main, when the runtime support routine transfers its control to main at RAM, there is nothing over there to take the control.

This is yet another reason to not apply --ramfunc to the entire project.  System startup code, along with the code that copies from flash to RAM, cannot itself be in .TI.ramfunc.

Thanks and regards,

-George