Teensy 4.1 with AD4134

[mkorz]

Hello PJRC community.

I am attempting to interface the Teensy 4.1 with the evaluation board for the AD4134. The pertinent hardware datasheets are:

Teensy 4.1: https://www.pjrc.com/teensy/IMXRT1060RM_rev2.pdf
AD4134 evaluation board: https://www.mouser.cn/datasheet/2/609/eval_ad4134_ug_2016-2902262.pdf
AD4134 chip: https://www.analog.com/media/en/technical-documentation/data-sheets/ad4134.pdf
LSF-EVM (auto-bidirectional multi-voltage level translators): https://www.ti.com/lit/ug/slvub53/s...url=https%3A%2F%2Fwww.ti.com%2Ftool%2FLSF-EVM
LSF0108 chip: https://www.ti.com/lit/ds/symlink/l...=https%3A%2F%2Fwww.ti.com%2Fproduct%2FLSF0108

I also have an interface board and evaluation software for the ADC which I am using to do troubleshooting, while I work on the Teensy - ADC interface.

SDP-H1: https://www.analog.com/media/en/technical-documentation/user-guides/UG-502.pdf

I am using a benchtop power supply set at 12V to run the ADC evaluation board, and same supply set at 7V to run a 5V regulator for Teensy, and a 3.3V and 1.8V regulator for the voltage translator.


My first milestone is to read a register on the AD4134 using SPI. The code I have uploaded to the Teensy is as follows:

main.cpp

#include <Arduino.h>
#include "ad4134.h"
#include "parameters.h"

void setup() {
    Serial.begin(9600);
    ad4134_spi_setup();
}

void loop() {
    Serial.println(ad4134_spi_read(0x80 + 0x00));
    delay(1);
}

parameters.h

#ifndef __PARAMETERS_H__
#define __PARAMETERS_H__

#define AD4134_SPI_CLK_FREQ_HZ	2500000
#define AD4134_SPI_BIT_ORDER_IN	MSBFIRST
#define AD4134_SPI_DATA_MODE_IN	SPI_MODE0
#define AD4134_SPI_CS           10
#define AD4134_SPI_MOSI         11
#define AD4134_SPI_MISO         12
#define AD4134_SPI_SCK          13

#endif /* __PARAMETERS_H__ */

ad4134.h

#ifndef AD4134_H
#define AD4134_H

#include <Arduino.h>
#include <SPI.h>

/** Setup SPI */
uint32_t ad4134_spi_setup();

/** Read from device. */
uint32_t ad4134_spi_read(uint8_t reg_addr);

#endif //AD4134_H

ad4134.cpp

#include "ad4134.h"
#include "parameters.h"

/** Setup SPI */
uint32_t ad4134_spi_setup(){
    pinMode(AD4134_SPI_CS, OUTPUT);
    digitalWrite(AD4134_SPI_CS, HIGH);
    SPI.begin(); 
    return 1;
}

/** Read from device. */
uint32_t ad4134_spi_read(uint8_t reg_addr){

    uint32_t result = 0; 
    uint16_t packet = 0;

    packet = reg_addr << 8;

    SPI.beginTransaction(SPISettings(AD4134_SPI_CLK_FREQ_HZ, AD4134_SPI_BIT_ORDER_IN, AD4134_SPI_DATA_MODE_IN));
    digitalWrite(AD4134_SPI_CS, LOW);
    delayMicroseconds(1);
    result = SPI.transfer16(packet);
    delayMicroseconds(1);
    digitalWrite(AD4134_SPI_CS, HIGH);
    SPI.endTransaction();
    return result;
}

My complication is that when I send a read command (0x80 to read register 0x00) from the Teensy to the ADC and scope the ADC's SDO line, I receive an incorrect response (expect 0x18 but get 0xFF). When I plug in the interface, run the evaluation software, and send same command while scoping the SDO line, I get the correct response (0x18).

Scoping Teensy SPI interface
yellow = CLK
teal = CS
purple = MOSi
blue = MISO


Scoping Interface Board SPI interface
yellow = CLK
teal = CS
purple = SDI
blue = SDO



Please let me know if there is additional information I may provide for troubleshooting. Thank you.

 

[PaulS]

Ran your code on a Teensy 4.1 and the logic analyzer shows the same as your first picture [with the exception of the MISO line since I don't have an AD4134 here].



Can it be that the eval software sets a number of additional AD4134 registers that you are not aware of?

Paul

 

[mkorz]

Ran your code on a Teensy 4.1 and the logic analyzer shows the same as your first picture [with the exception of the MISO line since I don't have an AD4134 here].

View attachment 28942

Can it be that the eval software sets a number of additional AD4134 registers that you are not aware of?

Paul

Thank you, @PaulS, for the suggestion. I've looked through the datasheet and it doesn't indicate additional setup. I also scoped the first 2 seconds of the SPI lines after evaluation software bootup, and the only activity is a read of every register on the ADC.

I am now powering the Teensy and lower side of the level translator using 5V and 1.8V outputs from the evaluation board (in case there was a grounding issue), and the high side of the level translator using the 3V output from the Teensy. There is an output difference but still incorrect.


Scoping Teensy SPI interface after rewiring to use 5V and 1.8V voltages from ADC evaluation board
yellow = CLK
teal = CS
purple = MOSi
blue = MISO


Two observations that strike me as irregular:
1. There is ADC-SDO (Teensy-MISO) traffic in the first two bytes, instead of the latter two bytes.
2. The Vpp of this line is ~10% smaller than the other signal lines.

Thank you again for your input.

 

[PaulS]

Just checking: you are measuring with the scope on TP86/TP80/TP59/TP64 of the EVM board? And R112 is mounted such that the board is operated in SPI mode?
My suggestion would be to doublecheck all powers and GNDs on the EVM board and levelshifter board.
Could the slow ramp of the blue SDO signal after the read cycle be an indication for an issue? I'm not sure how to explain that ramp.

Paul

 

[mkorz]

I am indeed scoping the pins that you describe, and R112 is also mounted. I've checked that the grounds across all three systems (ADC eval board, Teensy, and level shifter board) are common, and as are the different supply voltage levels.

In a troubleshooting step I attempted to run the evaluation software (with interface card plugged in), and my Teensy code at the same time, toggling between which one has control over the SPI bus. When a command is sent from the interface card, I receive an accurate response, but when a command is sent from the Teensy, I get an incorrect response. This was to verify that any sort of start up routine would be run by the evaluation software, before the Teensy took control. At this point, I don't believe there is any start up routine given the lack of change in operation.

I suspected that the level shifter may be faulty, so I purchased another one but didn't observe any change after swapping it into the system.

The search continues; I'll report back if I make a breakthrough. Thank you again for your engagement, PaulS.

 

[Nominal Animal]

I would not use a bidirectional level shifter for SPI; I find the unidirectional ones and the ones with a direction pin much more robust. (SN74LVC1T45 in SOT-23 is my favourite, for single signals.)

For SPI, TI TXU0304 should work very well, and is available at Mouser at least. All you need is 100nF=0.1µF ceramic capacitors from each VCC to ground for supply bypass.

If you want more than the three outputs (CS, SCK, MOSI), then TI SN74LVC8T245 can do eight outputs (or inputs) at a given voltage between 1.65V and 5.5V, so two of those, or one plus a SN74LVC1T45 or SN74LVC2T45 for at least the MISO input, should do the job. They seem to be available at many places (Mouser, TME, JLCPCB, LCSC), and one could even quickly create a simple break-out board in say EasyEda and have them custom-made.

 

[mkorz]

I will try your suggestion of swapping out the bidirectional shifter for a unidirectional one. Mouser sells an evaluation board for the TXU0304, TXU0204, and TXU0104 which is now on its way to me. Thank you for your insight.

 

[Nominal Animal]

To be specific, while the bidirectional level shifters do work as advertised, the way they determine the signal direction is something I do not trust in an unidirectional case. Extra capacitance, for example because you're using a breadboard, signal reflections, and so on, could easily confuse that. I am not an EE, so I do not know the conditions nor workarounds for that, so I use unidirectional level shifters instead. (For example, one of my single board computers, an Odroid HC1, has an UART with 1.8V signal levels.)

It is particularly evident when using I2C. Not all bidirectional level shifters work well (or at all!) with I2C, and one is better off using one specifically intended for I2C use.

It would be extremely interesting and informative to see and be able to compare the scope traces when using the different level shifters.
If there is no significant difference (especially in the MISO trace), then I was obviously wrong.
I am only a hobbyist myself, and am really hoping I didn't just cause you to waste $25/25€ + shipping...

 

[mkorz]

No problem Nominal Animal; these are good components to have in hand anyway and the investment is minor.
I’m at a dead end regarding my troubleshooting so your suggestion is an avenue I’m willing to explore.

 

[Nominal Animal]

Interestingly, over the EEVblog forums two experienced members, edavid and Ian.M, suggested someone having pulse shape issues to ditch their bidirectional level shifter (TXB0108 in their case) and use an unidirectional one, exactly because glitches and load limitations in these shifters. So, although it is still a guess, I do believe my original suggestion is very valid and sensible, even if it turns out the problem at hand happens to be somewhere else.

 

[mkorz]

Nominal Animal, your suggestion proved to be wise and has resolved my issue. Thank you for your help! I hope I can someday help someone else the way you helped me.

PaulS, thanks for your tips as well, they were a great sanity check and kept me from giving up.