Weird SPI Clock Signal on Teensey 4.1, Pin 13

C

c172jeff

Well-known member
The PCB I designed seems to work ok when I do not connect a 1 foot connector of ribbon cable that breaks out the SPI lines as well as some other signals. When testing with the cable, the SPI seems to fail in having good communication with the 5 chips on the PCB, the cable is unconnected to anything but the PCB at this point. It does not look like I can connect more spi devices on the cable.

I am running the SPI at 1 MHz. I decided to take a look at the SPI clock to see what it might look like before and after the cable is attached. I figured at 1Mhz, it should not be a problem.

When my program is running and I scoped Pin 13, I see the below.....

Why are there 2 different frequencies on the SCK signal? It looks like a pattern at about 1Mhz and 100 Khz. I think I see this same pattern when the cable is either attached or not. In any case, what will this cause behavior? I would think that the SPI clock line should be a constant pattern/frequency if it is on and it could only be either on or off. For starters, to me this does not look proper..please advise




weird spi clock.jpg
 
c172jeff said:
when I do not connect a 1 foot connector of ribbon cable that breaks out the SPI lines as well as some other signals. When testing with the cable, the SPI seems to fail in having good communication with the 5 chips on the PCB, the cable is unconnected to anything but the PCB at this point.
Click to expand...
c172jeff said:
what will this cause behavior?
Click to expand...

The rising and falling edges of the SPI clock have very high bandwidth, even though the actual clock rate is only 1 MHz. High bandwidth signals on long cables have all sorts of difficult problems when the source impedance isn't matched to the cable's characteristic impedance. The most common solution is to place a resistor in series close to Teensy pin 13 (SCK). Same of MOSI.

To see waveforms, check out the OctoWS2811 page and scroll down to "Signal Quality".

You can find an incredible amount of information about signal quality and transmission lines online and in engineering textbooks. It's a deep rabbit hole. But in the end, for this sort of application where you have an ordinary digital signal and a "long" wire, the solution is to add a resistor approximately equal to the cable's anticipated characteristic impedance. If you don't know that spec (it's rarely given) just guess 100 to 150 ohms.

Something to keep in mind is your 50 MHz scope can't show you the very high frequency effects, but even in this photo it is showing some of the overshoot and undershoot at each rising and falling edge. If you were to use a much higher bandwidth scope, with matching high bandwidth 10X probes, and careful wiring between the cable and scope probe to minimize extra ground lead, you would see much worse overshoot and probably also very high frequency ringing. But that sort of gear is extremely expensive and difficult to set up properly, all for a solution that ends up being a cheap resistor.


c172jeff said:
Why are there 2 different frequencies on the SCK signal?
Click to expand...

Bursts of 8 clocks is very common for SPI. The gaps between are software overhead. You can usually minimize this with SPI.transfer(buffer, size) rather than calling SPI.transfer(byte) for each individual byte.
 
Thanks Paul, this is a wealth of information. Version 2 of the board will have to have those resistors. I wonder if I could use a NanoVNA to measure the impedance perfectly and get the exact resistor in series with MOSI and SCK.
 
Paul’s comments and suggestions are spot on as for root cause and a remedy.

Another pitfall is SPI mode selection errors. Master reading MISO right when SCK toggles may still work with short wires, but fail with long.

The Teensy MCU offers many features for limiting output pin rise and fall times (bandwidth), adding schmitt trigger for inputs (the SCK pin is both output and input in SPI master mode!!) etc. The default T4 SPI library does not use those features. But it is possible to poke the IOPAD registers for the relevant pins.
 
Thanks, I am a licensed ham radio operator. Being a licensed ham radio operator, I get to scratch the surface of things electrical.

Is what Paul is talking about the concept of impedance matching... The idea of matching transmitter to feed line to antennae/load?
In ham radio, if this is not done, you can get damaging reflections and I suppose what looks like ringing on an oscilloscope.

In ham radio, you can always force a match by using an antenna tuner. This is usually a combination of L, C, and R at the source. Once done, and matched, I suppose no more ringing/standing waves.

If this is what's happening here, and I suppose it is, I probably should always make PCB's with the provision I can add a shunt to ground as well as some L and C on SCK and MISO (if need be)? If they are not needed, I can just short them to look the same as a single trace.

Anyways, in ham radio, I can use a NanoVNA to do all sorts of neat things...most are above my pay grade.

Can I use a NanoVNA on my PCB with a Teensey to measure the velocity factor of the trace and SWR to perfectly add something to match SCK and MOSI?


If I perfectly match the impedance of the source (Teensey) against the transmission line (the trace and what follows)..., will this ringing completely disappear?

It works as is....just not with the longer cable attached.

I wonder about adding an arbitrary cable length in the future and matching it ->no ringing -> no problems ... Wondering if this an over simplification and more importantly, what are the main points I am missing. I like the idea of matching impedances, and am curious if an "antenna tuner" on my PCB would completely eliminate ringing?
 
Yes, Z matching is part of the solution.
Source output Z on the Teensy side can be tweaked by either a series R as Paul suggested, but you can also opt for using the drive strength, slew rate and speed settings in the iMXRT1062 chip for the SCK output pin. Finding the relevant IOMUXC_SW_PAD_CTL_PAD_GPIOxxyy registers is a bit of a pain because T4 has 3 SPI hardware ports defined, numerated in Arduino land as 0, 1, 2, but for NXP known as LPSPI4, LPSPI3, LPSPI1 or so, and then SPI pins rerouted via MUXSELs to end up on PORT pins numbered inconsistently in Arduino land. But it's doable. I think the default T4 first SPI port SPC pin is "pin 13" which is on GPIO_B0_03. So IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_03 is the register to tweak. I think...

Still it's all a bit more subtle as just tweaking pin output impedance at the signal source and then assuming all will be fine. At the other end of the wire where the (last) SPI slave sits, there's another unterminated transmission line, open ended, so there things (sharp edges) still bounce back. And thus possibly causing spurious edges on the T4 SPC output pin. Which you thought was a (strong) output only, but actually it is also the input to the T4 SPI shift registers. False edges there, enough amplitude, Schmitt trigger (HYST) disabled, do make the T4 LPSPI SPI shift register decide to shift - prematurely...

Besides Z (mis)matching, basic capacitive loading of the SCK pin can bite you (or hide eminent problems). Too much capacitance on SCK and no HYST enabled makes you vulnerable...

How good or bad the SPI slave chip is (Schmitt trigger on SCK yes/no, bandwidth limiting filters in its SCK input etc) also matters.
And decent ground planes are a must...
 
Last edited:
On my board, I am noting that if I do not connect the Oscilloscope, the Board mostly works (95% of the time).
By that I mean, SPI messages get sent to/from the various devices.

Connecting the Oscilloscope, which has short connections, seems to damage the SPI signal to a point that this good communication breaks.
Nothing is accurately sent to/from the various SPI devices when the O scope is connected. The SPI devices are all on the same 80mm square board.

So, I looked into IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_03 to see its effect on Pin 13, SCK.

After my SPI.begin() call, I

ran code such as

IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_03 &= ~IOMUXC_PAD_SRE;


to change the slew rate to slow. It seems to do nothing at all. I am looking at the ringing on my O-scope and would have expected a change when either switching the bit on or off. I do not see any change. I am sure that IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_03 is the proper link as when I set DSE to 0, my output signal disappears from the O scope.

I had seen this post,
https://forum.pjrc.com/index.php?threads/slew-rate-limiting-for-spi.71455/ and noted that that person saw the same thing - IOMUXC_PAD_SRE has no effect

I saw something about user space and wonder if the microprocessor on the Teensey is running in that space and if that prevents these types of changes?...

Does anyone know how to use the macros shown in
IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_03 |= IOMUXC_PAD_SPEED(1) | IOMUXC_PAD_DSE(4) | IOMUXC_PAD_SRE;

to make changes to the slew rate on Pin 13 or more importantly, if it is achievable in a line of code right after SPI.begin().


I am hoping to change the slew rate to slow and/or the drive strength and see effects on my 100Mhz scope.
 
c172jeff said:
Can I use a NanoVNA on my PCB with a Teensey to measure the velocity factor of the trace and SWR to perfectly add something to match SCK and MOSI?
Click to expand...

I'm not very familiar with this measurement, but I'm going to go out on a limb to answer "probably not". A network of PCB traces, and separate ground return paths if not a 4+ layer PCB with unbroken ground plane, coupled to a completely different cable probably having PVC plastic rather than FR4 fiberglass for dialectric, and 5 destination points that are mostly capacitive loads (but could be quite non-linear... think MOSFET gate & diode junctions rather than real capacitor with pure insulator dialectric) is likely quite a bit more complex than the intended application. I'm a bit skeptical you'd end up with a useful measurement.

But typically just getting the resistor value "close" (even within 30-50% of "ideal") makes a huge improvement. Often the resistor forming a slight low-pass filter together with the capacitance of the traces and nearby chip pins (typically 5pF per pin) has as much or more effect than the source impedance matching to characteristic impedance of the wiring.

c172jeff said:
I saw something about user space and wonder if the microprocessor on the Teensey is running in that space and if that prevents these types of changes?...
Click to expand...

This question is much easier to answer. By default all code runs in system mode with full access to all hardware registers. You can reconfigure the pin and GPIO registers.

While unrelated to hardware registers, for a complete answer (especially for people who later find this by search), on Teensy 4.x we do configure the MPU (memory protection unit) to restrict executing instructions from memory normally used for data, and from writing to memory normally used for executing instructions. This is meant as a proactive software security measure, to prevent many types of programming errors from becoming potentially exploitable for code execution. The MPU also disallows any access to the first 32 bytes of memory, intended to catch NULL pointer dereference errors. For peripheral registers, the default MPU setting allows full access.
 
Last edited:
c172jeff, what are the SPI slaves that you use? If these are the ST MEMS (magnetometers, gyro, accelerometers etc) then there are lots of pitfalls with I2C interface mode getting activated by accident. And issues with SDO lines being undefined when first SCK clock edge arrives. Maybe that’s what’s biting you?
The scope probe is 1x or 10x? A small capacitor (~22 pF ish) has the same effect as adding the scope probe?
 
Those SPI slaves claim to have 20ns filters on their SCK inputs to avoid false triggering. So that should be pretty tolerant to ringing with the wire lengths that you have. The T4 SPI clock input may however still be suffering…
Things to double check also:
* Is SPI MODE3 the mode that T4 uses?
* Is tCC always respected?
* Is tCH always respected?
* Edges in SDI or SDO within +/- 100 ns of SCK rising?

SPI communication errors could be:
* failure of delivering data to slave
* failure of capturing data from the slave

I would try to diagnose what really goes wrong by exploiting the loopback after 40 bits feature that the TMC5160 offers: keep CS low, let Teensy send random bit stream and check that exactly the same data gets echoed 5 bytes later. If not then drive a leftover T4 output high, trigger your scope on that, and see who’s to blame for misbehaving.

IMG_0556.png
 
You define which SPI mode when you use the bus. Wouldn't expect any timing problems so long as respect the max freq.
 
I am using a Mode 3 SPI bus. I verified that in the oscilloscope and see it defined in code.

By the way, here is a short video of the board in a "working state"


If you connect the O scope, it no longer works as in the video. Same with the Raspberry pi. Connect the Pi and improper SPI communication ensues.

I do think that some parts of the SPI data stream are lost or miscommunicated.

When I designed the board, I laid the traces for the SPI signals without any regard for being proper. I mean they take twists and turns to get to the various places. One of them might even be a 165 degree turn around a pin and through vias. It is a 4 layer board. Next board will be different. I really had no idea I would have SPI issues.

I saw that SPI reference page in the manual and will have to study that next with regard to timings. I run the communication at 1M. It is not exactly a 1M SPI clock, more like 9xx Khz.

I had no idea that I could "to diagnose what really goes wrong by exploiting the loopback after 40 bits feature that the TMC5160 offers: keep CS low, let Teensy send random bit stream and check that exactly the same data gets echoed 5 bytes later." That looks like the feature to work with next to debug this problem." I will definitely use that to find the real culprit.


Earlier, when I decoded the SPI signals on the Oscilloscope, for the most part the values sent were correct. At times though, when I though a value should show on the O scope, it was 0, so not 100%.

I am really surprised I got this far on my first real test of SPI on a PCB.
 
is your 'scope probe set to x10? It needs to be for most situations so it has minimal loading on the circuit and full bandwidth.
 
Yes, I have been using 10x. I am looking at the timings/traces on my oscilloscope. I think i see a problem.
I am triggering on a falling edge of the chip select line. Most timings/triggers look as expected. Clock is high before cs falls (as per the doc).
I just noticed a pulse of this line in between clock edges. Blue is Chip Select. Yellow is the clock.
I cannot think of a situation where this should be true. I need to look more into this and the TM5160 library.
I plan to get the eval board for the tm5160 and link that to my motors to experiment and have a look at ideal signals.
Also the loop back test I plan to do. First, I want to understand where this pulse is coming from and why? I think the clock should always be high before this falls. This might be the issue. I used a TM5160 library from github.


20240108_112459.jpg
 
Just curious if you ever figured this out? I've also been having an issue with big tree tech TMC5160T stepper drivers the a Teensy 4.0.

The communication being very unreliable. I've made it way more reliable by soldering in some pull up resistors in the CS pins, and using software spi at very slow rate of around 1khz, but it still isn't 100%. The SPI traces are not long at all, so this has been a huge delay in my project I didn't think I would have had. But has been a good learning experience. Maybe my next step is to buy an oscilloscope.
 
Yes and No....First, I did take a 3 month break to go to Florida. Now that I'm back, I'm revisiting this.

I have seen some reliability issues in my design.

My best setup (using my current board) is to use just the Teensey 4.1 and 5 chips. My design has a limit switch... When each motor is visited, it drives to the end of travel until the limit switch is triggered. Stops and then drives the other way.

For a few axis, this works better than others. Some steppers stall. Ive been exercising it profusely. While I think I've had it working good on all axises, and can switch and manipulate the 5160, there does seem to be reliability issues and items decoded on my o scope are sometimes not correct. I disconnected the extra ribbon cable a while back. That makes it more stable.

I now understand the 5160 better than before. I now also see see some issues when the raspberry pi is added.
For example, when the raspberry pis spi pins are connected, its unreliable. Some pins are pulled up and I might need to change this in a new compiled pi dto file for the affectd pins.

Long story short, I am making a version 2 of the board that adds series resistors near all drivers as well as pull up lines on the chip selects.

My first board had the provision to add either an arduino or teensey 4.1. Additionally, it could handle 6 tm5160 chips and included a level shifter. Since i only need to use 5 chips, 3.3 logic, and am confident enough that the teensey spi stuff works good/lack of memory on an auduino is a major problem, i decided to get rid of the extra 5160 location and arduino options .

Ill give more attention to the layout of my new board, but given its small size and additional resistors/pull ups, teh routing might be just as bad. Either way, my plan is to make another board that corrects some mistakes.
I was pretty impressed with the first version of the board and how far i got, but, now i think its time to be corrected.
 
Okay, thank you for replying. That was the approach I was going to try to take. A new version with series resistors. I was looking into the teensy slew rate limiting feature, but I think resistors are just a better way to go no matter if slew rate limiting is in place or not.

Kind of wish I went with the TMC2209 at this point.
 
Just an update...I did make a version 2 of the board. The communication and TMC5160 function seem to work flawlessly. I gave more attention to the SPI lines and avoided the swiss army knife complexity of the first board implementation.

Like I said earlier, the first board could hold either a Teensy or Arduino as well a Raspberry PI. I had an extra 5160 slot and the choice of either 3.3 or 5 v logic... In the first, the traces literally took twists and turns all over the place to get to where they needed to be. The first board did not even have a ground plane. I think that might have helped the most in v2.

In any case, the second board, with the series resistor, cleaned up the waveforms. My communication to/from all the 5 TMC5160 chips work flawlessly.

Additionally, the Raspberry Pi on the board communicates perfectly fine with the Teensey 4.1

Someone asked about using the TM5610 chip.... That works good too. The advanced features of that chip such as motor stall detection and latching the ramp generator position to a latch register work as expected. I don't really see any problem with the electronics.

If I ever hade a V3 of the board, it might be able to add some more leds and mounting holes...
 
Thanks for the update.

I also got a new revision of my board and have been working on it this week. I added 4.7k pull up resistors on CS, added 47 ohm resistors in series on all lines. I also now do not cross any SPI lines unless there is a ground plane in between. So far the communication seems reliable.
 
I ended up still having issues. I was using TMCStepper library, what really helped was changing the library and adding a delay to make reading from the TMC5160 more reliable.
See: https://github.com/teemuatlut/TMCStepper/issues/303

That could of been my issue all along. The TMCStepper was probably originally developed on a uno and the teensy is just so much faster.

After I was able to communicate reliably I found a few other issues with my code. This was a big thing that help me find the other issues.
 
I thought I had it but still ran into troubles. Ended up using software spi. And the motor acts weird when I have the SPI going to certain pins on teensy 4.0

Works poorly:
MISO -> 9
MOSI -> 12
SCK -> 11

Works well
MISO -> 16
MOSI -> 19
SCK -> 18

Been trying to figure this out for hours, bought a oscilliscope just to try to figure it out.
Move any one of the pins of MISO, MOSI, SCK to the poorly pins and it still behaves poorly. I can't believe I've been struggling with this for so long :(
 
@Bluthen: Not sure if you are using custom pins for a specific reason, but standard SPI0 pins on the T4.1 (which work very well) are as follows:

MOSI: 11
MISO: 12
SCK: 13
CS: 10, 36, 37

Standard SPI1 pins are as follows:

MOSI: 26
MISO: 1
SCK: 27
CS: 0

Mark J Culross
KD5RXT
 
It has been a while since I last visited my robot project. Suffice to say, I am not having any more SPI problems. This is after making a new board that better handled the high speed line changes. I also made changes to the SPI library for TM5160. I though there wass an error that needed foxing. You can download the zip and compare what files were changed. I do remember making some changes in the low level SPI code in one of the base classes as well as other files. I got side tracked and will come back to my project
 

Attachments

  • tosend.zip
    188.9 KB · Views: 14
You must log in or register to reply here.
Back
Top