|Product Performed to Expectations:||8|
|Specifications were sufficient to design with:||8|
|Demo Software was of good quality:||7|
|Product was easy to use:||6|
|Support materials were available:||6|
|The price to performance ratio was good:||10|
|TotalScore:||45 / 60|
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: https://github.com/Workshopshed/TMC2300-IOT-Roadtest
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.