Can you turn off Pipeline in ARM Cortex M3

On Tue, 08 Sep 2015 22:13:49 +0300, Dimiter_Popoff wrote:

> On 08.9.2015 г. 20:55, Tim Wescott wrote:
>> On Tue, 08 Sep 2015 19:48:19 +0200, David Brown wrote:
>>.....
>>> For modern embedded PPC cores (such as Freescale's MPC5xxx families,
>>> using the z6 core), the EIEIO instruction has been replaced by the
>>> depressingly boring MBAR opcode.  It's a great step backward, in my
>>> opinion.
>>
>> Man, you go to sleep for JUST ONE DECADE and they go and change things!
>>
>> I just want to know if that mnemonic was intentional -- I know it would
>> have been if I'd been on the team and had enough influence.
>>
>>
> Oh I suspect it has been intentional - the guy who did the power
> architecture has been too good to not have a sense of humour.
> The mnemonics overall are no good (few of them have made it into my vpa,
> mostly those which are cpu unique) but this one just can't have come by
> chance :-).
> 
> On the OP issue - trying to do timing in the nS range using the
> processor load/store is no good. Two output compare (OC) timer outputs
> will do what is needed, there should be plenty of these on any mcu
> nowadays (???).

If I read it right the OP is using two output compares per half bridge, 
but he is concerned about a compare happening at just the wrong moment 
and having insufficient dead time.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On Tuesday, September 8, 2015 at 7:23:57 PM UTC+2, Tim Wescott wrote:
> On Tue, 08 Sep 2015 05:43:15 -0700, Klaus Kragelund wrote:
> 
> > Hi
> > 
> > I am not an embedded expert, so please be patient
> > 
> > I have an application with 6 phase PWM and the CC2650 TI processor does
> > not have deadtime support (to avoid cross conduction in a 3 stage
> > halfbridge design)
> > 
> > So, I could code this so when the timer PWM compare capture is updated,
> > I check the value that is needed to setup and adjust both the lowside
> > and highside compare values.
> > 
> > That requires IF statement, and no control of where the program might
> > continue in flash and thus the 3 stage pipeline in the Cortex M3 must be
> > flushed
> > 
> > A colleague said it would require a lot of code to do that. But, is it
> > possible to disable the pipeline all together, so there will be no
> > flushes and time used for this check is determined by the clock
> > frequency directly? (no optimization from the pipeline)
> 
> I'm pretty sure that your concern is that as you change the duty cycle 
> you may update one capture compare (I'm gonna call it 'CC') value in a 
> way that causes both transistors to be on at the same time, then have the 
> timer fire off, then update the other one -- yes?  What, I ask, is a bit 
> of noxious smoke between friends?
> 

You are correct, the objective is to use the microcontroller without the crossconduction and resulting smoke.

The PWM frequency is above 10kHz, and the update of the compare capture can happen almost at that frequency, so for worst case I define that at 10kHz

We need deadtime for sure, I am just trying to see if I can avoid using external circuitry to blank simultaneous LS and HS active signals.

The processor is running at 48MHz and most instructions are executed in less than 2 clock cycles. So something like 40ns max per instruction. So lets say I have a control loop that updates the compare values at 10kHz (100us period). I could add an interrupt to trigger at the compare value and handle the deadtime in raw code (or for long deadtime, initiate a timer to set the time). Even if this code would take 10-20 cycles, it's still less than 1us, so 1% of the period. I may be able to tolerate this since this is not an high end product

Still, using 20 cents for deadtime circuit begins to sound like a needed option. The above constrution is not clean and will cause jitter in the PWM duty cycle due to issues when transitions overlap


> My first urge is to change the hardware.  This situation should not have 
> been allowed to develop in the first place -- either someone should have 
> used a processor with dead time control, or they should have used gate 
> drive circuitry with dead time control (there are scads of ways to do 
> this in hardware-only), or they should have made damned sure that they 
> knew how to make it work in software.
> 
> If you have any influence over the hardware at all, I would start by 
> checking the schematic -- if you're lucky, someone used a gate driver 
> with dead-time control, meaning you can just add the appropriate 
> capacitor and you're done.  Or someone may have put in the older-style 
> diode-and-resistor network that accomplishes the same thing.
> 

I have control over the HW, but need to save every cent possible

> If all of that failed, I would check to see if the processor buffers the 
> CC numbers -- some companies design their PWM peripherals so that the 
> command registers are buffered and are only written at a specific point 
> in the PWM cycle.  If you interrupt on this point, and always manage to 
> write the command values well within one PWM interval, then all you need 
> to do is make sure to write the correct values.
> 

As far as I can see, it does not. I would prefer center aligned PWM, and it does not support that, so I need to make adjustments to get that working too

I am seriously contemplating a semi SW PWM, a function that checks the compare values and triggering a timer that when runs out triggers the relevant output. That way I have 100% control of the PWM outputs, but it would take a lot of computing power, but I do not care about that

One could perhaps even setup the DMA trigger, so on the run-out of the timer, the relevant output is set directly by the DMA

> Failing all else, I would monitor the direction that the PWM is going, 
> and always write the CC commands in such an order that during the 
> interval that one register has been written and the other hasn't, the 
> dead time is increased rather than made overlapping.  This may cause the 
> occasional inefficient operation and some strange EMI issues, but at 
> least it won't let out the magic smoke.  As long as your CC registers are 
> declared volatile and your hardware doesn't do anything funny then you 
> should be OK.
> 
> If you are concerned that the pipeline may disorder your ordered memory 
> writes, the ARM has an instruction to flush the pipeline before 
> proceeding (I'm pretty sure that it's absolutely unnecessary in your case 
> -- but if you're feeling paranoid it's there.)  If you were using a 
> PowerPC processor then I could recommend the EIEIO instruction which has 
> my FAVORITE MNEMONIC EVER, but you're not, so you'll have to live with 
> whatever stogy British mnemonic goes with the ARM stuff.

The pipeline question was to quantify if the flushing of it would cause a hickup/stall of the code, but I guess not. Disabling the pipeline would make the code more determistic

Cheers

Klaus

On Tuesday, September 8, 2015 at 7:05:56 PM UTC+2, rickman wrote:
> On 9/8/2015 8:43 AM, Klaus Kragelund wrote:
> > Hi
> >
> > I am not an embedded expert, so please be patient
> >
> > I have an application with 6 phase PWM and the CC2650 TI processor
> > does not have deadtime support (to avoid cross conduction in a 3
> > stage halfbridge design)
> >
> > So, I could code this so when the timer PWM compare capture is
> > updated, I check the value that is needed to setup and adjust both
> > the lowside and highside compare values.
> >
> > That requires IF statement, and no control of where the program might
> > continue in flash and thus the 3 stage pipeline in the Cortex M3 must
> > be flushed
> 
> I don't know the details of the Cortex line, but most processors assume 
> the processing will continue in sequence and if the branch is taken the 
> pipeline is flushed.  So this is entirely predictable if you know which 
> way the code branches.  You have not indicated exactly what the concern 
> is.  Whatever your issue with the pipeline is, I doubt you really need 
> to "turn it off" which would slow your code to as little as 1/3.
> 

Thanks. I looked deeper into the Cortex M3. It has a 3 level pipeline, and you are right the code will be predictable. I just need to take into account that I cannot count on the performance boost that the pipeline offers in all cases

Cheers

Klaus

On Tuesday, September 8, 2015 at 2:43:23 PM UTC+2, Klaus Kragelund wrote:
> Hi
> 
> I am not an embedded expert, so please be patient
> 
> I have an application with 6 phase PWM and the CC2650 TI processor does not have deadtime support (to avoid cross conduction in a 3 stage halfbridge design)
> 
> So, I could code this so when the timer PWM compare capture is updated, I check the value that is needed to setup and adjust both the lowside and highside compare values.
> 
> That requires IF statement, and no control of where the program might continue in flash and thus the 3 stage pipeline in the Cortex M3 must be flushed
> 
> A colleague said it would require a lot of code to do that. But, is it possible to disable the pipeline all together, so there will be no flushes and time used for this check is determined by the clock frequency directly? (no optimization from the pipeline) 
> 

I may have an option to add the Silicon Labs Busy bee:

http://www.silabs.com/Support%20Documents/TechnicalDocs/EFM8BB1_DataSheet.pdf

Pricing seems to be at 0.2USD in high volume negotiated etc, and it has center aligned PWM. In addition a kill signal from a comparator, so if a cross conduction ever occur, we can respond before the current is too high

Really a nice part :-)

Cheers

Klaus

On Tue, 08 Sep 2015 14:18:34 -0700, Klaus Kragelund wrote:

> On Tuesday, September 8, 2015 at 2:43:23 PM UTC+2, Klaus Kragelund
> wrote:
>> Hi
>> 
>> I am not an embedded expert, so please be patient
>> 
>> I have an application with 6 phase PWM and the CC2650 TI processor does
>> not have deadtime support (to avoid cross conduction in a 3 stage
>> halfbridge design)
>> 
>> So, I could code this so when the timer PWM compare capture is updated,
>> I check the value that is needed to setup and adjust both the lowside
>> and highside compare values.
>> 
>> That requires IF statement, and no control of where the program might
>> continue in flash and thus the 3 stage pipeline in the Cortex M3 must
>> be flushed
>> 
>> A colleague said it would require a lot of code to do that. But, is it
>> possible to disable the pipeline all together, so there will be no
>> flushes and time used for this check is determined by the clock
>> frequency directly? (no optimization from the pipeline)
>> 
>> 
> I may have an option to add the Silicon Labs Busy bee:
> 
> http://www.silabs.com/Support%20Documents/TechnicalDocs/
EFM8BB1_DataSheet.pdf
> 
> Pricing seems to be at 0.2USD in high volume negotiated etc, and it has
> center aligned PWM. In addition a kill signal from a comparator, so if a
> cross conduction ever occur, we can respond before the current is too
> high

For the most part, a comparator is good for limiting the duty cycle if a 
motor stalls, but if you're cross-conducting it will, at best, deliver 
the suicide note.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On Tuesday, September 8, 2015 at 11:25:55 PM UTC+2, Tim Wescott wrote:
> On Tue, 08 Sep 2015 14:18:34 -0700, Klaus Kragelund wrote:
> 
> > On Tuesday, September 8, 2015 at 2:43:23 PM UTC+2, Klaus Kragelund
> > wrote:
> >> Hi
> >> 
> >> I am not an embedded expert, so please be patient
> >> 
> >> I have an application with 6 phase PWM and the CC2650 TI processor does
> >> not have deadtime support (to avoid cross conduction in a 3 stage
> >> halfbridge design)
> >> 
> >> So, I could code this so when the timer PWM compare capture is updated,
> >> I check the value that is needed to setup and adjust both the lowside
> >> and highside compare values.
> >> 
> >> That requires IF statement, and no control of where the program might
> >> continue in flash and thus the 3 stage pipeline in the Cortex M3 must
> >> be flushed
> >> 
> >> A colleague said it would require a lot of code to do that. But, is it
> >> possible to disable the pipeline all together, so there will be no
> >> flushes and time used for this check is determined by the clock
> >> frequency directly? (no optimization from the pipeline)
> >> 
> >> 
> > I may have an option to add the Silicon Labs Busy bee:
> > 
> > http://www.silabs.com/Support%20Documents/TechnicalDocs/
> EFM8BB1_DataSheet.pdf
> > 
> > Pricing seems to be at 0.2USD in high volume negotiated etc, and it has
> > center aligned PWM. In addition a kill signal from a comparator, so if a
> > cross conduction ever occur, we can respond before the current is too
> > high
> 
> For the most part, a comparator is good for limiting the duty cycle if a 
> motor stalls, but if you're cross-conducting it will, at best, deliver 
> the suicide note.
> 

We use this technique routinely. The low side transistors does not refer to ground directly, but through a resistor. All though the current rises fast, we can sustain crossconduction. For worse cases, you can get gatedrivers that has the feature inherent (measures conduction voltage)

Cheers

Klaus

Den tirsdag den 8. september 2015 kl. 23.18.38 UTC+2 skrev Klaus Kragelund:
> On Tuesday, September 8, 2015 at 2:43:23 PM UTC+2, Klaus Kragelund wrote:
> > Hi
> > 
> > I am not an embedded expert, so please be patient
> > 
> > I have an application with 6 phase PWM and the CC2650 TI processor does not have deadtime support (to avoid cross conduction in a 3 stage halfbridge design)
> > 
> > So, I could code this so when the timer PWM compare capture is updated, I check the value that is needed to setup and adjust both the lowside and highside compare values.
> > 
> > That requires IF statement, and no control of where the program might continue in flash and thus the 3 stage pipeline in the Cortex M3 must be flushed
> > 
> > A colleague said it would require a lot of code to do that. But, is it possible to disable the pipeline all together, so there will be no flushes and time used for this check is determined by the clock frequency directly? (no optimization from the pipeline) 
> > 
> 
> I may have an option to add the Silicon Labs Busy bee:
> 
> http://www.silabs.com/Support%20Documents/TechnicalDocs/EFM8BB1_DataSheet.pdf
> 
> Pricing seems to be at 0.2USD in high volume negotiated etc, and it has center aligned PWM. In addition a kill signal from a comparator, so if a cross conduction ever occur, we can respond before the current is too high
> 


how about stm32f100?, afaict it has timers specifically for doing 3 complementary pwms with dead time and break

-Lasse

Den tirsdag den 8. september 2015 kl. 23.52.34 UTC+2 skrev Klaus Kragelund:
> On Tuesday, September 8, 2015 at 11:25:55 PM UTC+2, Tim Wescott wrote:
> > On Tue, 08 Sep 2015 14:18:34 -0700, Klaus Kragelund wrote:
> > 
> > > On Tuesday, September 8, 2015 at 2:43:23 PM UTC+2, Klaus Kragelund
> > > wrote:
> > >> Hi
> > >> 
> > >> I am not an embedded expert, so please be patient
> > >> 
> > >> I have an application with 6 phase PWM and the CC2650 TI processor does
> > >> not have deadtime support (to avoid cross conduction in a 3 stage
> > >> halfbridge design)
> > >> 
> > >> So, I could code this so when the timer PWM compare capture is updated,
> > >> I check the value that is needed to setup and adjust both the lowside
> > >> and highside compare values.
> > >> 
> > >> That requires IF statement, and no control of where the program might
> > >> continue in flash and thus the 3 stage pipeline in the Cortex M3 must
> > >> be flushed
> > >> 
> > >> A colleague said it would require a lot of code to do that. But, is it
> > >> possible to disable the pipeline all together, so there will be no
> > >> flushes and time used for this check is determined by the clock
> > >> frequency directly? (no optimization from the pipeline)
> > >> 
> > >> 
> > > I may have an option to add the Silicon Labs Busy bee:
> > > 
> > > http://www.silabs.com/Support%20Documents/TechnicalDocs/
> > EFM8BB1_DataSheet.pdf
> > > 
> > > Pricing seems to be at 0.2USD in high volume negotiated etc, and it has
> > > center aligned PWM. In addition a kill signal from a comparator, so if a
> > > cross conduction ever occur, we can respond before the current is too
> > > high
> > 
> > For the most part, a comparator is good for limiting the duty cycle if a 
> > motor stalls, but if you're cross-conducting it will, at best, deliver 
> > the suicide note.
> > 
> 
> We use this technique routinely. The low side transistors does not refer to ground directly, but through a resistor. All though the current rises fast, we can sustain crossconduction. For worse cases, you can get gatedrivers that has the feature inherent (measures conduction voltage)
> 
> Cheers
> 
> Klaus


the circuit used with an IR2171 is quite nifty, 

http://www.irf.com/product-info/datasheets/data/ir2127.pdf

if the gate is high and the Vce/Vds isn't low there is trouble

-Lasse

As far as I can tell the cheapest STM32F100 is double the price of the EFM8B

They are nice parts though, used them before :-) 

Cheers 

Klaus 

Den onsdag den 9. september 2015 kl. 00.34.22 UTC+2 skrev Klaus Kragelund:
> As far as I can tell the cheapest STM32F100 is double the price of the EFM8B
> 
> They are nice parts though, used them before :-) 
> 

ST says ~$1.3@10k , TI say ~$4@1k for the cc2650

-Lasse