Motor Control Libary on STM32F107 CL device

luke23 · ‎2014-03-28

Posted on March 28, 2014 at 11:35

Hi

I am running the Motor Control library 3.4.1 on the STM32F107xC.

It keeps crashing into the 'Hardware Fault' exception.

I have made the necessary adjustments to the IAR project build, and had to adjust some defines in the library to extend the build configuration past the STM32F10X_HD.

Is there some basal reason that the library is not documented to run on the F107 device?

Or, what could be throwing the hardware exception?

Thanks

Luke

#cl-device-motor-control-library

luke23 · ‎2014-03-28

Posted on March 28, 2014 at 20:45

To be a little more explicit with the above question, my MC implementation on the STM32F107xC connectivity line device is for:

- single motor

- encoder or 3x hall effect.

The implementation crashes during the call to:

MCboot(oMCI,oMCT); // :(

I notice, for example, that the MC Library uses TIM8, but the CL device has only a TIM1 - is this something fundamental which prevents the library from operating on this device? Or can it be overcome by assigning another timer to the TIM8 functions?

Thanks

luke23 · ‎2014-03-30

Posted on March 31, 2014 at 02:15

In adjusting the library configuration for the CL device I neglected to adjust the startup code for the specific crystal on my board. Now that I've adjusted the clock config code for my 8MHz crystal on my CL device - the provided library code assumes a 25MHz crystal - the crashing has stopped.

Now I have comms up with the MCWB software.

Just working through why it's reporting 'overcurrent' when the motor is not running now. I have slightly different gain circuits from the MB459 kit, but have adjusted accordingly in the MCWB setup.

Although I'm not 100% sure it's handling the op-amp analog processing right. The #defines which are sent through into the source code, while including information about the gain, doesn't seem to include information about the 'zero' level.

#define RSHUNT 0.220

#define AMPLIFICATION_GAIN 2.12

... seem to be the only #defines going into to code; so I assume that the library auto-magically adjusts for current 'zero' (the single-ended op-amp front-end biasing) by self calibrating when it knows there is no motor current flowing (at MCBoot() time?) - is this the case?

Any ideas?

luke23 · ‎2014-03-30

Posted on March 31, 2014 at 08:48

It seems that the library does perform it's own zero-current calibration, which is excellent - so the MCWB is passing enough analog current signal processing to the library.

Over-current. I am confused on this. It seems that some consistency in nomenclature is required, along with increased pertinence of terms.

Apparently 'Emergency Stop' is equivalent to 'Brake' input is equivalent to 'over current.'

But I'm not sure where the MCWB control for this is.

There are suspicious-looking settings under 'Power Stage - Over-current protection,' and then 'Over-current protection disabling network.'

Which, if this is true, this is ==> 4 names for the same thing !!!! <===

Then, again, just for fun this time, under 'Control Stage' and Over-Current Protection Topology, 'External Protection' or 'No protection' can be selected.

So I selected 'No protection' and now the over-current warning is gone, since my application uses PE15 (not re-assignable in the MCWB) for another purpose.

Gigi · ‎2014-03-31

Posted on March 31, 2014 at 11:36

Ciao Luke,

yes, the lib performs the offset calibration at each restart of the motor,

and yes, there is a little bit redundancy in the nomenclature: Over current, Brake Input and Emergency stop are equivalent.

The 'Over-current protection disabling network' has different meaning and is a network to allows to disable temporary the over current protection to have the possibility to work with an ''extra'' current.

If you don't have the Emergency Input/Over current/Brake input/PE15 pin available the only think is to disable the protection as you did... and then cross the finger.

Ciao

Gigi