• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Answers 1 answer
  • Subscribers 87 subscribers
  • Views 10524 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

How to boot from Flash after Reset, C2000 LaunchPad, F28027

Juan Gomez
Intellectual 335 points
Other Parts Discussed in Thread: CONTROLSUITE, TMS320F28027

Hello,

This is the situation, I'm able to compile and debug successfully my code but  when I perform a CPU Reset  I can't  boot again " the program jumps to a different address where main address is located".  I Know this has to be regarding with the Linker file ".cmd"  I try different ".cmd file" still doing the same. So, now I know that I have to modify my ".cmd".

Can someone help me to boot from flash?
Note:
CCSv5.3
C2000 LaunchPad  - C28027

Here Are some Pics of my project configuration:

Linker search path:

 

Is this important? how do I modify  OPT KEY & OTP BMODE?

Finally, what for these 2 code lines?

memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, &RamfuncsLoadEnd - &RamfuncsLoadStart);

InitFlash();

Thanks in advance.
Regards.
Juan. 

 

  • 0
    TI__Mastermind 22025 points

    Juan,

    Your project looks like it is setup correct for a flash boot.  All you should need to do is use one of the flash linker command files (which you are).

    OTP_KEY and OTP_BMODE can be programmed when you program your application in.  I would recommend you leave these two locations alone as they can only be programmed once.  Instead simply set the 3rd dip switch (the right most switch) to the down position (the other two should be up).  This will cause the device to boot to flash.  Keep in mind that while this third switch is down the debugger will not connect to the device.

    memcpy copies functions from flash into RAM.  This requires that these functions be linked to run from RAM and you'll see how this is done in the linker command file.  This allows these functions to execute from 0 wait state RAM which is much quicker than flash.

    InitFlash sets up the flash wait states and improves processor performance.  By default flash wait states are set to the maximum to ensure the chip always boots and can read it's flash memory.

    Are you calling memcpy and InitFlash in your application when you are trying to boot standalone?

    Trey

  • 0
    TI__Mastermind 19810 points

    Juan,

    with emulator connected, you can use EMUBOOT MODE, by programming EMUKEY and EMUBMODE values properly and see if the device boots to flash.if not you will have a porblem in stand-alone boot as well. Don't program OTPKEY or OTPBMODE yet, because OTP is One Time Programmable only.

    which device is this question for? the memcpy function copies the functions that needs to be run from RAM to RAM from flash. The InitFlash - initializes flash for waitstates etc.

    Best Regards

    santosh

     

  • 0
    Prodigy 185 points

    Dear Juan,

    Can you tell me the procedures you followed to program your code in FLASH memory.

    I am also facing a problem with a linker command file.

  • 0 in reply to mohamed azim
    Guru 192875 points

    Hi Mohamed,

    You can go through this file:

    4137.3301.TI_Running_from_Flash_spra958l.pdf

    Regards,

    Gautam

  • 0 in reply to Gautam Iyer
    Prodigy 185 points

     Hi Gautam,

    I have read that FLASH Pdf before .

    I am facing a linker problem at the moment, which i am not able to figure out from the PDF.

    I have attached my project file here. I have imported settings from the example file. You can download and directly import my project into CCS 5.5. Please analyze and give your feedback

    4617.azimimport2.rar

    Regards,

    Azim

     

     

     

     

     

     

     

  • 0 in reply to mohamed azim
    Guru 192875 points

    Hi Azim,

    I've attached the zip file with your working program in flash. Enjoy :)

    6661.azimimport2.zip

    Regards,

    Gautam

  • 0 in reply to Gautam Iyer
    Prodigy 185 points

    Dear Gautam,

    Have you replaced the example's source file with mine....???

    Are you using an older version of CCS .....I'm not able to access the linker files........???? 

    I'm able to dump the example files in FLASH but not my own project file.

    Could you please tell me the changes you have done in the linker files.

    Regards,

    Azim

     

     

     

     

     

     

     

  • 0 in reply to mohamed azim
    Guru 192875 points

    Hi Azim,

    Use the linker file of  "flash_f28027" project and add it to your project.

    Regards,

    Gautam

  • 0 in reply to Gautam Iyer
    Prodigy 185 points

    Hi Guys,

    Finally i have managed to crack the FLASH Settings

    There is no requirement for any importing of settings from the Example Files.

    Just follow the steps in the below document

    7737.Flash Accesses Settings for C2000 in CCS5.doc

    Regards, 

    Azim

     

     

     

     

     

  • 0 in reply to mohamed azim
    Guru 192875 points

    Good Good... :)

  • 0 in reply to Trey German289
    Intellectual 630 points
    you mentioned dip switch in your post. What is a dip switch and where is it located ?
  • 0 in reply to Amit Aryal
    TI__Mastermind 19810 points
    ca you check your project configurations and see if you are building a flash based COFF file? the DIP switches are the boot mode switches on the launch pad, please refer to the launch pad documentation/schematics. You don't have to program OTP to get to boot to flash., when there is NO OTP KEY programmed in flash and when boot mode pins are set to HIGH the device boots to flash.


    hope this helps.

    Best Regards
    Santosh Athuru
  • 0 in reply to Santosh Athuru
    Genius 4995 points

    Is anybody watching  this thread anymore?  I have the same problem, and just "copy this" doesn't explain what is going on.

    Honestly, nothing is documented to solve this issue, and I have spent 5 days trying to reverse engineer what is going on.  NONE of it makes sense...

    Steps to reproduce:

    1. Take a brand new LauchXL board, plug it in.  It runs the internal demo program. (the demo is in flash, obviously)
    2. Load the "Experimenters kit TASK 28" from control suite (no, I'm not uploading my project files, they are in control suite, which everyone has access to)
    3. Build and load the program, watch it run.
    4. Stop the debug task, unplug the board.
    5. Plug the board back in, it's dead. NO CODE IS RUNNING.
    6. Obtain the original demo code "Example F2802xLaunchPadDemo" and rebuild it, and reload it. Watch it run.
    7. Unplug the board, just like the above step 5. Plug it back in, and the demo program runs.

    WHY DOES THE DEMO PROGRAM PERSIST, BUT THE SAMPLE "TASK 28" DOESN'T?  The map file of "Experimenters kit TASK 28" shows that every function is stored in flash.  I see why... the entry point is pointing to the wrong place...  but wait.

    I see that the  "Example F2802xLaunchPadDemo" gives a build warning:

         entry-point symbol other than "_c_int00" specified:  "code_start"

    I DARE anyone to find where "code_start" is specified anywhere in the project!  But the build process is complaining about it!!  And the map file shows that this address is correctly set to 0x003f7ff6   (the boot rom final target)... I have no idea where is came from, how it got set there, what setting in what file told it to do that...

    On the other hand, the "Experimenters kit TASK 28" project imported and unchanged from the control Suite shows that the entry point "_c_int00"  is set to address: 0x003f14fe .   Where did it pull that from???  There is no place to specify that anywhere I can find in the settings, in the documentation, in anything!

    So, if  "code_start" isn't specified anywhere in the "Demo", how can I imagine to try to copy the setting to the "Task 28" project , and change the name to "_c_int00" ??

    Why doesn't the "Task 28" project properly set this out of the box?

    Why does the "Task 28" project even work if it's NOT setting the entry point to the BOOT ROM target of 0x003f7ff6 ?  How can that even happen?

    The Piccolo Boot Rom guide (sprufn6a) explains the boot ROM flow.  But not this issue.  The Assembly and Linker tools document (spru513L) has a bunch of  directives to put in the "cmd" file, but I can't get any of it to make sense.  It doesn't match what I'm seeing in the example projects.

    I am using CCS 6.2, and the newest of everything.  Installed less than 2 weeks ago, and I've gotten to spend those two weeks trying to figure out why this doesn't work.

    Getting more frustrated day by day...  I've been coding Micro Chip PIC devices for 18 years.  I know the concepts.  However, I can't seem to figure out this world.

    -CSW

  • 0 in reply to Christopher Weber
    TI__Mastermind 19810 points

    CSW,

    for a program to run stand-alone, you will have to program it into flash. You have this working with the  "Example F2802xLaunchPadDemo" .

    I couldn't find the "Experimenters kit TASK 28" in controlSuite, can you provide the path?

    Christopher Weber said:

    I see that the  "Example F2802xLaunchPadDemo" gives a build warning:

         entry-point symbol other than "_c_int00" specified:  "code_start"

    The tools assume the default entry point to be _c_int00 from the runtime C library. Function code_start can be found in the C:\ti\controlSUITE\development_kits\C2000_LaunchPad\f2802x_common\source\F2802x_asmfuncs.asm, it is being linked from the driverlib.lib, if you import the driverlib project you will be able to see this.

    entry point information is a link time input to the linker and is configured in the project properties (right click on project name on CCS)->C2000linker->Symbol Management. If user doesn't provide an entry point symbol then the linker defaults to _c_int00.

    If you can provide the path you have for Task 28 project, then we will be able to direct the question to appropriate group. But most likely the project would have some kind of build settings to let it build to run from RAM or FLASH. Once you set that up correct it should start working.

    Best Regards

    Santosh Athuru

  • 0 in reply to Santosh Athuru
    Genius 4995 points

    Santosh,

    No. I cannot provide the path to that example, because the CCS design insists on hiding all that information.  I have absolutely NO CLUE where the CCS Resource Explorer found this thing.  I have attached the screen shot of what I selected.  

    When I load it from CCS, it runs.  When I try to just run it by powering up the board, it doesn't.  (I have since then added the "boot.asm" file, and now it works)

    As for your information, it is not correct.  I am already linking to "driverlib.lib" in that "task28_experimenterkit_piccolo...", and it is NOT providing an entry point called "codestart".  On the other hand, the "Example F2802xLaunchPadDemo" has "driverlib.lib" listed in the project (linked file).  So both projects use that file, although different versions.  

    The linker cmd file is already directing ALL the code into flash.  And the boot ROM is directing the entry point to a location in FLASH.  But there is no way to make "_c_int00" be assigned to that entry point address.  

    Instead, I imported the ASM code to define that point.  Now it does what it is supposed to.  Would have been nice if that was explained somewhere. Or documented somewhere.  Or just *something* that didn't take 5 days of wasting time trying to figure this out.

    Is the BOOT ROM inside the TMS320F28027 always burned this way, or is it ONLY in the chips are are on the Piccolo launchpad devices?  If we bought a hundred chips, would they have this ROM burned, or would it be blank and we have to code it ourselves?

    It would also be nice if my CCS wasn't constantly crashing. I keep getting "Just In Time" debugger messages from the visual studio wanting to debug "cef_sub_process.exe" which is owned by CCS.

  • 0 in reply to Christopher Weber
    Genius 4995 points

    To anyone else who has this problem, it is because the BOOT ROM in the Piccolo board is trying to execute the memory location 0x003f7ff6 as the entry point to the compiled program... But there is no way to set the C compiler to designate "_c_int00" to that location.
    It would appear that "_c_int00" is not actually a "label" to a location.

    The solution is to add the following small assembler code to your project. Name this "boot.asm" or similar. This has a real label named "codestart", and it is a simple jump to the location "_c_int00". (You do NOT want to jump to "main" because the C program has to set up stuff before main can run, like initializing variables in ram).

    ***********************************************************************
* CodeStartBranch.asm
***********************************************************************
 .ref _c_int00
 .sect "codestart"
 LB _c_int00 ;branch to start of code
 .end ;end of file CodeStartBranch.asm

    Placing the code in a text file, and inside the project should build this as an object file, and link it correctly, provided you are setting your "cmd" file with the segment below:

    SECTIONS
    {
    /* Allocate program areas: */
    .cinit : > FLASH PAGE = 0
    .pinit : > FLASH PAGE = 0
    .text : > FLASH PAGE = 0
    codestart : > BEGIN PAGE = 0

    Then, after loading the Piccolo device, you can unplug it, and plug into another power source and it will run.