• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 973 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.

CCS/TMS320F28335: I encountered a memory problem

Dong Hua Jung
Prodigy 140 points
Part Number: TMS320F28335
Other Parts Discussed in Thread: CONTROLSUITE

Tool/software: Code Composer Studio

Recently I was transferring my program from CCS v5.1 to CCS v6.2. However, after I import my project into v6.2 and press compile, the problem below showed up.

I thought it is the problem about memory, so I modified the F28335_RAM_Ink.cmd as the following picture shows.

After this, it can compile successfully, but another problem showed up as below:

I have checked the program step by step. First, something weird happened when the program ran into "InitSysCtrl()".

It will stop at " asm("      ESTOP0") ". I'm a little bit confused of it.

 

and then I kept running the program, another trouble arouse in "InitAdc()" It happened in the command of DELAY_US(ADC_usDELAY) as below.

Hope someone could help me get through this, thanks.

By the way, this program is created in the version of v5.1, but I have created another new one in v6.1, and all those include file is from controlSuite v142.

  • 0
    Guru 192875 points

    Hi,

    Dong Hua Jung said:
    Recently I was transferring my program from CCS v5.1 to CCS v6.2. However, after I import my project into v6.2 and press compile, the problem below showed up.

    There is a possibility that the wrong linker (.cmd) file was selected when it got imported to CCS v6.2. Can you check with the CCS v5.1 project, which one was chosen? As your project seems to have multiple linker (.cmd) files, I got this doubt. Also, I assume that the project was executing well when it was debugged from CCS v5.1

    Regards,

    Gautam 

  • 0 in reply to Gautam Iyer
    TI__Guru 62975 points
    Dong Hua Jung,

    You should also check to see if the same GEL file is used between CCS versions. The GEL file can execute instructions at target connect and program load time.

    -Tommy
  • 0 in reply to Gautam Iyer
    Prodigy 140 points

    Hi, Gautam :

    This project works well on the v5.1.

    there is an issue I have to mention. We use different computers for these two versions. 

    The v5.1 is installed on the computer in my lab whose OS is win7, and the v6.1 is installed on my own computer whose OS is win10.

    and the cmd file in the version v5.1 is from controlSUITE v.131 with some amendment from my senior as below:

    And if I use this cmd file, the problem is still the same:

    Thanks. 

  • 0 in reply to Dong Hua Jung
    TI__Mastermind 30255 points
    Hello

    Are you sure you're including the "DSP2833x_Headers_nonBIOS.cmd" file? From the list of warnings I see, I would guess no. Without that, the bitfields won't work correctly and likely why you're seeing an issue.

    Best regards
    Chris
  • 0 in reply to Christopher Chiarella
    Prodigy 140 points
    Now I have included it,but the problem is still the same.
    Acoodring to my observation, it always runs into the ESTOP0 loop when operating DELAY_US(A) in DSP2833x_Examples.h.
    Could you please help me find the problem~. This has confused me for couple weeks. Now I'm really in a hurry.
    Thanks

    Best regards
    Jacky
  • 0 in reply to Dong Hua Jung
    TI__Mastermind 30255 points
    Jacky

    What ESTOP0 are you referring to? Did you resolve the ESTOP in InitPLL issue?
    That address it says that no source is available, is there anything there?

    Also is F28335_RAM_HVPM_Sensorless.cmd the linker file you're using? I can't see what sections are assigned to what but you have RAMLx RAMs that are using the same address space on page0 and page1. The memory is unified, so the pages don't matter and this means they will both be using the same memory locations. Ex: Your RAML4 is same as RAML2 as well as other conflicts. If you're using these, then that is likely why you're seeing weird behavior.

    Best regards
    Chris