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.

Working TI-RTOS / Motorware project example

Other Parts Discussed in Thread: MOTORWARE, LAUNCHXL-F28069M, BOOSTXL-DRV8301

The BAD news is that getting TI-RTOS and Motorware to play together nicely is a major pain.

The GOOD news is that I've already done that, so you don't have to.

I've posted my code on github in the repository below. It's targeted to the LaunchXL-F28069M development board with the BOOSTXL-DRV8301 daughterboard. I've listed the tool versions and jumper settings in the README.txt file.

https://github.com/grantfreese/motorware_rtos_integration

The example is based on Motorware Lab03. The script file in (motorware_rtos_integration/js/proj_lab03a.js) can be loaded to provide the same variables that are used in the lab. The motor is turned on by setting gMotorVars.Flag_enableSys to 1, then by setting gMotorVars.Flag_Run_Identify to 1.

I still have some cleanup to do, but at least this should be a good starting point. Let me know if there are any questions.

Sidenote: I recommend creating a git repo in your TI folder and version-controlling the entire IDE. The motorware projects are very tightly coupled with the code in the TI folder (eg, for things like hal.h), and those files are far too easy to modify in the IDE. There's no indication that they are toolchain provided files rather than project files. If the TI folder is version controlled, then it's at least easy to identify and rollback changes.

  • Thanks for the project and initial work. I managed to get it working from your old project about the time this was posted after a bit of linker file manipulation.

    As flash erase cycles on this chip are spec'ed quite low, erasing takes a while, and ram debugging is a bit nicer as well, I got it to run out of RAM.
    This runs and debugs. I have NOT yet verified the motorware ISR rates are proper but the motors spin nicely.

    I uploaded a linker cmd file to the repository to put it all in RAM for quicker ram based debugging. This all seemed to be lacking documentation or details of actually getting it to work were burried deeply somewhere. It probably needs the build option FLASH to be turned off / renamed.

    If it didn't make it I can upload here or try again.
  • I don't think the push made it. If you let me know your github username, I'll add you as a contributor on the project.

    RAM debugging is definitely nice, but motorware is a 400 pound gorilla, and will quickly exceed the RAM size, especially when coupled with TI-RTOS. The thing that really compounds the issue is the 16-bit char size, so strings take up twice the amount of memory you would expect.

    If you can put the RAM build in a separate branch for now, that would be great. There's a couple things I'd like to verify before merging it into master.

  • Git User: PGClendenc

    I have modified the project for the DRV8301Kit_RevD PCB without regards to going back.  This was proof of concept to start with integrated RTOS / motorware for motor development.  Main.c needs a conditional compile of the flash to ram copying items. 

    We will see how far we can go with RAM debugging.  It would be nice to debug / test the J1939 stack, RS-232 communications, and such out of RAM while porting from other CPU's.  We have been spoiled with Keil tools as of late that simulate the whole uC including PCB. 

    7z of project is attached as well.

    Chad

    motorware_rtos_integration_RamDebug.7z

  • Any chance you have gotten this to work with a floating point compile?

    I have gotten it to build, compile, and run but it is not turning the motor.

    no bus voltage returned.  a few other probelms. 

    Functions needing repair / removal:

    updateGlobalVariables_motor: many functions returning floats need to be casted as per fpu32 FOC labs.

    USER_calcPIgains() function is not fpu32 compatible as is.

    Libraries:

    Need to change to fpu32 version

    Link order of the various libraries is important.

    Forum suggests that it can work but ... havn't gotten it yet. 

    I have spent more time fighting the TI tools than I have in the last few years with my other ones.

    Chad

  • I did get it working with FPU32 at one point, but that was on a branch that I'm unable to share.

    I'll see if I can get that working in the next few days.

    Grant

  • Okay, I got FPU32 working and verified that it turns a motor. I've pushed it to master on the github repo.

    There was a bunch of different project settings that had to be tweaked to get it working-

    * Change RTS library to rts2800_fpu32.lib
    * Change RTSC target to ti.targets.C28_float
    * Change --float_support=softlib to --float_support=fpu32
    * Change SpinTac.lib to SpinTAC_fpu32.lib
    * Change 2806xRevB_FastSpinROMSymbols.lib to 2806xRevB_FastSpinROMSymbols_fpu32.lib
    * Change IQmath.lib to IQmath_fpu32.lib
    * Move rts2800_fpu32.lib to top of link order

    Note: My memory is a bit foggy on the subject, but I recall reading a while back that the routines in IQmath_fpu32.lib were drop-in replacements for some of the ones in rts2800_fpu32 to improve efficiency. When IQmath_fpu32.lib is at the top of the link order though, it exhibits the same exact issue as when you use the F28069 ROM addresses for the IQMath tables, rather than the F28069M linker address. I'm thinking that maybe IQmath_fpu32.lib was built incorrectly with the F28069 linker file?

    Grant
  • Could you verify it actually made it up there? 

    The project on there has had the releases build converted to fp32 but that was missing much CPU configuration and didn't want to build without quite a bit of coaxing, adding libraries, etc.   It is also possible it didn't update.   Debug (fixed pt) build seemed to work fine once built.  I have it on the 40 amp 8301 eval board so I didn't expect it to spin but it does try to cal the motor.

    On the Release fpu32 - once it did build, it is hitting abort function after the hal_user.c call of HAL_SetupFlash() call line 711 or HAL_CAL() at the ADC.

    I was seeing similar problems with the ADC cal or offset funtcion with my project. 

    I configured this to have 2 debug builds - a fixed point and a fpu32 both running from ram.  Same code, different libraries and fpu settings.

    The fixed point works fine, fpu32 crashes in the hal_cal.

    Thanks !!

    Chad

  • Yeah- my code is up there. It's on master (dd717fdb9a67464a09ef43059657d859644972cc)

    It's going to be difficult to figure out what's going on in your case if you're using different hardware. The launchpad F28069M, and the BOOSTXL-DRV8301 module are the targets of this project.

    Can you confirm you're on the same tool version?

    	CCS 6.1.2.00015
    	TI Compiler 6.4.10
    	TI-RTOS 2.16.0.08
    	XDCTools 3.32.0.06
    	Motorware 1.01.00.16

    I've been using the debug build target, not release. It wouldn't surprise me if the release target doesn't work. I can't remember if I'm using a flash build or a ram build, but I'll check when I get home tonight.

    Grant
  • I have TI-rtos 2.16.0.14, the rest are identical.
    I installed 2.16.0.08 - CCS is not happy. Does not recognize either now.

    Restoring TI directory from backup now.

    I have the launchpad listed above, can try on that as well. I have the 8305 not 8301 but I suspect that does not matter for making it through the bios_start() function and actually starting the tasks. I figured that with the same CPU that it behave about the same until it actually needed hardware.

    I lLso got a zip off GIT and that has the updated projects. Probably user error or a branch - don't use GIT much.

    Will update once the tools are functional again.

    Chad
  • Update:

    Tools restored.  The project downloaded as zip from git behaved as is.

    Project migrated to ram linker file. Had to adjust it / combine memory chunks due to larger memory footprint due to RTOS instrumentation.  Debug is much nicer from RAM.

    Adjusted TI boost8305 drivers as 8301 were. Launchpad works with 8305 board now. Files uploaded to Git. Project has not otherwise been updated to use them.   Define NO_RTOS as 0 in project options or adjust new hal files accordingly.

     

    Along the way, discoveries and headaches:

    If FLASH is not defined, it may hang in a HAL_CAL, a HAL_ADC cal function, or get stuck in ROM.

    RTOS may not run tasks if optimization was set at 1. 2 and 4 worked. 0 and 3 were not tested.

    XDC errors in various file lines:  Need to delete the project debug directories.

    Some Motorware functions in main.c updateGlobalVariables_motor need adjustment for fp32. Change committed to master. Refer to fpu32 labs for more but essentially compiler is not properly dealing with return values from ROM libraries.

    Now it is working here on the launchpad board, it is time to to migrate it to the high current eval board.

    Thanks again.