checking Teensy for partial failures

Fenichel

Well-known member
I have an app that connects Teensies to a variety of other hardware. A few days ago I blundered and connected an external opamp (LV321, rated up to 5.5V) to a Teensy 3.5's Vin (about 8.8V) instead of the intended 3V3. That destroyed the LV321, and it also did obscure damage to the Teensy, presumably through transient disruption of the Vin supply.

The only thing I've found so far is that the Teensy can't talk to its uSD socket any more; a lot (maybe all) of its other function is OK.

If I want to use the damaged Teensy for any purpose again, I'll have to check the particular functions then needed, to see if the relevant parts of this Teensy are intact.

This made me think of a useful project that would be incredibly tedious to execute, but I wonder if someone even more OCD than I am has already done it. Probably everyone has done small pieces of the job at one time or another.

What I'm thinking of is a board with a socket to accept a Teensy and with other hardware, including another CPU, that could systematically test most of the Teensy's functions, pin by pin. Such a board would be a great boon to people who, like me, now and then inadvertently abuse a Teensy without totally destroying it.
 
The code described in the https://forum.pjrc.com/threads/55735...l=1#post324323 post covers only a small part (digitalRead) of the Teensy's functionality. If I told you "This Teensy seems to be working perfectly," you would assume that I had looked at more than digitalRead. Also, using the program described in that post involves a lot of accident-prone manual fiddling.

With the board of my fantasy,
  • I load a fixed slave program onto the abused Teensy
  • I plug that Teensy into the board's socket, and
  • a fixed master program runs on the board's CPU (presumably, another Teensy)
Then, either via Serial Monitor or an on-board TeensyView, the master reports on how well the slave is performing tasks assigned by the master.

One version of such a board would have a ridiculous number of relays, allowing the master to connect each slave pin, one at a time, to test sources & sinks. Less extravagantly, the user could be required to select the pin(s) to test using rotary switches; an all-pin test would then require a fair amount of (mindless) user participation, but each per-pin test could be much more thorough than what users are likely to do with probes in hand.
 
PJRC has a MASTER TEST jig that tests all that and more in some fashion - each Teensy visits it for a test and bootloader programming before it is allowed to sit in a PJRC package because it has to pass to get the factory blink loaded, and has to factory blink to leave the factory.

Paul has posted some view of the POGO pin monster that hits every active pin and test point - takes a second or so to complete.

That link was indeed just a minimal, and as noted manual, way to confirm basic function of the digital pins. If they can't pass that then there are bigger problems - perhaps the base of an idea to test.
 
Thinking about it some more, the rig you describe and my fantasy board are directed at different tasks. PJRC doesn't knowingly sell Teensies that work except for one or two bad pins, so their rig is presumably optimized for rapid sell-or-trash decisions.

In the field, I think most people own one or more Teensies that are imperfect in known ways (victims of mishandling), but retained for when their remaining functionality is sufficient. My fantasy board would allow me to make a detailed census of a Teensy's functions/dysfunctions.

I have some old 7400 multiplexer chips somewhere, and I'll think a little more about a feasible design. I expected that someone else had done it already.
 
I think that kind of project only makes sense if you do it because you enjoy the challenge. No matter how good you are, you almost certainly will not be able to test as thoroughly as PJRC does when the boards are initially manufactured. I would image that several months were spent developing and tweaking their fixture.

In your case, you are working with the Teensy 3.5 which is probably at end of life in any case.

For example, here is a comment made by Paul regarding testing just the Ethernet port on Teensy 4.1.
--------------------------

I can assure you the ethernet PHY on every Teensy 4.1 is tested during the bed-of-nails test that checks all the pins.

In that test, the 4 data pins and GND are connected via 22 nF capacitors to a Pulse H1102 ethernet transformer in the test fixture, which has the transmit output connected to the receive input on the other side the transformer.

In the test, the PHY is configured to 100 Mbit full duplex. After link status is detected, a ping packet is transmitted and the test fixture checks that the PHY receives all of the bytes properly, exactly matching the transmitted packet.

If link status isn't detected within 0.35 seconds, or if the packet isn't received, or if any byte in the received packet doesn't match the transmitted packet, the test fails and the entire Teensy 4.1 board is rejected.
 
I think that kind of project only makes sense if you do it because you enjoy the challenge. No matter how good you are, you almost certainly will not be able to test as thoroughly as PJRC does when the boards are initially manufactured. I would image that several months were spent developing and tweaking their fixture.

I'm sure that's true, but I see my project as one that could be extended as needed, possibly by contributions from people with specialized experience. For example, the board might have multiple sockets, so it could accept various Teensy form factors, with (of course) only one socket in use at a time. A version could conceivably use pogo pins to get to the SMD pads on the undersides of the Teensies, but a simpler version could just ignore those pads, as (I'll bet) most end users do.

Then, the multiplexing could connect selected pins to (a) the master CPU or (b) to external connectors leading (as needed) to one or another external signal source or analyzer. I don't suppose that many end users have Pulse H1102 ethernet transformers, but less exotic equipment might sometimes be useful.

For example, consider the T3.5 that I mentioned at the start of this thread. It can boot, and it can talk to an attached TeensyView. It can't connect to its own uSD, so I know it's damaged, but I don't know how badly. I'd like to have a quick way of finding and logging that (say) digitalRead works everywhere except on pin 12, digitalWrite works everywhere except on pins 34 and 38, DAC0 works but DAC1 doesn't, 3V3 is still good, and so on. That kind of data could all be efficiently gathered by another Teensy, attached to an appropriate multiplexing network. If I suspected that there were more subtle problems (say, a change in the rise time of digitalWrite), then I could have the master CPU have the slave do digitalWrites on the various pins, while the master caused the multiplexer network to connect one pin after another to an output that I was tapping with a scope.

In your case, you are working with the Teensy 3.5 which is probably at end of life in any case.

Yes, but that's something of a red herring. The key idea is a diagnostic (not just pass-fail) test bed. As long as the device under test could be loaded with a slave program that knew how to respond to protocol instructions from the master, it might not even be a Teensy.
 
Back
Top