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.

TMS320F28069F: Error: Program "make" is not found in PATH

Part Number: TMS320F28069F
Other Parts Discussed in Thread: DRV8301, MOTORWARE,

Hello,

I've been developing with InstaSpin for some time. I recently did a new spin of a custom board, based heavily on the DRV8301 kit, Rev D.

There were only very minor changes, and the new version of the board is VERY close to the previous version. I just had to widen some of the clearances to meet requirements for creepage and clearance mandated by the FDA. The new board, however, does not spin the motor, using the firmware developed for the previous rev.

I figured I'd try going back to the Labs to determine whether this new board works at all. I'd start with Lab 1b, to see whether I can spin the motor open-loop. If that worked, then I would characterize the motor with Labs 2a or 2c. Maybe my problem is that the "motor" characteristics may have changed (from InstaSpin's point of view), due to the board changes, and that's why the motor no longer spins.

When I tried to use Lab 1b, however, I got the following error:

Program "make" is not found in PATH.

It also appears that the compiler does not know the meaning of various data types (uint16_t, etc...). I added types.h to the includes for proj_lab01b.c. Still didn't recognize the data types, so I included the entire path as follows:

#include "C:\ti\motorware\motorware_1_01_00_18\sw\modules\types\src\types.h"

Can I get some help?

Thanks,

Dave

  • Update:

    The original error in my post was evidently related to my trying to use Lab 01b in an already existing workspace. I created a new workspace and was able to select "Use default build command" under the Builder tab in Project Properties, which it wasn't allowing me to do in the existing workspace.

    It still doesn't recognize any of the custom data types, though.

  • Ok - I got rid of a lot of these errors by referencing the entire path, as above.

    But there are a couple of persistent errors:

    Cannot find file "libc.a"

    program will not fit into available (that's it, seemingly only a partial message)

    unresolved symbol _ceil, first referenced in ./user.obj

  • Hello Dave,

    Can you send me a screenshot of all the errors you're seeing? Additionally, please include a screenshot of your include options in your project properties.

    Regards,
    Jason Osborn

  • Hi Jason,

    Here are the errors that are left. I got rid of the "program will not fit..." by raising the Optimization level to 2.

    Here are the includes from project properties:

    Thanks,

    Dave

  • Hmm, odd. What are the 4 warnings that are being generated?

    Regards,
    Jason Osbron

  • Here are the warnings:

    and the compiler flags from Project Properties:

  • Hello again,

    Please try compiling a fresh, unaltered version of Lab 1b and see if you encounter the same issues- this may require a re-installation of motorware if you were changing linked source files instead of local copies.

    Additionally, what files, exactly, did you alter to account for this motor? Did you adjust a .cmd file?

    Regards,
    Jason Osborn

  • Hi Jason,

    28069_RAM_lnk.cmd was altered, but only when I changed the optimization. I didn't go in personally and change anything.

    There were innumerable other files changed (mostly header files) when I was substituting explicit file locations for relative ones, in hopes of getting the compiler to find those paths.

    I'll try re-installing motorware, and keep my fingers crossed that it doesn't mess up the code in my actual project. I think I placed everything for the project in one location.

    Thanks,

    Dave

  • Hi Jason,

    I re-installed Motorware. Now there are 172 errors.

    Here's a small sample:

    Best Regards,

    Dave

  • Dave,

    I am... Not sure how that happened. It looks like files are no longer being linked properly. Is this after importing a fresh lab?

    Regards,
    Jason Osborn

  • Yes - this is from the new Motorware installation, here:

  • Here are a couple of errors from the Build Console:

    Building target: "proj_lab01b.out"
    Invoking: C2000 Linker
    "C:/ti/ccs1210/ccs/tools/compiler/ti-cgt-c2000_22.6.0.LTS/bin/cl2000" -v28 -ml -mt --cla_support=cla0 --float_support=fpu32 --vcu_support=vcu0 -O2 --opt_for_speed=2 --advice:performance=all --define=FAST_ROM_V1p6 -g --diag_warning=225 --display_error_number --abi=coffabi -z -m"proj_lab01b.map" --stack_size=0x3B0 --warn_sections -i"C:/ti/ccs1210/ccs/tools/compiler/ti-cgt-c2000_22.6.0.LTS/lib" -i"C:/ti/ccs1210/ccs/tools/compiler/ti-cgt-c2000_22.6.0.LTS/include" --priority --reread_libs --disable_auto_rts --diag_suppress=16002 --xml_link_info="proj_lab01b_linkInfo.xml" --rom_model -o "proj_lab01b.out" "C:/ti/motorware/motorware_1_01_00_18/sw/modules/fast/lib/32b/f28x/f2806x/2806xRevB_FastSpinROMSymbols.lib" "C:/ti/motorware/motorware_1_01_00_18/sw/modules/iqmath/lib/f28x/32b/IQmath.lib" "./CodeStartBranch.obj" "./adc.obj" "./angle_gen.obj" "./clarke.obj" "./clk.obj" "./cpu.obj" "./cpu_time.obj" "./ctrl.obj" "./datalog.obj" "./drv8301.obj" "./flash.obj" "./gpio.obj" "./hal.obj" "./ipark.obj" "./osc.obj" "./pid.obj" "./pie.obj" "./pll.obj" "./proj_lab01b.obj" "./pwm.obj" "./pwr.obj" "./spi.obj" "./svgen.obj" "./timer.obj" "./usDelay.obj" "./user.obj" "./vs_freq.obj" "./wdog.obj" "../28069_RAM_lnk.cmd" -llibc.a
    <Linking>
    error #16008-D: file
    "C:/ti/motorware/motorware_1_01_00_18/sw/modules/fast/lib/32b/f28x/f2806x/28
    06xRevB_FastSpinROMSymbols.lib<TMS320x2806x_REVB_boot_rom_out_FD$$MPY_tmp.ob
    j>" specifies ISA revision "C2800", which is not compatible with ISA
    revision "C28FPU32" specified in a previous file or on the command line
    error #16008-D: file
    "C:/ti/motorware/motorware_1_01_00_18/sw/modules/fast/lib/32b/f28x/f2806x/28
    06xRevB_FastSpinROMSymbols.lib<TMS320x2806x_REVB_boot_rom_out_FD$$TOL_tmp.ob
    j>" specifies ISA revision "C2800", which is not compatible with ISA
    revision "C2700" specified in a previous file or on the command line.

    It seems to repeat:

             specifies ISA revision "C2800", which is not compatible with ISA
             revision "C28FPU32" specified in a previous file.

    in one form or another, for most of the errors listed.

    Thanks,

    Dave

  • Actually, all of them, except the very first one, involve "C2700", rather than "C28FPU32".

  • Here's one that's different:

    "../28069_RAM_lnk.cmd", line 121: error #10099-D: program will not fit into
    available memory, or the section contains a call site that requires a
    trampoline that can't be generated for this section. placement with
    alignment/blocking fails for section ".text" size 0x3046 page 0. Available
    memory ranges:
    RAML0_L3 size: 0x2000 unused: 0x1f13 max hole: 0x1f13

  • Take a look at the following link:

    This appears to discuss your exact issue. Please take a look and let me know if this helps at all.

    Regards,
    Jason Osborn

  • The microcontroller is a TMS320F28069F. One of the features is "Floating-Point Unit (FPU)." See pg. 1 of the data sheet.

    So how could the compiler be complaining if some of the compiler flags are as follows?

                    -v28 -ml -mt --cla_support=cla0 --float_support=fpu32

    I don't understand why it thinks the micro is strictly a fixed point.

    Or maybe it's complaining that not *all* files are compiled with these switches?

    I don't know what more to do to ensure that this is happening with all .c files and all libraries.

    I thought that the flags listed above would take care of that?

    Thanks,

    Dave

  • By the way - thanks for the reference. At least we have a clue now...

  • Hi Jason,

    Here's a screenshot of the include options in Project Properties:

    and the Compiler flags:

    These look like they're setting up the build options for floating point. I've assumed this is global, but maybe it's not?

    On the "Compiler Error and Warnings" page that you directed me to, it says      

    • Check each library and make sure each was built with the -v28 --float_support=FPU32 switch.

    How is that done?

    It also says

    • Make sure all .c files are compiled using the -v28 --float_support=FPU32 switch. (In Code Composer Studio you can set this as a global build option or a per-file build option).

    Again - how is that done? 

    Of course, the above questions are assuming that this is a floating-point device. The technical documentation I've seen indicates that this is the case. But the fact that much of the "floating-point" arithmetic that's done in the code is in IQ24 format implies that the device is fixed point - otherwise, such machinations would be unnecessary. Maybe the people who wrote this code wanted it to be portable to fixed-point devices?

    If this is indeed a fixed-point device, then the second part of the text in the relevant section of the "Compiler Error and Warnings" page would apply.

    This section states that "the RTS library should be changed to the non FPU32 version."

    How would I do that, if need be?

    Thanks,

    Dave

  • Dave, sorry for the delay, I was out for a week and I had thought I had asked someone to take over the thread- apparently not. Apologies again! I'll look into this today.

    Regards,
    Jason Osborn

  • Hello Dave,

    To update you on how things are going, I've replicated your issues, tracked down a few potential sources, and have isolated what I believe to be the primary source.

    • Right click 'exclude from build' on
      • IQmath.lib
      • 2806xRevB_FastSpinROMSymbols.lib
    • Right click on each of the above and 'Show in' -> 'System Explorer'
      • There should be files in each of these folders named identically except with _fpu32 appended to the end of the filename. Drag these into the project, select "link to project"

    After this, I had no more missing symbols.

    • Right click 'exclude from build' on F28068F_ram_lnk.cmd'. I don't know how that got there, honestly.
    • Right click and uncheck 'exclude from build' on F28069F_ram_lnk.cmd
      • If you have a custom cmd file, make sure it's linked and not excluded from the build instead.

    This fixed the memory issues.

    Successfully built. Hooray!

    Note that I also set the following in the project properties settings (show advanced settings):

    I'm uncertain which (if any) of these were relevant.

    Hope this finally helps,
    Jason Osborn

  • Hi Jason,

    Hey! That did it! Thanks!

    Best Regards,

    Dave