• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 84 subscribers
  • Views 1606 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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/TMDXIDDK379D: Compiler bug.

Wayne Hunter
Intellectual 340 points
Part Number: TMDXIDDK379D
Other Parts Discussed in Thread: CONTROLSUITE,

Tool/software: Code Composer Studio

I have an IDDK_PM_Servo_F2837x-v2 running CCS v7 on a Mac.  The variables that are initialized before main() of which there are many are not being initialized.  The system is not setup properly and interrupts do not work among other things.  How can this system have been tested?  Is there a compiler version that works?

Wayne Hunter

  • 0
    TI__Mastermind 27240 points

    check compiler version v6.4.6

  • 0 in reply to Ramesh Ramamoorthy
    Intellectual 340 points
    I upgraded the compiler via the app center. There is no clue of which version was downloaded or which I started with. Anyway there is no change. Can we switch to a more effective mode of communcation?
  • 0 in reply to Wayne Hunter
    TI__Mastermind 19810 points

    wayne,

    are you able to build and load any other device support example from ControlSuite for your device?

    do you see any build errors with the IDDK project or other examples? We have verified the IDDK example to be working with windows and CCS. The global initialized variables will get initialized by the c run time library linked by the compiler tools before code reaches main().

    Would you be able to verify this with a windows machine and if we can rule this to be a MAC problem, we can direct the question to the compiler tools support team for quicker resolution.

    Best Regard

    Santosh

  • 0 in reply to Santosh Athuru
    Intellectual 340 points

    I installed the software on a windows 10 machine.  The three arrays are initialized properly so some of the problem must be Mac based.  However EPwm1Regs points to 0xc940.  No idea where it got that idea.  It should be 0x4000.  So still no pwm and no interrupts and it hangs up in the for loop which sets the offsets.  I have been stuck in this for loop for almost a month now.  Not even been able to get through build level 1.

  • 0 in reply to Wayne Hunter
    Intellectual 340 points

    I have further details on the failure to initialize the variables on the TMDIDDK379D.  I have single stepped and set breakpoints through the initialization code.  It starts out OK for a few variables then reaches address 0x2E and finds a zero length and aborts.  The data for ePWM which has been the variable that I first noticed the problem is at address 0x235.  A long way to go.  The program then skips the binit and pinit sections.  I am assuming one of those is probably reserved  for flash transfer which would be OK.  I have no clue the purpose of the other.  Anyway this has to be either a bug or defective control card.  I have two and both do the same thing.  Not sure it is at the same address.  This board is useless to me.  Are you going to help or do I have to find another vendor?

  • 0 in reply to Wayne Hunter
    TI__Mastermind 19810 points
    Wayne,
    let me move the query to compilers team to help with the issue with build on MAC.

    Best Regards
    Santosh Athuru
  • 0 in reply to Wayne Hunter
    TI__Guru* 84285 points
    I'm sorry you are not satisfied with the forum. However, it is the best resource we currently have for general questions. We do want to get to the bottom of this ASAP, as it sounds like you may have uncovered one or more bugs in the tools. The compiler is aggressively tested (See processors.wiki.ti.com/.../Compiler_Validation), but sometimes bugs do slip through. Embedded systems tend to have very tricky requirements, and we can't always predict what situations may arise.

    The .cinit section is for initializing C global variables. The .pinit section is for initializing C++ global objects. The .binit section is for boot-time (RESET interrupt) copy tables. If you have a simple C or ASM program, you probably don't have any .pinit or .binit entries.

    You said the arrays were initialized properly when using the Windows tools; I'd like to make sure that isn't just coincidence. Do these arrays have complete initializer lists, or do you rely on zero-initialization for some of the elements? Be aware that in TI COFF, you need to completely initialize global objects manually. In order to get the standard C behavior, you need o arrange to default-zero-initialize arrays in another manner, such as with a fill value in the linker command file. The forthcoming EABI mode for C28x arranges this for you automatically. Please see
    processors.wiki.ti.com/.../Uninitialized_Static_Objects_Not_Set_to_Zero_in_COFF

    Please generate the assembly file for your program. (Use the --keep_asm compiler option.) You will see some .cinit records in the generated assembly code. You should find one for each global variable. If you don't, please post the definition of the variable, along with its initializer, and whatever .cinit records the compiler generates.

    I am a compiler expert, not a device expert, so I don't know immediately what the problem with EPwm1Regs is, or why you don't have interrupts. I'll probably need to get more information, such as a reproducable test case, before I could figure out how to attack this problem.

    Do you specify the address of EPwm1Regs, or is does that come from a linker command file?

    Where did the linker end up placing the interrupt vector? It would be very helpful to see the linker map file (use the --map_file linker option).

    You mentioned that "it hangs up in the for loop which sets the offsets." I'm not sure what you're referring to here. Could you describe the failure mode in more detail so I can figure out how to analyze it?

    We're going to need to know the compiler version. Please see
    www.youtube.com/watch
  • 0
    Intellectual 340 points
    The software is supplied by TI in the TMDXIDDK379D evaluation module. I have not changed it except to comment out the enable test at the beginning because I got tired of setting it. I have not even made it through build level 1. The for loop is near the end of main() and sets offsets for some of the A/Ds. It is stuck there because PWM 11 is not running. My last post on this subject pointed out that I have isolated it down to the initialization routine finding a zero length prematurely and exiting leaving many variables uninitialized including but not limited to the PWMs. :Your tips on programming practice are appreciated but this is TI software not mine. My earlier comment regarding Mac versus PC indicated that more variables were initialized on the PC but neither finish the job.

    I am sure that the forum approach is very cost effective for TI but very inadequate for problems such as mine. I have wasted about a month of my time chasing this problem. I expected the evm to work to specification out of the box and very disappointed in Ti's ability or willingness to help with this problem. What is InstaSpin?

    I read somewhere that a self test exists. Where can I get access to it. I would like to eliminate the possibility of a hardware issue.

    Wayne Hunter
  • 0 in reply to Wayne Hunter
    TI__Mastermind 19810 points

    Wayne Hunter said:
    ows 10 machine.  The three arrays are initialized properly so some of the problem must be Mac based.  However EPwm1Regs points to 0xc940.  No idea where it got that idea.  It should be 0x4000.  So still no pwm and no interrupts and it hangs up in the for loop which sets the offsets.  I have been stuck in this for loop for almost a month now.  Not even been able to get through build level 1.

    Wayne,

    getting back to the debug on windows, if you still have problem with windows environment :-

    the EPwm1Regs are linked to the peripheral address space using a linker command file that is used across may other examples. I'm not sure what is happening here. Can you send the MAP file you have built on windows machine? The example is verified to be working on windows and CCS.

    Best Regards

    Santosh Athuru

  • 0 in reply to Wayne Hunter
    TI__Expert 8950 points
    Wayne,

    I am able to compile and run the IDDK_PM_Servo_F2837x-v2 project with Win7 and CCS 6.1.2 and get correct results. I'm not sure what's going wrong in your setup, but I can tell you that EPwm1Regs is a linker variable and does not need to be initialized. It comes out as a structure located at address 0x4000.

    Can you tell us what compiler version you're using? If you right-click on the project name in CCS, choose Show Build Settings..., and then click on General in the tree list, you should be able to see which compiler version you're actually using.

    Also, which build configuration are you using? F2837x_RAM or F2837x_FLASH? You can see this next to the project name in the Project Explorer.

    If you'd like to test the hardware, you can try running some of the other examples in controlSUITE. I recommend blinky, cpu_timers, or one or the CLA math examples.
  • 0 in reply to Adam Haun
    Intellectual 340 points

    I have solved the initialization problem.  The rom boot stack was stomping on the initialization data.  I am sure someone with a background in the hardware would have recognized it quickly but without the source code on the rom I was not even aware that the rom stack was in that area.  The role of the rom boot is still a mystery to me when booting to ram.  You might want to fix the problem in the ram .cmd file and it would be nice if the product were tested before releasing for sale.

    In several places in the literature you recommend turning off real time mode.  There is an icon to turn real time mode on but I do not find any means to turn it off.  There is a check box in right click project name/properties/debug/auto run which is already unchecked.  I have checked then unchecked it anyway.  Not sure it gets the job done.  Can you steer me in the right direction?

    Wayne Hunter

  • 0 in reply to Wayne Hunter
    TI__Expert 8950 points
    You should be able to turn off real-time mode by clicking on the same CCS button you use to enable it. It's a debugger setting, so you don't need to change the project properties.

    The CPU1 boot ROM runs after every reset (except for debugger resets). The CPU2 boot ROM runs whenever CPU2 is brought out of reset by CPU1. This happens before application code is run, so it shouldn't interfere with anything unless you're trying to save data across a hibernate. (That example isn't.)