RoadTest: Trinamic TMC2300 EVAL KIT (2-PH Stepper Motor)
Author: Jan Cumps
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: Smart stepper drivers (Texas Instruments DRV8711 Stepper Motor Pre-driver), full-bridge motor driver (STMicroElectronics L298P) and half-bridge with protection (Infineon BTN8982TA half-bridge driver ICs)
What were the biggest problems encountered?: The IDE sends commands to the TMC2300 continuously, making it difficult to use a UART protocol analyzer to find out what relevant commands are sent.
Detailed Review:
I'm road testing Trinamic TMC2300 EVAL KIT (2-PH Stepper Motor). It's their latest design that targets battery powered devices.
During my review I've posted additional support articles about specific details. You'll find these linked at the end of the report. Links to all referenced documents are provided at the bottom too. |
The purpose of this kit is to validate if a TMC2300 stepper motor driver is suitable in your design.
To help you with that, it comes with the software and hardware to test out use cases:
with source code on github) for low level (direct driver datagram) and high level (TMCL datagram) support *.
For this road test, they added a 3V 2-phase stepper motor with matching connector. This isn't part of the standard kit.
This IC is a 2-phase driver for a single stepper motor. Specifically designed for battery powered designs.
It contains both the power control part and a logic (smart) part to handle the motor activity.
How is it different from full-bridge ICs: it contains a logic part that will either transfer a pulse train into a motor movement or UART commands into a motor movement.
How is it different from basic stepper motor drivers: next to the configuration registers for power and profile management (that other drivers also have), it has an internal pulse generator and a number of intelligent motor management functions.
It operates with supplies between 2 and 11 V.
It handles 1.2 A RMS motor current.
The drive circuitry itself, in operation, consumes 7 mA.
For the driver disabled modes: in software diasabled mode, it consumes +- 4mA. In hardware disabled mode 1.5 mA.
In the lowest power mode, standby, the documented current is 50 nA.
1.8 V operation is possible but specific conditions apply.
2 A peak motor current.
Currents are cumulative for what's being used in both coils at the same time.
All figures are from the TMC2300 datasheet. Check it for the details - it contains a lot of useful info.
Two ways to control the motor:
Intelligence (note: the names for these functions are Trinamic specific):
These functions all work by sensing what's happening at the driver output. There's no motion feedback from the motor to the IC (some other offerings from Trinamic have encoder feedback options).
These features focus on use cases where you operate on low power (battery) and want to detect and react on stalling / blocking motor.
When you use the current settings and the intelligent functions with care, you can make operating designs that run low power, smooth, safely and (for a design without rotation feedback) reasonably precise.
My entire road test is based on using the UART mode, with the intelligent functions listed above.
Everything below describes operation in that mode.
The standalone STEP/DIR mode can be useful when moving from a legacy design.
When you put a few extra footprints for resistors and jumpers on your PCB you can switch between the two modes: making your design work first without touching the existing firmware. Then configure it into UART mode and adapt the firmare.
I wouldn't suggest this IC if you don't intend to use its UART interface in your final design. It's not intended to compete in the standard driver market and other ICs fill that particular gap better.
The driver has two main blocks: the logic part (everything left from the two full bridges) and the power section.
All feedback is handled by the StealthChop module.
The documentation is somewhat confusing here. The narrative says that StallGuard manages StealthChop, the image indicates that all feedback arrives at StealthChop.
My take is that StealthChop gets feedback and (in parallel with using it to manage smooth yet strong stepping) gives that info to StallGuard.
StallGuard then uses that info to control the motor for its stalling / blocking behaviour again via StealthChop.
Either that, or the terms are marketing gimmicks. The registers seem to indicate that they are seperate yet tightly coupled modules.
The power section is the simplest. These are two full bridges (implementation not documented). One per coil.
Both bridges have an inductor current measurement circuit that feeds back into above mentioned StealthChop.
External resistors are required to configure the measurement circuit. The value is dependent on the motor current envelope of your design.
The logic part is more complex. Next to the typical parts you find in a firmware configurable driver (addressing, registers, current profile configuration, status retrieval), there are the internal pulse generator and smart blocks.
All control signals and the communications arrive or depart on this side of the IC.
Virtually all settings are handled via the UART interface and the registers. This makes the interface concept (communication protocol) simple.
Don't get fooled though. Setting up all parameters to fit a specific motor, then controlling all behaviour and functions isn't fully straightforward. Many options. Much to read.
The IDE helps to get this right, together with a rather sophisticated spreadsheet that allows you to dial in register settings.
Best results - in particular when you want to optimise with the advanced modules - are achieved when you use the spreadsheet as a start, then use the IDE with your design wired up.
You can then physically see how the motor behaves, and what little tweaks in the parameters do to the movements, motor noise, tork and power use.
You don't need the spreadsheet to get started with the kit though. With the default profile that the IDE uses for the TMC2300 and a common little stepper, you can start using the kit right out of the box.
Power preservation may or may not be a thing in your case. Given that the IC is targeted for battery operated designs, it's worth investigating the options.
In articular if the device is always on and the motor freewheeling for the majority of the time, saving power during idle time is valuable.
When the device is running or holding the motor virtually all the time, the power used by the IC is in the noise and not worth optimising. But these type of applications are typically not fit for battery operation.
You can save power by disabling the power driver via a UART command. That brings the current consumption down form 7 to 4 mA. When you pull the Enable pin to ground, you'll get as low as 1.5 mA.
When you put the IC in standby (take away the Vvio supply), current can drop to 0.03 µA.
Be careful on the surrounding circuit. Surrounding components and passives can burn away more power than the IC.
On the Evaluation kit, for instance, R315 at the output of the logic level supply / enable / standby circuit consumes 0.33 µA.
And if you don't implement the digital output that serves the ~STBY as open collector, 0.33µA is consumed by R316.
The first isn't a big deal. 0.33 µA isn't that impacting when the ICs operating current is 7 mA.
If you are sloppy in your firmware design (as I was when coding my own firmware 
) and don't set GPIO that serves the ~STBY as open collector. you burn 0.33 µA while the IC uses 0.033 µA.
That's not Trinamic's design issue (it's not an issue, it's a watch-out), it's yours - but it indicates that low power involves more than the IC and more than the surrounding hardware.
Interaction with the IC from your firmware is with a limited number of signals:
Overall, Trinamic managed to build a reasonable simple hardware and software interface around this complex landscape.
The only exotic choice may be the single pin UART.
It works well ii the driving controller implements the UART logic levels correctly. But a pin saved on the IC requires 2 external resistors on the PCB.
Maybe that's a price to pay to have both UART and legacy STEP/DIR mode. Switching between those two modes takes two pins on the IC.
But the single pin UART works, so this is a detail remark.
Configuration for your motor specifications, PSU setup, required tork and speed is usually a difficult task. In particular if this isn't your core skill.
Trinamic provides a spreadsheet that can help you with a number of decisions.
You'll need the specifications of your motor an the requirements of your own design.
With those calculations, you can retrieve some key settings for registers and commands. They also help you to predict power envelope, heat profile and overall dissipation.
I found that the best way to understand all the settings and how the spreadsheet helps you, is by using the IDE and the sheet side by side. Rinse and repeat until you get it.
Reading Section 7 and 8 of the datasheet will definitely help too.
Like many device that combines power and logic, with fast pulsing signals in both domains, you need to carefully lay out a PCB.
The datasheet shows best practice and decoupling requirements. This is used by the evaluation kits that are available for the TMC2300. This one, the standalone TMC2300-BOB (tiny breakout-style PCB) and the funny Thermo-BOB.
The best value of this kit, in my opinion, is when you are at the start of a design and want to check if the IC is a match for your requirements.
That, and as a tool to learn developing for the driver and the Trinamic firmware libraries (see next section).
You can use the combination to validate if a particular motor will work good in your design. You can try swapping that motor with a cheaper / smaller one and see if it still operates within requirements.
In particular if you have a mechanical prototype of your end product available, with motor mounted, this is an intuitive setup.
| Check the Evaluation Kit and IDE Functionality link below for a deep dive. |
The IDE can be used to configure and maintain the kit's boards. The main functionality however is to configure the TMC2300 real time and entertain the stepper motor.
Basic highlights:
Advanced functions:
Overall a well-designed and easy to use IDE. If I could add one functionality, it would be a switch to disable all polling communication between IDE and Landungsbrücke.
This traffic is needed because the IDE shows statuses real time. But it is very frequent and very noisy.
Because these communications generate UART traffic from Landungsbrücke to TMC2300, it's hard to find back those parts of the communication that drive the motor behaviour or control a ramp.
Closing most of the windows reduces the traffic somewhat but it's still a lot with all feasible activity in the IDE shut down.
If you use a logic analyser to record the activity from enabling the driver, setting current, StallGuard and CoolStep parameters, then define execute a velocity ramp,
the relevant traffic is maybe a few % of all the captured UART communication. It's not the end of the world. It would help designers that want to use the IDE to prototype the motor setup though.
I've had a few instances where the IDE became instable, with windows not being reactive, graphs displaying incorrectly and the odd crash. In particular when using basic and advanced in a combination or during a single session.
Visually, the IDE is sober. Changing the layout and the active windows is something you learn by doing.
The register window and the TMCL/PC host window could use a review by a GUI usability designer. They work fine, but aren't intuitive.
The majority of the other windows are both well styled and intuitive. Overall, this is a very good IDE, more elaborate than what I've seen from competition.
The Trinamic libraries support two levels of control: low level via the TMC-API and higher level via the TMCL wrapper.
This one operates on the register level of the TMC2300 and uses the read and write datagrams* to set and get register values.
The libraries for the TMC2300 have just been released during the road test (thank you Lenard Heß).
They contain the register definitions, constants, macro definitions and an API to talk to this driver (and many other from the Trinamic portfolio.
| Check the C++ Custom Firmware links below to follow along with my TMC-API project. |
The API is not written for a particular host microcontroller.
There are hardware specific functions that you'll have to provide. In particular those related to UART, GPIO and (optionally) timer.
If you use an ST or Freescale controller, chances are that you can reuse a significant part of the hardware layer of the library in the next subsection.
If not you can always use these as guidelines for your own implementation.
It takes a while to understand what's written where, and what's used when. Studying the code helps. I learned more from trying to write my own firmware with the library.
It would be helpful if an application note would provide a known-working set of register and GPIO sequences as a starting point. It's doable. The kit works out of box with the sequence generated by the IDE/
When you want to program the TMC2300 with similar commands as used by the IDE, this library is your friend.
The name of the lib and the mix of contents is a bit odd. It seems to indicate that it's the firmware of the evaluation kit family (what it is) or that it started as glue logic firmware between IDE and kit (what it is),
and then evolved into that same glue logic with a set of very useful higher level APIs abstracted out.
The TMLC and StepDir APIs, if you implement them on your host microcontroller, will allow you to control the stepper motor with the same commands as used in the IDE.
Some examples:
In its current state, I'd use this library as a starting point. As a set of well written code and a good API granularity that you can copy / paste from.
To use the embedded APIs as a pluggable / scaleable unit on a microcontroller, an additional cycle of refactoring would be welcome: split the evaluation kit and IDE glue part from the reusable APIs.
The source code on GitHub is published with the very open MIT license.
Trinamic provides a set of host-side (PC side) examples.
They let you use the same commands as used by the IDE. There are examples for LabVIEW, C and C with Windows API. Each time using serial comms.
You can use these directly with the evaluation kit. If you want to use them from your custom project, you have to implement the TMCL layer in your firmware and have serial comm set up between the host PC and your design.
I haven't evaluated this option. But when you use the IDE, you see this level of integration in action in the log window or when you use the Datagram view.
The TMC2300 is a feature-rich driver.
The intelligent blocks in the hardware allow you to control motors on a relative high level.
This can make the firmware simpler and flexible. You can reuse tork-, movement-, power consumption-, noise- and stall-optimisation logic that's native available on chip.
These blocks are what make this chip stand out. I'd consider it a good candidate in a design if you plan to use those blocks.
The evaluation kit combined with the IDE are a rich toolset to investigate, prototype and learn stepper motor control.
The documentation set is extensive and reasonably understandable.
The publicly available source code is a good start point when you're writing your own design.
The high-level part could use some refinement to make it easier to reuse it as a library.
A simple "Hello, world!" C example would be a great addition.
Overall, the experience (my first with a Trinamic product) is enjoyable. Easy enough to get started fast. Rich enough to tweak the details.
The evaluation kit as a whole helps to bridge the whole cycle from fast start to complex scenario prototyping.
This was fun.
| Sources: |
|---|
All screen captures, photos, annotations and animations are my own. Tables, schematics and spec images (pure and/or edited) are from:
|
* low level uses TMC2300 specific datagrams from your firmware over UART. TMCL (Trinamic Motor Control Language) uses its own datagrams that are Trinamic specific but driver-IC independent.
Top Comments
Great report and blogs.
Nice test report Jan.
DAB
A good and detailed Review. It will certainly helpful for other to consider Trinamic products,