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/TMS320F28027: Won't boot after reset. 0x3FF5F5 (no symbols are defined)

Part Number: TMS320F28027
Other Parts Discussed in Thread: LAUNCHXL-F28027

Tool/software: Code Composer Studio

Device won't run any code after pressing the reset button or after a power reset. It works fine when the code loaded from the debugger, but for only once. When i press the reset button, debugger says "Ox3FF5F5(no symbols are defined ) and the device freezes. This happens to every code which i loaded.  

I searched  for the information about the above memory location and, from the bootloader  reference guide i found out that it belongs to the "boot rom function" area. But i wasn't able to find any description or guide for the "boot rom function" section.

Im a new user and sorry for my bad english. Please give some advice to repair the device.

  • Damith,

    You need to configure the boot modes. Please see the following workshop:

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

    Note that the F2803x is similar to the F2802x (for the most part), except it has additional memory and the CLA. Reference the lab 5 directions on page 5-20 (page 82), step 11, for setting the EMU_KEY and EMU_BMODE values.

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

    - Ken
  • Thank you for the response. Can you please give me some reference or description about boot rom functions. I can't find it anywhere. There is no description about it in the boot rom reference guide.
  • Damith,

    The "TMS320x2802x Piccolo Boot ROM Reference Guide" can be found at:

    www.ti.com/lit/sprufn6

    and see section 2.9 for bootloader modes. Later sections in chapter 2 include details about the various boot functions.

    To find additional information about the F28027 family, please visit:

    www.ti.com/.../tms320F28027

    Also, in the F2803x multi-day workshop link that I previously sent you, see pages 4-3 (page 53) though 4-5 (page 55) in the workshop manual to learn more about the bootloader.

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

    - Ken
  • I followed the instructions. After loading the code to the device, i opened the memory browser window and looked for the 0x0D00 and 0D01, which is EMU KEY and boot mode location. Instructions says it should have the value of 55AA and 0003  to work as the emulation boot and boot from flash. But it have the values 34CC and 003F. Then i changed those values to 55AA and 0001.  But code still won't run after i press reset button on the board or cpu reset in the debugger. Device freezes and debugger says no symbols defined for 3bf7ff.

    2 otp locations and 2 gpio pins have  the right value and position.

    then After i press the restart (not reset) button in the debugger, code runs fine. But 0D00 and 0D01 values again change to 34CC and 003f. not only that, This value sequence is appeared from 0D00 to 0D19. I dont know what's happening.

    What functions change those memory locations automatically. Why this happening.

  • Damith,

    Please let me know which development target you are using (e.g. LaunchPad, Experimenter Kit, etc.) and which version of CCS. Also, please let me know how you set up the target configuration file.

    - Ken
  • I used Launchpad XL F28027.
    CCS v7.4
    Traget configuration.-
    Connection- TI XDS100v1 USB Debug probe
    Device- TMS320F28027
    I selected above and saved the target configuration file .

    What are the functions which change the emu key and mode memory locations like that. ?
  • Damith,

    I tested some code on the LaunchXL-F28027 using your target configuration with CCSv7 and did not have a problem. The EMU_KEY is 0x55AA, and the EMU_BMODE needs to be 0x000A to boot from RAM or 0x000B to boot from flash. (Note that if using GetMode you must first program the OTP). The switch settings on S1 are all up.

    Let's try some code on your board from the following workshop:

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

    Import the solution file for Lab 2. You will receive a warning that this project was built with a previous version of the tools. Go to the Properties for the project and select the later version of the compiler and the warning will go away. Load the program and open a Memory Browser window to 0X0D00. Then using the CCS Scripts change the EMU Boot Mode Select between SARAM and FLASH and you should see the BMODE (0x0D01) change between 0x000A and 0x000B. With the BMODE set to SARAM reset the device, Run -> Go Main, then run (Resume). At this point, if all went well you should be trapped at an ESTOP instruction. If you would like, try lab 4 for testing the flash (see the workshop manual for directions). Please let me know what happens.

    - Ken
  • Thank you. I will try that.
    I have some quetions.
    There are number of workshops. Which workshop should i use.
    What do you mean by CCS scripts.? How can i use that. Are there any function or library to change those memory locations from the software. ?
    Is
    Can't we edit the memory locations from memory browser window. ?
  • Damith,

    In my original post I included a link to the F28035 multi-day workshop:

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

    I also explained that the F2803x is similar to the F2802x (for the most part), except it has additional memory and the CLA. If using this workshop with you F28027 LaunchPad you will need to modify the linker command file and you will not be able to run the CLA and DSP/BIOS lab exercises. I referenced this workshop because it includes more details than the one-day workshop. That being said, you could also use the F28027 1-day workshop at:

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

    I would recommend running the lab exercises in this workshop to become more familiar with the device and CCS. You should be able to run this workshop as is, except this workshop uses the controlSTICK, so you will need to remap the jumper pins in the lab exercises to use the LaunchPad. Then if you want to use the multi-day workshop, you could use the linker command file from the one-day workshop with the multi-day workshop, except as noted previously about the memory, CLA, and DSP/BIOS.

    Also, in my previous post, I referenced the multi-day workshop lab 5 directions on page 5-20 (page 82), step 11, for setting the EMU_KEY and EMU_BMODE values. This step explained how to use the CCS Scripts. You will find the same directions in the one-day workshop in lab 2, step 9 on page 39.

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

    - Ken
  • I loaded those lab_2 files. Unlike you said, i didn't have to change the linker command file. Its compiled and loaded fine. That code works fine. No change in the emu key and mode locations.

    There is this code i find from the c2000 ware examples called flash. I removed the .c file which came with that and i wrote my own programme to blink the onboard leds. That code runs fine in stand alone mode, no problems but when connected to the debugger, it shows the previous problem. When i reset the cpu, emu key and mode locations change to some garbage values and device freezes.
    There is another program which wont run in standalone mode. I compared that program's properties and the flash (i mentioned above) program's properties, only change i found was, in the C2000 linker section summary of flags. In there, there is a line called "entry_point=c_int00" or something like that. I changed it into "entry_point=code_start"
    Then that code also works fine in stand alone mode but not in the debugger mode. It still writes some nonsense values to the emu locations.
    Also please note that, As soon as the cpu reset, this exact same value is appeared in a whole lots of memory areas beginning from the emu_key.
    I want to know,
    **What are the functions that automatically writes values to those locations. How can i stop that.***
    Also i want to know ***how properly set up the properties of a project. How choose the linker or whatever necessary files. ***-
    Those instructions are nowhere to be found.
    Even though the community help and the IDE and debugger is good, TI has the worst documentation for their devices and software. Instructions references are scattered everywhere, and, learning process is a pain in the.... unlike the avr or pic. no proper tutorials or anything on youtube. Just some tips videos only. Ask for hep from the community and solve the problem is like learning how to swim through the post cards.

    But i must say that the Response from the members is very good. But it will be very very productive if we had some proper guide to begin from the start.
    Thansk you very much for your hep sir.
  • Damith,

    Thanks for your reply. I was referring to the multi-day workshop Lab_5_6_7.cmd file and the one-day workshop Lab_2_3.cmd file. The multi-day workshop .cmd file has additional memory sections that do not exist in the F2802x device. The .cmd file will work, but you need to be aware of the differences. What I would like to do at this point is to get some common code that works on your LaunchPad and mine. This will eliminate the possibility of a bad board or device. Then we can work backwards and find out why you are having difficulty with your code.

    To keep thing simple, let us use the F28027 workshop solution files. Please download the "Piccolo One-Day Workshop Installer" file (which includes the workshop manual) from:

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

    Run this file - this will insure that we are using the same set up. We will run two lab solution files that will blink an LED - one running out of RAM and the other running out of flash. The jumper wire in the lab directions will not be needed. The workshop code blinks the LED connected to GPIO34, however the LEDs on the LaunchPad do not use this GPIO pin. Instead we will modify the Gpoi.c file to use GPIO33, which is connected to an LED on the LaunchPad.

    Now, using the directions for Lab 3, load the Lab3 solution file (step 1 and 2). Next, open Gpio.c and at the bottom of the file under the "Selected pin configurations" change the two lines from GPIO34 to GPIO33. Follow steps 4 and 5, the run the code. Does the LED blink? Halt the code and follow steps 19 and 20. This is the code running out of RAM test.

    Now, using the directions for Lab 4, load the Lab4 solution file (step 1 and 2). Modify the Gpio.c like before. Follow steps 14, 15 and 18 through 30. Does the LED blink? This is the code running out of flash test.

    Please let me know what happens.

    - Ken
  • I did as you said. I tried the examples in lab 3 and 4 of one day workshop. In my board, there is no LED connected to the gpio 33. But there are 4 leds connected to gpio 0-3. Therefore i changed the pin to gpio 2. But there is no blink at all. Just led remains off.  (To turn on led, gpio pin should set to low).  Above condition is same for both lab 3 and 4

    However, i noticed that the previous problem not occurred which is changing of the emu key and mode values after a reset. Code runs without crashes at the reset.

  • Damith,

    Yes, you are correct - the LEDs are connected to GPIO0-3. The schematic for the board and LED connections can be found on page 10 in the user's guide:

    www.ti.com/lit/spruhh2

    Sorry, I miss read the GPIO3 with the 3 pin on package thinking it was GPIO33. In any case, to get the LED to blink let's use GPIO1. In Gpio.c modify the following two lines at the bottom of the file (note GPA for group A, so change ...GPB... to ...GPA...):

    //--- Selected pin configurations
    GpioCtrlRegs.GPADIR.bit.GPIO1 = 1;
    GpioDataRegs.GPASET.bit.GPIO1 = 1;

    Next, in DefaultIsr_3_4 modify the following code lines in the ADC_INT1 ISR at line 168 :

    static volatile Uint16 GPIO1_count = 0; // Counter for pin toggle

    And the following code lines starting at line 193 (again note ...GPA... and not ...GPB...):

    if(GPIO1_count++ > 25000) // Toggle slowly to see the LED blink
    {
    GpioDataRegs.GPATOGGLE.bit.GPIO1 = 1; // Toggle the pin
    GPIO1_count = 0; // Reset the counter
    }

    The LED should now blink when running the code. Please confirm this.

    From your last post, it now looks like you can make changes to the KEY and BMODE values using the Scripts and see these changes in the Memory Browser. If this is the case, we both have "known good code" to use. Please compare this code to the code you are having issues with and let me know if you see any problems. I hope this helps.

    - Ken
  • I made those changes and code works fine. No problem after the power reset or normal reaet. I even checked the graph and it shows a 25% duty cycle pwm waveform.
    Do you know how to make a few milliseconds delay in a code. ?.
  • Damith,

    In the project you will find UsDelay.asm which implements a time delay. You can find examples of its usage in SysCtrl.c and Adc.c.

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

    - Ken
  • Where can i access the section files (ex .ebss .text) and edit them.
    I created a new project and started to debug it. I used an led on off sequence code from a working example. I used same linker files which used to that example code which are, Headers_nonBios.cmd and f28027.cmd files.
    Code compiled without a problem. It runs until i press the reset or power reset. This time, emu key and boot modes are ok. But there is a memory location which is 0x3f7ff6. That use to point to the code start point.
    I found that its value for working code is 007F and mine is just ffff.
    In the lab guide, they says there is a "section" called codestart which contain the value to this memory location. Where can i find and edit that. I can't edit the location from the memory browser.
    Linker file has a line that link the codestart section to the 3F7FF6.
  • Damith,

    The CodeStartBranch.asm file needs to be at the code entry point. It will branch to _c_int00(), which is part of the compiler runtime support library that sets up the compiler environment and then calls main(). If you are running from RAM this file needs to be at 0x000000 and if you are running from flash this file needs to be at 0x3F7FF6. (In the workshop manual see the top slide on page 30).

    The linker command file describes the physical hardware memory (MEMORY section) and specifies where the sections are placed in the memory (SECTIONS section). This is the key file that you edit for placing the various sections which need to be placed at specific memory locations (and not in the Memory Browser). In the workshop linker command files you will notice that for RAM there is a memory range for BEGIN_M0 (origin = 0x000000, length = 0x000002), and likewise for flash there is a memory range for BEGIN_FLASH (origin = 0x3F7FF6, length 0x000002). The CodeStartBranch.asm has a user defined section named 'codestart' and consists of a long branch (LB) to _c_int00(). This is exactly 2 words, hence the length of 0x000002. In the Sections section of the linker command file you will notice a section for 'codestart'. For RAM this section is placed in the memory location BEGIN_M0, and for flash this section is place in the memory location BEGIN_FLASH.

    I hope this helps.

    - Ken
  • Thank you very much for your help. My new code works just fine. However i didn't able to solve the problems with my original code.
    :)
  • Damith,

    You are very welcome. I am glad it is working now.

    - Ken