• State Resolved
  • Locked Locked
  • Replies 22 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 3802 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.

Motor will not turn after Ti-RTOS integration

Grant Freese
Intellectual 700 points
Other Parts Discussed in Thread: MOTORWARE, SYSBIOS, CONTROLSUITE

I'm working on integrating Ti-RTOS with motorware and getting it to run on the Launchpad 28069 board. The motor sometimes moves a quarter turn after setting the run variable, but otherwise remains motionless. 

Motorware lab03a was used as my starting point. The motor parameters in user_j5.h work just fine in a normal lab03a project. The major changes made to the lab03a code were removing pie.c (handled by RTOS now), and turning the main motorware control loop into an RTOS task. The hal.c file was also copied into the project and renamed as hal_USER.c, since the pie stuff had to be removed. None of the files in the c:\ti folder are modified for this project.

* The ADCs work (gMotorVars.VdcBus_kV)

* Speed reporting works (gMotorVars.Speed_krpm)

* The ADC interrupts occur at the correct intervals

* Ti-RTOS tasks work

I've attached a git repo that has my current progress. Help on this would be most appreciated.

Thanks,

Grant

ws_motorware_rtos_integration_2015-07-23_0416PM.tar.gz

  • 0
    TI__Guru** 118000 points
    Grant,
    I don't think there are many people who have MotorWare running on TI-RTOS. You may have more luck asking on the CCS / RTOS forum....but they may run into difficulties because they don't know the details of MotorWare or how some of the CTRL/EST code is in protected on-chip memory.
  • 0 in reply to ChrisClearman
    Intellectual 700 points
    This seems to be more of a motorware issue though. All of the TI-RTOS stuff seems to be working pretty well. I don't have any insight into the internals of motorware, so I don't know where to even start on debugging this issue.
  • 0 in reply to Grant Freese
    TI__Guru** 118000 points
    I've sent this to someone else on the team who might be able to offer some insight. I still think it may be worth at least asking the RTOS experts if they have any thoughts.
  • 0
    TI__Mastermind 22025 points

    Hi Grant!

    I've done a little work combining TI-RTOS and real time control application, so lets see if together we can fix this.

    I took a look at the project you posted and everything looks ok for the most part.  By chance, Have you tried unplugging the ADC interrupt from the HWI manager?  TI-RTOS gives you a way to effectively unplug ISRs from being managed by TI-RTOS.  This decreases the latency of the interrupts and makes them run just like they were outside an RTOS.  You can find some more info about it here:

    http://processors.wiki.ti.com/index.php/SYS/BIOS_for_the_28x#Handling_28x_Interrupts_with_SYS.2FBIOS

    If this doesn't work, we can continue to dig deeper.

    Best Regards,

  • 0 in reply to Trey German289
    Intellectual 700 points

    Awesome, glad to have your help Trey. I'm out of town for defcon this week, but will jump back on this soon as I return.

  • 0 in reply to Trey German289
    Intellectual 700 points
    Sorry about the late reply. I just now became available to work on this issue again.

    I had to remove pie.c from my project in order to get Ti-RTOS running. When pie.c is present, it jumps to 'interrupt void PIE_illegalIsr(void)' shortly after startup. How would I handle the unplugged interrupt without pie.c?

    Alternatively, how would I get pie.c working with TI-RTOS?

    Thanks,

    Grant
  • 0 in reply to Grant Freese
    TI__Mastermind 22025 points

    Grant,

    TI-RTOS handles all the interrupts so there is no need for pie.c.  Alternatively, there is no way for TI-RTOS to co-exist with pie.c

    Best,

  • 0 in reply to Trey German289
    Intellectual 700 points

    I'm a bit confused- If I unplug the interrupt, is it still managed by TI-RTOS? How would I tell it what handler to execute?

  • 0 in reply to Grant Freese
    TI__Mastermind 22025 points

    Grant,

    My apologies, I misspoke.  You should be able to have pie.c in the project, but you need to be careful what functions you're calling.  When it jumps to the illegal ISR function, are you calling any functions in pie.c?

    Best,

  • 0 in reply to Trey German289
    Intellectual 700 points

    Trey,

    Initially when I added Ti-RTOS into the motorware project before ripping out pie.c, I would get the illegal ISR. I removed that a while back, and no longer get that.

    I'm still a bit unclear as to how to get the zero latency ISR working with Ti-RTOS. I've done the following:

    * Removed the HWI for the ADC (I currently have no HWIs)

    * Zero latency IER mask in 'Hwi (ti.sysbios.family.c28)' is set to 0x200

    * The following line of code is called right before HAL_enableAdcInts() --  Hwi_plug(104, (Hwi_PlugFuncPtr)&isr_ADC1);

    With the above done, what do I need to call from pie in order to get the zero latency ADC interrupt working without conflicting with Ti-RTOS?

    Thanks,

    Grant

  • 0 in reply to Grant Freese
    Intellectual 700 points

    I also got a bit more instrumentation on the issue. The logic traces below were captured with the ADC interrupt being handled by Ti-RTOS. 

    The above logic trace shows my three PWM channels on top. The 'debug' trace is an IO pin that's set on the top of the ADC ISR, and reset at the bottom of the ISR. The trace was captured while running lab03. The first half is it calculating Rs, and the second half is when it goes online. The PWM erratically stops and restarts.

    Above is a zoomed in view of the previous trace while the system was in the online state. The PWM section in the middle looks perfectly normal. Additionally, the interrupt timing below does not appear to change. (Note- I'm using 20 KHz PWM with 2 isr ticks per ctrl tick to try and reduce ADC ISR time. This is why every other ADC tick is shortened.)

    The PWM channels do not always work at the same time. 

    Other notes:

    * As soon as the software goes into the 'online' state, it immediately hits the 6 amp limit on my power supply and drops significantly in voltage. Would the excessive current be causing the PWM channels to turn off?

    * I've also tried setting the ADC interrupt to mask all in the Hwi, but it had no effect. Is there maybe something other than the ADC interrupt that could be causing this issue?

  • 0 in reply to Grant Freese
    Intellectual 700 points
    Also- I just got the zero latency interrupts working, but it did not resolve the issue. I see the same behavior with zero latency interrupts as I'm seeing in the logic traces in my previous reply.

    Any thoughts on other things that could cause the issue?

    Thanks,

    Grant
  • 0 in reply to Grant Freese
    Intellectual 700 points
    I found something pretty interesting-

    I uncommented the original motorware code for setting up the interrupt through pie.c, commented out BIOS_start(), and instead called task_motorware() directly at the bottom of main(). This should be bypassing the Ti-RTOS scheduler entirely.

    In this configuration, the erratic PWM issue still persists.
  • 0 in reply to Grant Freese
    TI__Mastermind 22025 points
    Hrmmm...strange.

    Have you successfully gotten the motor spinning with an unmodified motorware project?

    If I'm not mistaken, lab 3 is the torque control loop lab. With an unloaded motor, I've seen similar currently limiting situations with my supply. Basically, when you enable the motor you request a certain amount of torque but because the motor is unloaded this torque level is never reached. In order to try to hit the torque level the controller goes to max duty cycle and hit the current limit of the supply.

    For this reason, I like testing with lab2.
  • 0 in reply to Trey German289
    Intellectual 700 points

    I think I found the cause of the issue. It's something in the linker file. I replaced it with the linker file from a motorware project, shuffled some stuff around to fit, and that got it working. The motor turns just fine, and I have another RTOS task executing concurrently.

    Regarding your questions- Yes, I got it working before in a plain motorware project. I was troubleshooting with lab03a since it starts up quicker than the other labs.

    Can you take a look at the linker files I've attached? It would be extremely helpful to know what it was in the linker command file that was breaking things.

    Thanks,

    Grant

    integration_linker_files.7z

  • 0 in reply to Grant Freese
    TI__Mastermind 22025 points

    Grant,

    I took a look at the files, and I don't see any major differences.  The only thing I'm seeing is that the file that doesn't work combines multiple memory sections together, while the one that works doesn't.  This is making me think the issue could be related to data paging.  Basically some data may be getting split across a boundary and the compiler isn't dealing with it properly.  Does that make sense?

    Best,

  • 0 in reply to Trey German289
    Intellectual 700 points

    Trey,

    I see what you're getting at, but I really need a concrete answer on exactly what is breaking my software. Would you mind running the linker files by a few of the others in the Motorware and Ti-RTOS teams to see if they can identify a specific cause?

    Thanks!

    Grant

  • 0 in reply to Grant Freese
    Intellectual 330 points
    Hey Grant,

    Have you had any more luck with the F28069-launchpad and TI-RTOS? According to "TI-RTOS Product Releases and Download Links", from 25th of Februari 2016, there should be a TI-RTOS release (2.16.xx) that officially supports the c2000.

    software-dl.ti.com/.../index.html

    Regards
    Robert
  • 0 in reply to Golgor
    Intellectual 700 points

    Hi Robert,

    Yes- I did get TI-RTOS and Motorware working together. If I remember correctly, the issue above was caused by an incorrect addresses IQTABLES3 in the linker file. I based my linker file on the F28069 one from ControlSuite. The documentation doesn't exactly spell this out, but the F28069M device needs different addresses for that. That issue is discussed in the link below-

    https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/470757

    That said, there's still a pretty major issue. Motorware takes up about 40-60% CPU time when running, and most of that is interrupt time. Given that constraint, it makes more sense to dedicate a motorware chip to motor control, and use a separate MCU for everything else in the system. Unfortunately, that is a rather expensive solution.

    The TI-RTOS+Motorware platform combination only has limited support from TI,  so it would have slowed down development by quite a bit if we had stuck with that platform.

    I'll see if I can post a working copy of my code a bit later.

    Grant

  • 0 in reply to Grant Freese
    Intellectual 330 points

    Ok, good to know! I got a quite good reply from Chris Clearman in my own questions post, se link below. I think using RTOS will only be purely experimental when I have time to test it, and not use it as first hand choice in a real project.

    e2e.ti.com/.../1825955

  • 0 in reply to Grant Freese
    Prodigy 130 points

    Any chance you have / could post a working demo RTOS + motorware project? 

    It sounds that several of us are desiring to get a RTOS working with Motorware.

    TI still has not fixed the IQTables3 address in the 28069M ...

    It is disappointing that the TI rtos people don't talk to the motorware people much as RTOS greatly simplifies things that need to have pauses such as reading blocks from E2 prior to using them, communications threads, etc.  There may only be 10-20% CPU left.  I have some controllers that only use 20% of the available CPU cycles for their whole entire job.

    Thanks,

    CHad

  • 0 in reply to Chad Clendening
    Intellectual 700 points
    Sorry about the late reply on this. I've partially cleaned up and documented my project. It's posted on github. This thread was getting a bit long, so I started another thread for it.

    e2e.ti.com/.../523232