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.

CCS/LAUNCHXL-F28027: Example_F2802xLaunchPadDemo does not boot from Flash standalone, but works in EMU mode

Part Number: LAUNCHXL-F28027
Other Parts Discussed in Thread: C2000WARE,

Tool/software: Code Composer Studio

HI.  I am a beginner in C2000 microcontrollers.  My only previous experience is with Arduino and Arduino-compatible microcontrollers.  So, please explain like I'm five!

I can connect to the Launchpad, compile the demo program Example_F2802xLaunchPadDemo (the "demo"), download it to the board, run and debug it.  It all works fine as long as it's plugged in.  If I power cycle the board or press the reset button, it doesn't boot.  It requires the program to be downloaded into Flash again, either with the downloader or the debugger in CSS.

By comparison, the Example_F2802xLEDBlink (the "blinker") from the same version of C2000Ware does boot correctly from Flash.  So I know that everything is basically working in terms of the hardware and communication.  I can compile, build, link, download, debug, and boot from Flash.  There must be an incorrect setting or error that is specific to the demo project

Here is the vintage of the hardware and software I am using.  The board was recently purchased from the TI store, and CCS and C2000Ware were downloaded last week. 

  • LAUNCHXL-F28027:  Lot: 03262017I2; Week: 19/2017
  • CCS: Version 9.0.1.00004
  • C2000Ware - v:1.00.06.00

The example code is from C2000Ware/English/Devices/F2802x/F28027/Examples/Driverlib/C2kLaunchPadDemo

Some settings:

  • The Active (and only) Build Configuration is Flash
  • The C2000 compiler has the define=_FLASH flag
  • The C2000 linger has the --define=_FLASH and --define=LARGE_MODEL flags set
  • I have the S1 switch set to 111 when connected to the PC and to 110 when trying to boot standalone.
  • All settings and code are exactly as loaded from C2000Ware - I have not modified the demo.

Linker flags:
-v28 -ml -mt -O0 -g --define=_FLASH --define=NDEBUG --define=_DEBUG --define=LARGE_MODEL --quiet --verbose_diagnostics --diag_warning=225 --diag_suppress=552 --gen_func_subsections=on -z --stack_size=0x300 -m"Example_F2802xLaunchPad_demo.map" --heap_size=0x200 --warn_sections -i"C:/TI/ccs901/ccs/tools/compiler/ti-cgt-c2000_18.12.1.LTS/lib" -i"C:/TI/ccs901/ccs/tools/compiler/ti-cgt-c2000_18.12.1.LTS/include" -i"C:/Users/Jeremy/Documents/workspace_v9/Example_F2802xLaunchPadDemo" -i"C:/TI/C2000Ware_1_00_06_00_Software/device_support/f2802x/common/lib" -i"C:/TI/C2000Ware_1_00_06_00_Software/libraries/math/IQmath/c28/lib" --reread_libs --verbose_diagnostics --issue_remarks --entry_point=_c_int00 --rom_model

Compiler flags:
-v28 -ml -mt -O0 -g --include_path="C:/TI/ccs901/ccs/tools/compiler/ti-cgt-c2000_18.12.1.LTS/include" --include_path="C:/TI/C2000Ware_1_00_06_00_Software/device_support/f2802x/common/include" --include_path="C:/TI/C2000Ware_1_00_06_00_Software/device_support/f2802x/headers/include" --define=_FLASH --define=NDEBUG --define=_DEBUG --define=LARGE_MODEL --quiet --verbose_diagnostics --diag_warning=225 --diag_suppress=552 --gen_func_subsections=on

Update:

The demo will boot from Flash with linker flag  --entry_point=_c_int00 changed to --entry_point=code_start

Since I started writing this note, I found a solution to the problem.  I changed the linker flag from --entry_point=_c_int00 to --entry_point=code_start, because I noticed that is what the blinker demo used, and it boots from Flash successfully.  This produces a build warning:  "warning: entry-point symbol other than "_c_int00" specified:  "code_start"".  However, when this change is made, the board will boot from Flash upon powerup.  It will also boot from Flash if RST button is pressed as long as S1 is set to 110.  

This is what the linkInfo.xml file for the original demo says:

   <entry_point>
      <name>_c_int00</name>
      <address>0x3f2d46</address>
   </entry_point>

This is what the llinkInfo.xml for the modified demo says:

   <entry_point>
      <name>code_start</name>
      <address>0x3f7ff6</address>

From the Boot ROM documentation, 0x3f7ff6 is the correct entry point.

Questions:

  • I thought _c_int00 defined the entry point.  Why does the working blinker demo use --entry_point=code_start?
  • Where is the value for _c_int00 defined, and why is it wrong?
  • Where is the value for code_start defined?  
  • Why does the linker give a warning for --entry_point=code_start?
  • Why doesn't the demo program shipping with the launch pad work correctly?  It will be quick, they said!  It will be easy, they said!  And days later here I am, surrounded by a stack of TI Reference Guides and Application Notes, having read through dozens of E2E threads, single stepping through the boot ROM in the disassembly window, wondering why my "simple and complete" eval kit won't boot its demo program correctly.

Thanks,

Ciaran

  • Ciaran,

    The name 'codestart' is a user defined section located in CodeStartBranch.asm and it is used to redirect code execution for booting to flash or RAM. The 'codestart' section is located in the linker command file links the code in CodeStartBranch.asm to the entry point. The warning you are receiving is because the entry name does not match the setting in the CCS project properties under C2000 Linker -> Advanced Options -> Symbol Management. Delete this entry since it is already taken care of with the linker (and the warning should not appear).

    To learn more about the F2802x please see the following workshop:

    processors.wiki.ti.com/.../C2000_Archived_Workshops

    Please not that this workshop uses the discontinued F28027 controlSTICK, however the lab directions can easily be modified to use the LaunchPad. The source code will work as is.

    For more details, please see the F2803x workshop at:

    processors.wiki.ti.com/.../C2000_Archived_Workshops

    Please not that you will nee to modify the linker command file memory usage from this workshop to use the F2802x. Also, the CLA is not available on the F2802x devices.

    I will forward your comments about the demo code to the appropriate team.

    I hope this helps. If this answers your question, please click the green "Verified Answer" button. Thanks.

    - Ken
  • Ken,

    Thanks for the reply.

    >> Delete this entry since it is already taken care of with the linker (and the warning should not appear).

    This doesn't work, but I may not have interpreted it correctly. I interpret this to mean delete the CCS project properties under C2000 Linker -> Advanced Options -> Symbol Management -> specify program entry point. If I delete "code_start" in this field and leave it blank, the board resumes its original behavior of not booting from Flash.

    The problem seems to be that the _c_int00 function is returning the wrong address. The debugger says that _c_int00 = 0x3f2d46. This is the **wrong address**! The entry point should be 0x3f7ff6. The code_start gives the correct address: code_start = 0x3f7ff6.

    --------------------------------------------------------------------------------------------------------------------------------------------------
    To summarize so far:
    * _c_init00 returns the wrong entry point address (0x3f2d46)
    * code_start returns the correct entry point address (0x3f7ff6)
    * I need to specify code_start as the entry point in the Symbol Management page of the properties to boot from Flash.
    --------------------------------------------------------------------------------------------------------------------------------------------------

    Thanks for the explanation of how code_start and _c_int00 are used. These seem to be the relevant files in my case:

    C:\TI\C2000Ware_1_00_06_00_Software\device_support\f2802x\common\cmd\F28027.cmd
    C:\TI\C2000Ware_1_00_06_00_Software\device_support\f2802x\common\source\f2802x_codestartbranch.asm
    C:\TI\ccs901\ccs\tools\compiler\ti-cgt-c2000_18.12.1.LTS\lib\src\boot28.asm

    I can follow generally how these work but not well enough to see what's wrong.

    So I'm left with the question: why is _c_int00 returning the wrong entry point for Flash booting?
  • I think I found the explanation. Please confirm if this is correct.

    Reading the header in C:\TI\C2000Ware_1_00_06_00_Software\libraries\math\IQmath\c28\examples\C\source\CodeStartBranch.asm
    (This file isn't in my includes, but the header provides some insight into what's going on.)

    ;// FILE: CodeStartBranch.asm
    ;//
    ;// TITLE: Branch for redirecting code execution after boot.
    ;//
    ;// For these examples, code_start is the first code that is executed after
    ;// exiting the boot ROM code.
    ;//
    ;// The codestart section in the linker cmd file is used to physically place
    ;// this code at the correct memory location. This section should be placed
    ;// at the location the BOOT ROM will re-direct the code to.
    ;//
    ;// In addition, the example projects are setup such that the codegen
    ;// entry point is also set to the code_start label. This is done by linker
    ;// option -e in the project build options. When the debugger loads the code,
    ;// it will automatically set the PC to the "entry point" address indicated by
    ;// the -e linker option. In this case the debugger is simply assigning the PC,
    ;// it is not the same as a full reset of the device.
    ;//
    ;// The compiler may warn that the entry point for the project is other then
    ;// _c_init00. _c_init00 is the C environment setup and is run before
    ;// main() is entered. The code_start code will re-direct the execution
    ;// to _c_init00 and thus there is no worry and this warning can be ignored.

    Of specific interest:
    > When the debugger loads the code, it will automatically set the PC to the "entry point" address indicated by the -e linker option.

    I think the "-e linker option" is the same as --entry_point. This suggests that setting --entry_point=code_start is correct, and that the original setting in the demo of --entry_point=_c_int00 is incorrect.

    > The compiler may warn that the entry point for the project is other then _c_init00. _c_init00 is the C environment setup and is run before main() is entered. The code_start code will re-direct the execution to _c_init00 and thus there is no worry and this warning can be ignored.

    So no worries! Change --entry_point=_c_int00 to --entry_point=code_start, ignore the warning, and get on with the project.
  • Ciaran,

    Yes, that is correct. I cover these details in the F2803x workshop (see the workshop manual .pdf file). In the lab 5 exercise the CodeStartBranch.asm is linked to M0 SARAM (see step 6), and in lab 10 it is linked to Flash (see steps 14 and 15). In this section (lab 10) you might be interested in paragraphs before and after steps 14 and 15. Likewise for booting from RAM, see step 11 in lab 5.

    Also, I want to let you know that a bug has been filed for the demo code and it will be fixed in the next release.

    - Ken
  • Ken,

    Thanks. The workshop file looks helpful.

    - Ciaran