Teensy 4.1 noisy/spurious digital output

[mnissov]

my logic analyzer has an analog mode which caps at 50MS/s, I'll give that a try as well, but this drastically reduces the recording time.


One additional point, I feel at some point there may have been a misunderstanding. Here I show two 10us wide HIGHs, these are highlighted by the yellow circle. The problem area is circled in red

Here I zoom in on only the problem area, the widest HIGH is about 6ns, I've written 6ns above it.

So this "glitch" is purely additive, meaning it's not affecting the 10us 200Hz HIGHs. The glitch inserts itself between the expected HIGHs at random times and in random position (i.e. closer to left, middle, closer to right, etc).

I realized the quality of the previous images was quite bad. Hopefully this is better.

 

[luni]

Since your signal is not in sync to the generated 200Hz, 10µs pulses, ringing of the edges of these pulses seems unlikely to me. Another idea: Maybe you get disturbances from the PC through the USB connection? Together with the ringing Paul showed, this might explain your observations. Can you power the board by an external supply to check this? E.g. using an old 5V Micro USB charger (don't forget remove any while(!Serial) lines from your code). Alternatively connect the Teensy via another/additional USB hub and see if something changes.

 

[mnissov]

Since your signal is not in sync to the generated 200Hz, 10µs pulses, ringing of the edges of these pulses seems unlikely to me. Another idea: Maybe you get disturbances from the PC through the USB connection? Together with the ringing Paul showed, this might explain your observations. Can you power the board by an external supply to check this? E.g. using an old 5V Micro USB charger (don't forget remove any while(!Serial) lines from your code). Alternatively connect the Teensy via another/additional USB hub and see if something changes.

And actually ringing in general isn't a huge problem for my rising edges. I can take another picture on monday but the analog mode captures a bit of overshoot (0.2V perhaps) and that's about it. Immediately settles to 3.3 after. The glitchy region is actually quite far from the expected HIGHs.

I have a dock I can try powering i through, I guess this achieves a similar effect?

 

[PaulStoffregen]

Maybe this is a good point to contact Saleae for support?

The oscilloscope results pretty clearly show this program doesn't output those tiny pulses. Maybe if you give them photos of your setup, show them the scope results (feel free to send my photos) and give them other details about your setup, perhaps they'll have some idea of what's going wrong.

Saleae products are premium priced because they offer support. This is a pretty clear case of their gear showing you strange results that other people can't reproduce. Who knows, maybe the end result could be there's some issue with your particular unit? If it was just a cheap no-name product, I'd say don't bother and just get a different one. But for premium priced Saleae that offers support, you really shouldn't feel shy to contact them for a situation like this.

EDIT: looks like they have forum, maybe start there? https://discuss.saleae.com/

 

[mnissov]

I wrote their support team a mail yesterday so I'll hopefully be in touch with them after the weekend.

That being said I feel relatively confident this isn't aliasing in the measurement, because I've connected a sensor (the original point of the more complicated code is triggering sensors) and this seems to trip up whenever this glitches appear. Meaning, the IMU samples normally and then suddenly returns twice (in quick succession) data packets "stamped" with the same count. This happens at the HIGH signal before the glitch (in 2 tests so far) as if the HIGH generates one message and the glitch screws it up before it manages to finish and send: thereby corrupting the first and triggering a second. Of course the duration of these glitches aren't long enough to trigger a response either, IMU quotes minimum 100ns syncin. Anyway it's just to say this has been very convoluted to debug from my side.

Of course the examples I post here are with a more basic program and no peripheral sensors attached, purely the teensy as it seems the same event happens in these minimal conditions. I'll try on monday and see if I can catch an analog measurement of the glitches, either with an oscilloscope or the logic analyzer.



Don't get me wrong though, I'll definitely be hearing what saleae thinks, I have a hard time pinpointing exactly where the cause is, particularly given how it seems I am the only one who can recreate this phenomenon.

 

[mnissov]

Update, got a hold of an oscilloscope, been trying to capture this but it's difficult keeping a sufficiently large window but also sufficient resolution. So that's a work in progress.

Otherwise: connecting with a USB hub and measuring analog on the logic analyzer I found the phenomenon. I used the following script

#include <Arduino.h>

const uint8_t _pin_out_ = 2;
const uint8_t _pin_gnd_ = 1;

elapsedMicros g_rising_edge_timer;
elapsedMicros g_falling_edge_timer;
uint32_t g_rising_edge_cycles;
uint32_t g_falling_edge_cycles;

uint32_t threshold;
bool g_is_high{false};
uint32_t g_interval = 5000 * (F_CPU / 1000000);  // 5ms
uint32_t g_width = 10 * (F_CPU / 1000000);       // 10us

elapsedMicros timer = 0;
void detectGlitch()
{
  if (timer > 5005 || timer < 4995) {
    Serial.printf("gotcha %d\n", (unsigned)timer);
    digitalWriteFast(22, HIGH);
    digitalWriteFast(22, LOW);
  }
  timer = 0;
}

void setup()
{
  pinMode(_pin_gnd_, OUTPUT);
  digitalWriteFast(_pin_gnd_, LOW);
  pinMode(_pin_out_, OUTPUT);
  digitalWriteFast(_pin_out_, LOW);

  if (ARM_DWT_CYCCNT == ARM_DWT_CYCCNT) {    // Enable CPU Cycle Counter
    ARM_DEMCR |= ARM_DEMCR_TRCENA;           // enable debug/trace
    ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA;  // enable cycle counter
  }

  pinMode(3, INPUT_PULLUP);
  attachInterrupt(3, detectGlitch, RISING);
  pinMode(22, OUTPUT);
  digitalWriteFast(22, LOW);

  while (!Serial) {
  }
  Serial.println("starting");
  delay(1000);
  timer = 0;
  g_rising_edge_timer = 0;
  g_falling_edge_timer = 0;
  g_rising_edge_cycles = ARM_DWT_CYCCNT;
}

void loop()
{
  if (ARM_DWT_CYCCNT - g_rising_edge_cycles >= g_interval) {
    digitalWriteFast(_pin_out_, HIGH);
    g_is_high = true;
    g_rising_edge_cycles = ARM_DWT_CYCCNT;
    g_falling_edge_cycles = g_rising_edge_cycles;
    //timer                 = 0;
  }

  if (g_is_high) {
    if (ARM_DWT_CYCCNT - g_falling_edge_cycles >= g_width) {
      digitalWriteFast(_pin_out_, LOW);
      g_is_high = false;
    }
  }
}

The serial monitor returns:

starting
gotcha 2208
gotcha 2791

Pins 2 and 3 are soldered together and the gotcha is registered, so this should be more than just logic analyzer aliasing.

and zooming in on the glitch in the center

and yes, it is registering as negative

Note, row 1 is pin 2 (200Hz signal), row 2 is pin 3 (alarm), and row 3 is analog of row 1.

Note, here is the falling edge of an expected HIGH



Working on oscilloscope capture

 

[mnissov]

UPDATE with oscilloscope. Note connections are suboptimal so additional ringing may be there.

As before, logic analyzer row 1 is 200 hz, row 2 is alarm, and row 3 is row 1 analog measured. I'm using the script from p#31. The whole capture is

The specific glitch I'm focused on is

Zooming in:

The scope capture of this (yellow is signal and green is alarm)

 

[mnissov]

Update: think I've discovered the problem: interference.

I'm not sure if all instances were cause by this, but I know this can at least be a very potential cause. While gathering some data, I noticed the alarm was spiking when a stood up, a little more investigating revealed that compressing the damper in my chair was inducing a HIGH signal on the logic analyzer, even when disconnected from micro controller.

For the time being I guess I'll be using a different chair. For a more long-term solution I think I need to put some consideration into EMI protection. I guess twisting cables will be a good start, maybe proper shielding will be necessary as well.

 

[PaulStoffregen]

I'm running the code from msg #31 on a Teensy 4.1 with pins 2 and 3 shorted together. So far it hasn't printed "gotcha", except when I remove and replace the wire just to check it really is watching.



Regarding your measurement, are you still seeing negative voltage at the pin?



Might be worthwhile to remove all the wires (except USB cable) between Teensy and anything else. Then use a voltmeter to check the voltage between Teensy's GND pin and the ground of everything else on your desk. Ideally you should see very close to zero volts (and it shouldn't fluctuate when touching the wires) if everything is properly grounded.