Embedding the TI Motor Control Libraries into a larger project

Ari,

The projects available in controlSUITE can be copied and kept anywhere on your disk, to prevent any changes to happen from the automatic installer. Also any updates use revision on all the folders and hence would not delete anything from your file system. It would generate warnings before deleting anything from the file system.Also any new changes to the header files comes with revision notes. Please look at the DSP<devicename>_HeaderFiles_Quickstart_Readme.pdf in the device support directory under docs to see the changes.

I would suggest keeping the directory structure which is being used by the controlSUITE, you can still use ccsv3.3 if you like to with it however i would recommend using CCSv4.1.3 or later. 

Regards

Manish Bhardwaj

Manish,

I didn't quite understand your answer.

all the header files are spread around in about 7-8 different directories...

are you suggesting copying the whole controlsuite directory each time I want to open a new version ?

maybe there is some tool that gathers all of the files needed for a project together ?

besides that a couple of questions:

1. should I use the header files delivered with the controlsuite or should I use the ones that come with the examples ? I assume the header files in the controlsuite are more up-to-date...

2. if you could explain the strange behavior of the SCI interrupts I described previously it'll be great..

thanks

Ari.

Ari,

These are  just suggestions no right or wrong. The controlsuite includes the example and header files as well

controlSUITE\device_support\f2803x\v122 etc..

if a software specifically an application software related to the kit is still using an older version on the header file that version is maintained in controlSUITE.

Now when you copy the control suite into another directory you can remove whatever you may not need and manage your project accordingly.

Whenever a new version is available you can then just copy that particular folder into your directory, not the entire controlSUITE.

Rest, it's an age old question of project management that you are trying to ask, which i may not be able to answer by just suggesting one route.

About the SCI question,PIEACK is necessary, and i find it strange that it worked without acknowledging it.

Are you able to repeat the behavior?

Manish,

regarding the PIEACK I've found something a little bit disturbing:

when you use OR to write tothe register, it'll clear all flags !!

even the line:

PieCtrlRegs.PIEACK.all |= 0x0000;

will clear all flags !!

this was the strange behavior with the SCI - I have a Timer0 interrupt, and I used the line:

PieCtrlRegs.PIEACK.all |= PIEACK_GROUP1;

This behavior is not documented anywhere...

The thing is, that in your example "scia_loopback_interrupts" you use the " |= " , while in some other examples (such like "Timed Led") you don't use the OR.

I think this is what led me to use the OR (the sci example), which I based my low-level driver on...

any way, I think it's important to document this behavior somewhere...

thanks

Ari.

Ari as Mitja explained,

The PieCtrlRegs.PIEACK.all |= 0x0000; is a Read Modify Write instructions so when you have or'ed the values you end up writing a one and thus clearing any flag that is set. 

However i would agree we need to be consistent in our examples and need to follow only one convention i.e. to just write and not do a Read Modify Write,

Sorry for the trouble,

Regards

Manish Bhardwaj

yes, of course it'll clear all... :)

by the way, regarding the Sensorless algorithm, I have some questions:

1. why aren't you writing to the shadow register of the pwm, but rather directly to the CMPA ? isn't it safer to write to the shadow (besides, I saw that in the init of the pwm you're enabling the shadow)

2. isn't it better to send SOCA when the PWM is high, in sense of accuracy  ? now it's sent when it's low.

3. i'm adding more interrupts to the project. In order to be precise on the control algorithm, I thought to do interrupt nesting (not to loose the timing of timer0). I wrote (for example in the SCI interrupt):

IER = 0x01; // enable only Timer0 interrupt

EINT; // to enable interrupts inside SCI interrupt

some code here...

PIEACK...

DINT;

is that ok for interrrupt nesting ?

4. I read that it's possible to have interrupts going even when the CPU is halted (real-time emulation).

obviously, this is very important for the motor-control, and without it's not possible to halt the software.

I've enabled timer0 in the DBGIER, and running the command ERTM. that should be enough I think.

then, in the CCS 3.3 I enable real-time.

but when stopping at a software break-point, the interrupt halts.

maybe I didn't understand the concept of real-time emulation, but shouldn't the timer0 be running ?

thanks a lot for your support and quick response,

Ari.

1. Once you enable shadow mode then any write to the CMPA register is shadowed, you still write to the CMPA register itself. The shadowing is in hardware.

2. The SOCA depends where you are sensing,for ACI and PSMSM motors we are sensing the leg currents and there is no leg current when the PWM is high so it makes sense. I would need to revisit this for BLDC as it only uses backemf sensing. I would get back on this one but the reason why it is the way it is for ACI and PMSM motor vector control.

3. I would refer you to the following wiki http://processors.wiki.ti.com/index.php/Interrupt_Nesting_on_C28x for more details on the nesting example

4. There is a good  video describing how to use real time mode and real time interrupt here:  http://processors.wiki.ti.com/index.php/Real-Time_Interrupts_with_CCSv4

there is full video describing it.

Regards

Manish Bhardwaj

Hi Manish,

I was thinking about the Sensorless implementation and have some questions:

1. Basically, what is the reason for implementing such a high frequency ISR ? since the ADC works at the frequency of the PWM, you'll have a couple of iterations on the TIMER0 that the samples do not change... I can a problem with that when starting to add more interrupts to the system (SCI,SPI, eCAP etc)

2. what is the reason for running the algorithm in the timer interrupt (which is not synchronized with the PWM, as far I understand) ? why not in an ADC interrupt, which is synchronized, and you'll run the algorithm as soon as the sample is ready (rather than polling at the timer interrupt) ?

3. regarding nested interrupt - I looked at the reference you supplied, but there they're only talking about interrupts from the same group... what happens If my interrupt comes from another group ?

4. further more, in the same example, there are two lines:

IER |= M_INT2;
IER &= MINT2;

just to understand - why can't I just write:

IER = M_INT2 ?

for my case I would like to have interrupts from group 1, so the line should be:

IER = M_INT1 ?

5. In the same example, I saw that the PIEACK is given for all groups:

PieCtrlRegs.PIEACK.all = 0xFFFF;

wouldn't this line make a mess with other interrupts (from other groups) ? what is the reason for ACK all groups ?

6. from my understanding the ADC should start when the PWM is high (so the MOSFETs or IGBTs conduct), thus the current flows through them... In the sensorless we're sampling the non-conductive phase so maybe it's really not important when the sampling starts.

thanks a lot,

Ari.

Ari,

The nested interrupts example found here controlSUITE\device_support\f2803x\v122\DSP2803x_examples_ccsv4\sw_prioritized_interrupts

completely configures the SW Defined priorities, The example serves as a reference framework that can be used for SW Prioritization of interrupts, the header file found at 

controlSUITE\device_support\f2803x\v122\DSP2803x_common\include\DSP2803x_SWPrioritizedIsrLevels.h

lets user define any type of priority, the way this is done is that mask values are generated at compile time based on the header file values, and these masks are used in the framework so that the user does not have to worry about the masks etc. The document can be found at

controlSUITE\device_support\f2803x\v122\doc\Example_ISRPriorities.pdf

The reasoning behind writing as compared to read modify write is the way these masks are generated, the way these masks are generate is beyond the cope of the discussion of the forum, I would recommend using the framework.

The reason why acknowledging all the groups is necessary is for the SW prioritization to take effect, consider this there are 2 interrupts EPMW1_INT and ECAP1_INT, now the EPWM1_INT has higher priority than ECAP1_INT by hardware prioritization, let;s say you want to change this and EPWM2_INT has to have higher priority, 

An ECAP1_INT comes and the ISR would jump to the service routine, in the ISR the first few tasks are to set the SW interrupt prioritization, Now let's assume  before these prioritization tasks finish  EPWM1_INT also comes, this would set the appropriate bit in the PIER register. Now if the group 4 bit is not acknowledged as soon as the interrupts are enabled again the CPU would jump to EPWM1_INT ISR because of hardware prioritization and software prioritization would fail.

Thus to prevent these boundary cases we need to acknowledge all, Note no interrupts are lost because the PIEIFRx flag would still be set for unserviced routine and as soon as the PIEIERRx bit would be set and the CPU can jump to the interrupt,

Hope this explains the reasoning behind the example,

-Manish

Hi Manish,

thanks a lot, your explanation cleared all doubts.

so, correct me now if i'm wrong:

in the sensorless algorithm, the only thing that interests me is that the timer0 interrupt will not be delayed by other interrupts.

IF there are no more interrupts from group 1, so group prioritization doesn't interest me.

so in order to jump to timer0 interrupt from other interrupts (and assuming they are from other groups, lower ones), the only thing i need to write in those interrupts is:

    IER |= M_INT1;
    IER &= MINT1;                      // Set "global" priority
    EINT;

in this above case I DO NOT need to ACK the PIE. is that correct ?

besides that, in order to allow the sensorless algorithm to continue running even when halting the CPU (real-time mode), I thought that I need to enable this emulation in the following registers (set to FREE running):

PWM register

ADC register

TIMER0 register

is there something else that you can think of in order to have the algorithm running while halting ?

by the way, I thought about moving the whole algorithm to ADC interrupt instead of the TIMER.

there are 2 reasons:

1. process the results as soon as they're available - maintain synchronization.

2. I don't see any reason why to work faster than the PWM frequency - especially if using the shadow register - changing the CMPA twice a cycle has no logic...

3. there could be a problem if an application requires a very high frequency of PWM (let's say, 100KHz) - need to think about this case, even though the SOCA can be configured to happen only at the third or fourth cycle...

what do you think ?

thanks a lot

Ari

Ari,

The pieack handles both inter and intra group prioritization, the framework is provided to take everything into account, I would still recommend doing it.

For real time interrupts you have to enable the bits as well for the real time interrupt as illustrated in the video i pointed to earlier,

I agree moving to ADCINT or PWMINT makes sense, i would need to revisit the points you have mentioned with respect to BLDC code.

Regards

Manish Bhardwaj

Hi Manish,

thanks for your quick replies.

I will appreciate your comments on the BLDC implementation (regarding also previous issues i pointed out - sampling point etc)

I have encountered another problem though - I wrote a PC program that communicates through RS-232.

My problem is that the USB-SERIAL interface doesn't work ! I've tried using it on the ControlCard also, but couldn't send data TO the MCU from the PC. I did notice that sending from the MCU to the PC works well... the problem is that on HV-kit there are no header pins for the GPIO28-29 (SCI)...

can you please advise ?

I did a search through the forum and found some threads from 2009 regarding the upload of new software to the EEPROM of the FTDI device...do you know if that works ?

does anyone manage to communicate through the USB-SERIAL line ?

thanks a lot

Ari.