Trinamic have drivers that use different communication protocols. The ones most used are SPI and UART.

The TMC2300 supports UART. It's used to set the behaviour of the driver, query settings and give commands.

Understanding the commands isn't very difficult. They are well described and their IDE helps to look at what get sends to the device when you perform an action.

Let's have a look at how to interpret and use the UART interface, and at some real signals.

Using UART in a Real Design

When you're using the Trinamic IC in your own design, you wouldn't use the Landungsbrücke to talk to it. The translation from the desired action to UART streams is done in your firmware.

There are a few things to review when doing this:

• Speed: you can run between 9600 and 155200 baud. The TMC2300 adapts to the frequency used by the host. It adapts at each communication.
  If there's no activity for more than 63 expected bits in a communication, the IC cancels that communication.
• Integrity: the protocol uses CRC to validate the communication, both directions. This is very useful in longer distance wiring.
  If your design doesn't need it and you know the commands you'll send to the device up front, you can pre-calculate the CRC value for all the commands you'll send, and ignore the CRC on the receiving side.
  The CRC control value is added as the last byte in any communication sequence (datagram).
  More on the CRC algorithm later.
• Sync: The first byte is a sync signal. The first 4 bits are the fixed sequence nibble 1010b. Then there's 4 bits that aren't used - but you have to include them in your CRC byte.

Address:  the second byte is the address of the TMC2300 for ommunication to the device. This address is set via two address pins. You can set this in your PCB design or via the GPIO of your master controller.
When talking to the IC over UART, the address is defined by the 2 most significant bits. When the TMC2300 responds, this addres is 0xFF always.



image source: Trinamic's datasheet, edited

• Register address: The next byte is the register address that's read or written. You set the last bit of the address high for a write request, 0 for a read request.
• Sequence start and end: the UART has to be high when not communicating. The first falling edge is the trigger for the communication to start. At the end of communication the line has to be high again.
• Datagrams: consists of all the above and, in case of write and read respond, also a 32 bit value that will be written in the register.
• Communication counter: For read commands, you can check yourself if the reply has arrivd and the CRC matches. For write commands, an internal register is incremented for each successful call and you can check that.
• SIngle pin UART: the TMC2300 uses a single pin for UART in/out. An external resistor network to split it up in Rx and Tx signals for your controller.

A typical write communication looks like this:

A read and reply:

image source: both from Trinamic's datasheet

Capture UART exchanges with the Evaluation Kit

There are two ways to capture the traffic: by reading the IDE's history log or by connecting a protocol analyser to the Eselsbrücke (the OCB in the evaluation kit that exposes the signals).

Both give insight in what's happening. It's not straightforward though, in both cases.

It would be nice if I was able to set up a configuration and a motor action, then see that in the log window or on the logic analyser. Without anything else happening.

But the IDE shoots so many messages over that UART constantly (even with no display window open, it queries the device multiple times per second), that it's difficult to isolate the relevant ones.

View UART via the History Log

All communications that you send from the evaluation logic to the device can be shown. Both the Trinamic's TMLC commands and the UART raw data.

I've set the filter actions in the log as restrictive as possible, so that (almost) only commands generated by my actions are shown.

You see the communication in the black window. Left side is the commands generated in the IDE. Middle the datagrams flowing over UART, right the value written or read.

If we look at the two last signals, these are write commands. The SAP command sets the motor to a target acceleration of 100000 pps², and the ROR line lets it rotate right at 1500 pps.

The first two GAP lines are read requests to get the current set acceleration from the TMC2300.

Exercise for the reader: try to translate these lines into write, read and answer datagrams.

View UART via a Logic Analyser

You can tap the Tx and Rx lines from the Eselsbrücke  DIO10 and DIO11 test points.

source: Trinamic's evaluation kit schematic, edited

The TMC2300 uses single wire UART (see below for the implementation of that). A perfect choice but it makes my exercise difficult.

If you have a real logic analyser (I am using an FPGA development board as protocol analyser here), and you have control over the logic level thresholds, you will be able to log the Rx and Tx signals seperately.

Because my analyser has a limited analog input section, it can't natively work with the split signals. Therefore you'll see that Rx and Tx show the same information.

It's actually not an issue once you understand the datagrams. You can use just one signal and derive the direction of the traffic from that. There's no overlap between Tx and Rx, so no conflicts.

at the time I took this capture, I didn't yet understand that Trinamic's protocol is Most Significant Bit First

What makes it more difficult to deploy a logic analyser as a tool to help understand the communication, is the amount of traffic the IDE generates.

It's very chatty, sending and requesting info constantly.

That makes it difficult to capture the sequence between starting a slow ramp, reaching the desired speed and ramping down.

Again, having an analyser with better filtering and triggering on serial data values may help. But it would be good if you could tell the IDE to shut up for a while, except for the commands needed to complete an exercise.

Single Wire UART

As mentioned before, the TMC2300 uses a single pin for UART in/out. An external resistor network to split* it up in Rx and Tx signals for your controller.It works perfectly with UART modules that respect the signal levels.

source: Trinamic's evaluation kit schematic, edited

R306 and R311 take care that signals accidently sent from the TMS2300  and host at the same time can't harm each other.

The UART on your host controller shouldn't be listening anyways while it is sending. The UART protocol isn't synchronous.

That UART module should support open drain for the Tx signal. Else the TMC3200 would need to fight the 1K resistor.

This is how the Trinamic Landungsbrücke sets the UART pins:

HAL.IOs->pins->DIO10.configuration.GPIO_Mode  = GPIO_Mode_AF3;  // TxD (DIO10)
HAL.IOs->pins->DIO11.configuration.GPIO_Mode  = GPIO_Mode_AF3;  // RxD (DIO11)
HAL.IOs->pins->DIO10.configuration.GPIO_OType = GPIO_OType_OD;  // TxD as open drain output
HAL.IOs->pins->DIO11.configuration.GPIO_PuPd  = GPIO_PuPd_UP;   // RxD with pull-up resistor

Code source: Trinamic's github pages

I hope you enjoyed this first little view on the TMC2300 and its command engine.