breakpoints and timers

lanchon · ‎2009-09-10

Posted on September 10, 2009 at 12:10

lanchon · ‎2011-05-17

Posted on May 17, 2011 at 12:34

hi all,

ST has a FOC motor control library available. it has a user manual that says:

''Caution: During a breakpoint, when using the JTAG interface for the firmware development, the motor control cell clock circuitry should always be disabled; if enabled, a permanent DC current may flow in the motor because the PWM outputs are enabled, which could cause permanent damage to the power stage and/or motor. A dedicated bit in the DBGMCU_SR register, the DBG_TIM1_STOP bit, must be set to 1 (see Figure 25). In the main.c module the DBG->CR |= DBG_TIM1_STOP; instruction performs the above described task.''

this seems to imply that the DBG_TIM1_STOP bit disables the outputs of TIM1. (''disabling the outputs'' would be understood here as setting the outputs in their user-configurable disabled states, as by clearing the TIM1_BDTR_MOE bit.) this would be very reasonable behavior for TIM1.

however, the user manual tells a different story:

''During a breakpoint, it is necessary to choose how the counter of timers and watchdog should behave:

-they can continue to count inside a breakpoint. This is usually required when a PWM is controlling a motor, for example.

-they can stop to count inside a breakpoint. This is required for watchdog purposes.''

''DBGMCU_CR:

Bits 13:10:

DBG_TIMx_STOP: Regular data. x=4..1

0: The clock of the involved Timer Counter is fed even if the core is halted.

1: The clock of the involved Timer counter is stopped when the core is halted.''

the ref manual says that setting the bit will freeze the counter, not that it will disable its outputs. this would be reasonable behavior for timers and counters other than TIM1, that don't have user-defined disabled states for their outputs (or don't have outputs at all).

so which is it? does DBG_TIM1_STOP stop the timer or disable the outputs or both?

note that if DBG_TIM1_STOP only stops the timer, the FOC library has a very serious and dangerous bug: if the timer is halted while a winding is electrified, the bus voltage will be directly applied to the winding without PWM, most likely with disastrous results.

the alternative (keeping the PWM going) is also dangerous if the rotor is spinning fast enough, but at least it won't fry everything at low speeds.

has anybody looked into this or should I contact support?

thanks!

jj · ‎2011-05-17

Posted on May 17, 2011 at 12:34

hi lanchon,

Your specifics are - as of yet - unexplored by me/team.

As a student of logic - perhaps I can still assist...

In your case - with actual Eval Bd. or other motor & hardware -

I believe THIS HW puts you at a DISADVANTAGE! (as you state -

you may fry both motor and output stage(s).)

Can't you experiment with ''simple resistive load'' in place of

the motor and employ a current-limited, lab-supply instead of

''normal'' hv/motor supply? Objective is to spare the motor and

hopefully minimize damage to output stages - while you experiment.

I'm hoping that the resistive load will not totally spoil your FOC

sensing - if it does suggest you employ the smallest, cheapest

motor in ''sacrificial'' mode.

Wish you success - again thanks for your great forum contributions.

jj · ‎2011-05-17

Posted on May 17, 2011 at 12:34

Hi lanchon - some more thoughts...

I don't have any working STM32 hardware now or I would try to

get some experimental results for you.

Sure you know this - when driving 3 phase motor we insert small

value, precision R in series with ea. phase ground - and feed this voltage

to a discrete comparator. Should the micro hang - or otherwise fail -

the comparator causes the PWM motor drive to be starved. With this

type of protection perhaps you would limit damage to your motor and/or

output stage. I wish I could help more...

lanchon · ‎2011-05-17

Posted on May 17, 2011 at 12:34

hi jj,

well for one thing, since I don't use debugging I don't care enough about this to go and test it myself. this is a certainly a doc error, may also be a FOC lib bug, and might also be an oversight in the design of TIM1.

me knowing this will not prevent others from breaking their electrical and/or mechanical setups. and a result posted here will only serve a postmortem analysis. the point is giving ST a chance to clarify this before it hurts customers, not fixing a problem of mine. my only concern with this is that I'm obsessive and, even though I'll never debug my code, I'd like to code as safely as possible and not to leave to others a timebomb planted in my code.

> we insert small value, precision R

I've got several current sensors, including a bus current sensors that triggers a break. but this trigger is unidirectional and in the bus, it won't protect if the currents are causing a breaking torque. plus a high breaking torque weakens the flux of the magnets and can potentially irreversibly damage them, even if not above the break trigger current. anyway people shouldn't trigger the overcurrent during normal development, it should be a safety net in case something else fails.

paulm · ‎2011-05-17

Posted on May 17, 2011 at 12:34

Hello

quote:

''the alternative (keeping the PWM going) is also dangerous if the rotor is spinning fast enough, but at least it won't fry everything at low speeds.''

I've read that You got a problem with your project, I'm not a professional programer but maby I can help in hardware. Are you constructing the hardware part also?

There is a Integrated Power Module for Appliance Motor Drives from International rectifier called IRAMX16UP60A (there are different types of IPM's-see IRF for more info). You will get an overheat safety control and + inserted dead time. It's a 3 phase brige with IGBT transistors.

Recent I've project a prototype circuit with brake as a protection of bus capasitators.

Check your inbox.

[ This message was edited by: paulm on 30-04-2008 19:25 ]

lanchon · ‎2011-05-17

Posted on May 17, 2011 at 12:34

I sent you mail to elektroda, didn't you get it?

paulm · ‎2011-05-17

Posted on May 17, 2011 at 12:34

I've got it thanks.

I've answered earlier but You didn't get My answer.

So just sent it for the second time.

stello · ‎2011-05-17

Posted on May 17, 2011 at 12:34

Please visit

http://www.st.com/mcu/forums-cat-6786-13.html

to have more information about TIM1 behavior in debug mode.

Regards

cagdasyet2 · ‎2011-05-17

Posted on May 17, 2011 at 12:34

This code seems fine, Tim 1 2 3 4 stops in debug mode while in break points.

int main(void)

{

#ifdef DEBUG

debug();

#endif

DBGMCU ->CR = 0x3C00; //Timerlar Debug Modda durur.

Thanks for your help.