Can you turn off Pipeline in ARM Cortex M3

If I understand you correctly, what you are trying to get here is cycle-accurate deterministic instruction counts for a series of instructions - i.e., you want to be sure of /exactly/ how long those instructions will take, in order to make exactly the right changes to your lowside and highside values.

If that is true, then the pipeline in the cpu is only one relatively minor issue - there are many more factors that can affect exact timing. Some factors can be eliminated or reduced (depending on the details of the chip), but not all.

Putting it bluntly, you don't have that sort of control - and if you think you need it, you've got a poor design (of hardware or software). Take a step back and look at what you are really trying to do, and if you have the right approach.

If you conclude that you /do/ need accurate timing, but not necessarily cycle accurate, then there are various possibilities to deal with that. Disabling the cpu's pipeline is not one of those possibilities. Post some rough code, and perhaps someone can give you some ideas. (Also note what compiler you are using, as this sort of stuff can be compiler-dependent.)

There is, of course, a significant difference between predictability, repeatability and worst-case behaviour. I have no idea whether the OP was thinking of that.

If you want the compiler to predict the number of cycles required, then the only processor/compiler that I know can do that is the XMOS series. Multicore variants are surprisingly cheap at digikey. Next time I have a hard real-time control-loop, I'll look at them very seriously.

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.

You haven't given much info to go on. The ARM instruction set also includes conditional instructions which are always fetched in line, but only executed if the appropriate flag is set vs. clear. I believe the timing is always the same for those. If you code in assembly I expect you can find a suitable set of code to meet your needs whatever they may be.

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?

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.

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.

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.

Absolutely - and once the OP has thought about the real issues and what he actually needs, we can suggest ideas to implement it.

I have used XMOS devices a little, a few years ago. They are definitely an interesting architecture (my boss always worries when a developer describes a chip or a project as "interesting" :-). The development tools were a bit problematic at that time, and their example code was a bit of a mess, but I believe things have improved since then. I would enjoy doing another project with them. Just beware that they have quite limited memory that is needed for both program and data - although XMOS are keen on doing both USB and Ethernet in software, the chips don't have enough RAM to do much with such interfaces.

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 (???).

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

------------------------------------------------------

It would help if he told us his goal or problem, not his solution. 'Twas ever thus.

:)

Just so. But I'll take the stance that a hard real-time kernel should be small, and that usb/ethernet should be out of that loop.

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.

You are correct, the objective is to use the microcontroller without the cr ossconduction 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 ext ernal circuitry to blank simultaneous LS and HS active signals.

The processor is running at 48MHz and most instructions are executed in les s 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 p eriod). 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 th e time). Even if this code would take 10-20 cycles, it's still less than 1u s, 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 op tion. The above constrution is not clean and will cause jitter in the PWM d uty cycle due to issues when transitions overlap

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

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 t oo

I am seriously contemplating a semi SW PWM, a function that checks the comp are 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 time r, the relevant output is set directly by the DMA

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

Cheers

Klaus

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

ot have deadtime support (to avoid cross conduction in a 3 stage halfbridge design)

check the value that is needed to setup and adjust both the lowside and hi ghside compare values.

tinue in flash and thus the 3 stage pipeline in the Cortex M3 must be flush ed

ssible to disable the pipeline all together, so there will be no flushes an d 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:

Pricing seems to be at 0.2USD in high volume negotiated etc, and it has cen ter 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

EFM8BB1_DataSheet.pdf

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

not have deadtime support (to avoid cross conduction in a 3 stage halfbrid ge design)

I check the value that is needed to setup and adjust both the lowside and highside compare values.

ontinue in flash and thus the 3 stage pipeline in the Cortex M3 must be flu shed

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)

.pdf

enter aligned PWM. In addition a kill signal from a comparator, so if a cro ss conduction ever occur, we can respond before the current is too high

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

-Lasse

oes

ed,

it

as

f a

to ground directly, but through a resistor. All though the current rises fa st, we can sustain crossconduction. For worse cases, you can get gatedriver s that has the feature inherent (measures conduction voltage)

the circuit used with an IR2171 is quite nifty,

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:

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

-Lasse