Trinamic TMC2300-IOT-REF Stepper Driver + Motor - Review

Table of contents

RoadTest: Trinamic TMC2300-IOT-REF Stepper Driver + Motor

Author: Workshopshed

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?: Comparable products include BA6845FS-E2 from ROHM, E-TEA3718DP from STMicroelectronics and the DRV8842PWP from Texas Instruments

What were the biggest problems encountered?: Overheating of the board, noise on the serial comms and a bad example code which had the wrong slave address (and the value was not labelled as the slave address).

Detailed Review:

The roadtest for the Trinamic-TMC2300-IOT-REF-Stepper-Driver-%20-Motor got off to a good start. The board was easy to programme as an ESP32 and I quickly got it blinking - TMC2300-IOT-REF - Remote controlled Stepper Motor - Getting to blink

However, when I moved over to getting the motor running TMC2300-IOT-REF - Remote controlled Stepper Motor - Getting your motor running then the problems started. Unknown to me the configuration for the motor current was not transmitted to the board and after struggling to get the board to communicate over UART my experiment with step and dir caused something on the board to overheat.  A lot of time was spent then trying to diagnose what was going on with the board.

Finally the board was made to communicate over serial and the motor speed and direction were controlled by setting the registers TMC2300-IOT-REF - Wrong address and write only registers


As a reference design I feel there are a few things missing. The top tip about holding reset to avoid problems when unplugging the battery should be right up there at the top of the manual. Also, the need to pull IO5 low is missing from the Blynk example code as the default behaviour would be to float the pin. Equally reading back the IFCNT register to validate that data was written should be in the example code. If this is an optional step the a comment should be included but it seems like best practice to do this step. Also missing in the documentation is an explanation of the comment "Periodically write to the chopper conf register". It is clear what the code is doing but no indication as why you would want to do that. There's no mention in the comprehensive manual as to needing to do that.


Despite several engineers more qualified than myself examining the combination of Q2 and R13 in the circuit it was not entirely clear what it was doing. So again a little documentation could help there. It is not clear at this time if the noise on the Uart signal is connected to my earlier failure or if that is something that needs to be factored into the design. For me what sets this chip apart from simpler drivers is that serial communications so it is critical that it is understood to be able to create a design around it.


Now that I am happy that my code was successfully communicating with the motor, I am fairly certain that the board has failed. The regulator/charger are still getting very hot even when not driving a load.  Again it would be good to know why that failed in the way it did before I would build any designs using this chip.


My demo code:


So in summary, a good little driver chip but let down by some minor code/documentation points and a catastrophic failure mode of the reference board.