Possible new shields

[CWashburn]

As I said earlier, I tend to like what I called a hacker's shield that has islands with pins needed for a particular purpose (I2S1, I2S2, Serial1, Serial2, i2C0, i2C1, SPI0, SPI1, etc.). And it would be nice if there was an option for using standard cables (such as the 5x2 IDC cable, or the RJ45 cable with 8 wires).

Now in your shield there isn't necessarily room for these island, but it would be useful to avoid the usual cross wiring that you see with breadboards. Obviously there are some issues, such as you can't use SPI1 and Serial1 at the same time, since they use the same pins. And with SPI pins, you often want to chose other pins for the CS, D/C, and reset pins, particularly if you have multiple SPI devices on the bus (such as flash memory, a SD card reader, and a display).

Speaking of the CS pins, you may want to have pull-up resistors for the common pins, just like you have for the i2c pins.

And a lot of times now, I find myself wishing I had a separate 5v power bus.

But again that likely won't fit this into your current setup.

Yeah, it's a pretty tight sqeeze on a 2 layer board, but it helps keep the cost down. If I add too much more, some traces are going to have 4-5 vias.... not ideal for high-speed signals. There isn't much room for any more connectors, but there are a few things I think I could fit:

- A 5V level translator for WS2812 strings
- 5-pin Serial port header
- Some general purpose LEDs
- Piezo buzzer
- Spring terminals for the sides

I was wondering about carving a through path for a wire under the spacer PCB to get that missing pin connected as long as the trace connects all the other pads?

That should work. You could also find some 1mm washers and use those as spacers. I'm pretty sure the ones that come with the kit are about 1mm thick, so you could try those.

[recri]

I have been a long time fan of the Dontronics SimmStick system. You mount your microprocessor and run all the pins out on a parallel bus to a series of SIMM sockets. Then you build extension boards with fingers and notches that mate to the SIMM sockets. Each extension board pulls only the power busses and signals that it needs and does with them what it wants. The founder of Dontronics retired at 75 last year, but parts of his website live on buried inside his daughters' scuba tourism influencer website. Ah, in fact, here's his catalog https://www.dontronics.com/dt.html of SimmStick backplanes and plugins. Seems that passive backplanes with processor mounted on a plugin were common.

Reading https://www.dontronics.com/ssinfo.html I see that credit for the original SIMM backplane idea belongs to Antti Lukats from Estonia.

These days, the raspi compute module is built to fit a DDR2 SODIMM socket, 67.6mm x 31.1mm, and google sees multiple host boards advertised for it.

Hmm, a 62.3mm x 18.0mm board, like a Teensy 3.6 might fit into that form factor, too. Maybe build a passive backplane with SODIMM sockets, design SODIMM carrier cards for all the Teensy 3+ that route shareable signals to shared bus lines, unique signals to unique bus lines. The same set of carrier cards might adapt stackable shields built for different Teensy models.

I didn't realise that the Pi compute module routes all the processor gpio to the SODIMM, not just the gpio that the Pi normally exposes. Interesting.

[CWashburn]

I really like that concept, where all the slots are standardized. As with any system, there are drawbacks though. It would probably take up more space (at least vertically), and I would have to completely respin the design.

My current design is more geared toward stuff like robots and industrial-type applications that don't need to be super tiny. I wanted it to be as simple as possible, while still retaining the most common components to reduce the amount of unnecessary wiring.

[chipaudette]

I want a MIDI shield. MIDI In/Out/Through. Along with the MIDI hardware, the board should have assorted through-hole solder points for attaching analog sensors or whatever. Nothing fancy, just through-holes.

Also, for the Teensy audio shield, the combination of MIDI + audio shield makes for a ready-to-go as a synthesizers. Or as a sound effects machine. That would be a sweet combination, especially if joined together as a single board.

Similarly, if the Teensy audio shield had a USB Host (say, instead of MIDI), it means that I could use cheap USB MIDI keyboards (and cheap MIDI knobs). This would be another ready-to-go sound making machine, especially if joined together as a single board.

Chip

[skybrian]

I have no idea if anyone else wants this and I'm just getting started with Teensy, but I would be nice to see something designed specifically for easy, portable sound synthesis. So, something like a good way to do battery charging, a headphone jack, a line out socket, and an amp on the board?

(Just to give some context, when I was shopping I also looked at the Axoloti board and the Bela mini. The Axoloti seems bigger than I want and perhaps designed more for a rack mount, and the Bela mini is pricy if you order it assembled, and ships from the UK.)

I also wonder if it's worth putting the microcontroller and some basic audio output on the same board, since the i2s connection needs to be kept so short anyway. Even if that's too specialized, a bit of convenience for beginners would be to sell a bundle with microcontroller and audio parts together.

[defragster]

@CWashburn - posted some Ultimate breakout feedback on other thread ::

>> Is-there-a-third-Teensy-4-0-breakout-board

And post after that >> Is-there-a-third-Teensy-4-0-breakout-board

I just did a HDD USBHost test to external powered Hub&Drive unit. That unit back feeds power back to the attached Host.
>> On T_3.6 the onboard hardware rejects that power.
>> On T4 PJRC Beta breakout and loglow beta board will take feedback power only after the sketch runs to activate the USB hardware - then the T4 stays powers when device USB unplugged

>> On the Ultimate breakout without regard to Host power slide switch - plugging that powered Hub with a HDD in the box immediately lights the white LED and powers the T4 and lights the VUSB power LED.
-- Not saying this is a problem - just different observed behavior from those units. As long as the onboard diode ( yes?) prevents a supply clash this is probably just as well - or better.

[defragster]

Has anyone assembled the Tindie '@CWashburn Ultimate breakout' and seen SDIO work? As noted in above linked posts I didn't get a pin connect - then re-assembled and the pins for SDIO all test good as Hi/LO and not shorted, but CardInfo that works on PJRC Beta breakout fails to find the card.

[mjs513]

Has anyone assembled the Tindie '@CWashburn Ultimate breakout' and seen SDIO work? As noted in above linked posts I didn't get a pin connect - then re-assembled and the pins for SDIO all test good as Hi/LO and not shorted, but CardInfo that works on PJRC Beta breakout fails to find the card.

@defragster - same here - can't seem to get it to work either. Tried BillG's SD-Fat as well.

[CWashburn]

Has anyone assembled the Tindie '@CWashburn Ultimate breakout' and seen SDIO work? As noted in above linked posts I didn't get a pin connect - then re-assembled and the pins for SDIO all test good as Hi/LO and not shorted, but CardInfo that works on PJRC Beta breakout fails to find the card.

@defragster - same here - can't seem to get it to work either. Tried BillG's SD-Fat as well.

That's very strange, I was able to get it working just fine. I wonder if the traces are too long or not well length-matched?

I will do some more testing on this tonight. Can you try reducing the SPI bus speed and see if that makes a difference?

[defragster]

@CWashburn - what did you use to test it? It might work as SPI2?

Using the "...\hardware\teensy\avr\libraries\SD\examples\Car dInfo\CardInfo.ino" with BUILTIN_SDCARD uses it as SDIO 4 data 'SPI' - not normal Mosi&Miso SPI - I've not seen speed adjustment for that?

Last night I was running the USBHost MSC app { github.com/wwatson4506/MSC/ uses github.com/WMXZ-EU/uSDFS } to test HardDrive/FLASH speed - it has support for using the BUILTIN_SDCARD SDIO as well - that same sketch worked on Paul's Beta breakout - and failed to connect using this Ultimate Breakout.
That sketch from above is :: libraries\uSDFS\examples\logger_RawWrite:

#define TEST_DRV 1
// ...
#elif TEST_DRV == 1
  const char *Dev = "1:/";  // SDHC
//…

[KurtE]

@CWashburn, @defragster @mjs513...

I have my ultimate... assembled (2nd time). First time, I had several (0, 2, 5, 6, 23) IO pins that were not working (probably did not sand off the edge enough), so I undid it and reassembled... More pins are working. I need to double check but I don't think it liked pin 12. I did not test all of them...

But Thought I would try the Cardinfo test.

First here is a run off of one of the Beta boards:

Initializing SD card...Wiring is correct and a card is present.

Card type: SDHC

Volume type is FAT32

Volume size (bytes): 65027072
Volume size (Kbytes): 63503
Volume size (Mbytes): 62

Files found on the card (name, date and size in bytes): 
OVERLAYS/     2017-03-03 15:27:06
  AKKORD~1.DTB  2016-05-04 14:10:52 1130
  README        2017-02-15 17:45:56 55994
  ADAU19~1.DTB  2016-05-27 09:20:02 1411
  ADS101~1.DTB  2016-06-22 07:06:02 2425
  ADS784~1.DTB  2016-05-04 14:09:24 2426
  BMP085~1.DTB  2016-05-04 14:33:14 449
  AUDREM~1.DTB  2016-09-22 08:07:36 575
  ALLO-P~1.DTB  2016-10-24 11:41:48 1011
  AT86RF~1.DTB  2016-05-04 14:09:24 1668
  AUDIOI~1.DTB  2016-05-27 09:20:02 787
  DIONAU~1.DTB  2016-09-22 08:07:36 663
  DHT11~1.DTB   2016-05-04 14:09:24 983
 ...
SYSTEM~1/     2017-03-27 15:50:04
  INDEXE~1      2017-03-27 15:50:04 76
  WPSETT~1.DAT  2017-03-27 16:06:40 12

Now to run on the Ultimate board:

Initializing SD card...Wiring is correct and a card is present.

Card type: SDHC

Volume type is FAT32

Volume size (bytes): 65551360
Volume size (Kbytes): 64015
Volume size (Mbytes): 62

Files found on the card (name, date and size in bytes):

So data does not match in sizes and did not find any of the files.

[defragster]

@Kurte - that is farther than I got where the disk was never seen.

Here is the version of PinTest I called HiLow:

HiLowTest.ino

Posted somewhere - startup does all pins pulldown, shows any stuck HI, then probe with 3.3V will show pin hit on SerMon - hitting one should only raise one and it should drop on release.

Send 'Enter' over Sermon and all pins go PullUp ( LED 13 will glow ) - any pin stuck low will print. Then touch GND to any single pin to see it drop o on SerMon and return on release.

Just hit ENTER a couple times for fun - if the pins change with PinMode nothing should print but the test notes.

[defragster]

That's very strange, I was able to get it working just fine. I wonder if the traces are too long or not well length-matched?

I will do some more testing on this tonight. Can you try reducing the SPI bus speed and see if that makes a difference?

How tight are the clamp screws on your board? This last time I held screw and put a bit of turn on the nut with pliers - so more than finger tight - but not that tight.

I just put an allen wrench in the screw and used a hand nut driver and added about 1/2 turn to each {very snug}, then Ran HiLow.ino test on All pins 0-39 all show working {exc:#23}: Single pin changes as expected with touch Hi or Lo and returns to expected state.
Still get just this:

Test logger_RawWrite
uSDFS_VER:30_Jun_19_07_17
BUFFSIZE :32768
Dev Type :1:/
Mount: Failed with rc=FR_DISK_ERR.

// "...\hardware\teensy\avr\libraries\SD\examples\CardInfo\CardInfo.ino"
Initializing SD card...initialization failed. Things to check:
* is a card inserted?
* is your wiring correct?
* did you change the chipSelect pin to match your shield or module?

The first is USBHost code that works on Paul's board and also the FRDM4236 board I had.

The next is from CardInfo using BUILTIN and then these settings to try "regular SPI".
@KurtE - these numbers look to come from the T4 card backside - any idea if they should work - they DO NOT even on Paul's Beta Breakout with CardInfo. ::

const int chipSelect = 36;

void setup()
{
  //UNCOMMENT THESE TWO LINES FOR TEENSY AUDIO BOARD:
  SPI.setMOSI(35);
  SPI.setMISO(34);
  SPI.setSCK(37);

This was tried at :: SPI_FULL_SPEED, SPI_QUARTER_SPEED and the default SPI_HALF_SPEED:

if (!card.init(SPI_HALF_SPEED, chipSelect)) {

[mjs513]

@CWashburn, @defragster @KurtE ...

As an experiment I pushed down on the T4 by the USB connector and the SD Card started working. So I tightened a bit on the nuts by the usb connector and success. From the SD list files:

Initializing SD card...Wiring is correct and a card is present.

Card type: SDHC

Volume type is FAT32

Volume size (Kbytes): 31154688
Volume size (Mbytes): 30424

Files found on the card (name, date and size in bytes): 
SYSTEM~1/     2019-10-24 07:29:32
  WPSETT~1.DAT  2019-10-24 07:29:32 12
  INDEXE~1      2019-10-24 07:29:34 76
121_IM~1.PDF  2019-05-15 14:17:46 238578
CIMMAC~1.PDF  2019-10-15 07:41:30 547151
POINT-~1.PDF  2019-10-15 17:58:08 944066
RGBA_I~1.PDF  2019-10-16 07:50:06 126402
ROBOTI~1.PDF  2019-10-16 08:46:18 9079060
SLVA689.PDF   2019-10-21 09:42:12 161062

Using Bill G's SD-FAT library (note have some debug prints on - forgot to turn them off):

SdFat version: 2.0.0
Assuming an SDIO interface.

type any character to start
init time: 18 ms

Card type: SDHC

Manufacturer ID: 0X3
OEM ID: SD
Product: ACLCD
Version: 8.0
Serial number: 0XA33D2B88
Manufacturing date: 7/2011

cardSize: 31914.98 MB (MB = 1,000,000 bytes)
flashEraseSize: 128 blocks
eraseSingleBlock: true

OCR: 0XC0FF8000

SD Partition Table
part,boot,bgnCHS[3],type,endCHS[3],start,length
1,0X0,0X1,0X1,0X0,0XC,0XFE,0XFF,0XFF,8192,62325760
2,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0
3,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0
4,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0
DBG_FAIL: ExFatPartition.cpp.107

Scanning FAT, please wait.

Volume is FAT32
sectorsPerCluster: 64
clusterCount:      973584
freeClusterCount:  973239
fatStartSector:    9362
dataStartSector:   24576
Files found (date time size name):
2019-05-15 14:17     238578 121_IMAV2016_Proceedings.pdf
2019-10-15 07:41     547151 CIMMACS-03.pdf
2019-10-15 17:58     944066 point-with-scanned-figs.pdf
2019-10-16 07:50     126402 rgba_inclass.pdf
2019-10-16 08:46    9079060 robotics2017-pucca.pdf
2019-10-21 09:42     161062 slva689.pdf

[mjs513]

@CWashbur

One recommendation for the next revision would be to put additional labels next to the audio shield headers - recommend to use the ones Paul used on his breakout board. They came in handy for other purposes.

[KurtE]

@CWashburn, @defragster @mjs513 - I have now tried cranking down the nuts...

@defragster - I also have run your HiLow test which is pretty nice

Obviously pin 23 did not work (as expected). Sometimes pin12, did not work? But then tested again and it did...

Compile Time:: C:\Users\kurte\Documents\Arduino\Teensy Tests\HiLowTest\HiLowTest.ino Oct 24 2019 06:48:50
PULLDOWN Start Vals:
  PULLDOWN :: TEST to 3.3V
  0,0,0,0,0,0,0,0,
d#=8 val=1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,

PULLUP :: TEST TO GND
  d#=0 val=0,
d#=0	 val=1,
d#=0 val=0,
d#=0	 val=1,
d#=1 val=0,
d#=1	 val=1,
d#=2 val=0,
d#=2	 val=1,
d#=2 val=0,
d#=2	 val=1,
d#=3 val=0,
d#=3	 val=1,
d#=4 val=0,
d#=4	 val=1,
d#=4 val=0,
d#=4	 val=1,
d#=5 val=0,
d#=5	 val=1,
d#=6 val=0,
d#=6	 val=1,
d#=7 val=0,
d#=7	 val=1,
d#=8 val=0,
d#=8	 val=1,
d#=8 val=0,
d#=8	 val=1,
d#=8 val=0,
d#=8	 val=1,
d#=8 val=0,
d#=8	 val=1,
d#=8 val=0,
d#=8	 val=1,
d#=9 val=0,
d#=9	 val=1,
d#=10 val=0,
d#=10	 val=1,
d#=10 val=0,
d#=10	 val=1,
d#=11 val=0,
d#=11	 val=1,
d#=13 val=0,
d#=13	 val=1,
d#=14 val=0,
d#=14	 val=1,
d#=15 val=0,
d#=15	 val=1,
d#=15 val=0,
d#=15	 val=1,
d#=16 val=0,
d#=16	 val=1,
d#=16 val=0,
d#=16	 val=1,
d#=17 val=0,
d#=17	 val=1,
d#=18 val=0,
d#=18	 val=1,
d#=18 val=0,
d#=18	 val=1,
d#=19 val=0,
d#=19	 val=1,
d#=19 val=0,
d#=19	 val=1,
d#=20 val=0,
d#=20	 val=1,
d#=21 val=0,
d#=21	 val=1,
d#=22 val=0,
d#=22	 val=1,
d#=24 val=0,
d#=24	 val=1,
d#=25 val=0,
d#=25	 val=1,
d#=26 val=0,
d#=26	 val=1,
d#=27 val=0,
d#=27	 val=1,
d#=28 val=0,
d#=28	 val=1,
d#=28 val=0,
d#=28	 val=1,
d#=29 val=0,
d#=29	 val=1,
d#=29 val=0,
d#=29	 val=1,
d#=30 val=0,
d#=30	 val=1,
d#=31 val=0,
d#=31	 val=1,
d#=31 val=0,
d#=31	 val=1,
d#=32 val=0,
d#=32	 val=1,
d#=33 val=0,
d#=33	 val=1,
PULLDOWN :: TEST to 3.3V
  d#=8 val=1
d#=38 val=1
d#=38 val=0,
PULLUP :: TEST TO GND
  d#=0 val=0,
d#=0	 val=1,
d#=34 val=0,
d#=34	 val=1,
d#=35 val=0,
d#=35	 val=1,
d#=36 val=0,
d#=36	 val=1,
d#=37 val=0,
d#=37	 val=1,
d#=38 val=0,d#=39 val=0,>>> MULTI CHANGE !!

d#=38	 val=1,
d#=39	 val=1,
d#=38 val=0,d#=39 val=0,>>> MULTI CHANGE !!

d#=38	 val=1,
d#=39	 val=1,
d#=38 val=0,d#=39 val=0,>>> MULTI CHANGE !!

d#=38	 val=1,
d#=39	 val=1,
d#=12 val=0,
d#=12	 val=1,
d#=12 val=0,
d#=12	 val=1,

Note: the output in RED. I plugged in a Sparkfun microsd sniffer (https://www.sparkfun.com/products/9419) and when I touched what is DAT2/DAT3 (DAT2,CD) it shows these two pins are shorted out to each other...

[mjs513]

@CWashburn, @defragster @KurtE

I know that I had a devil of a time getting it lined up right on the pins. Sounds like the board may be rotated slightly to the right so that those 2 pins are touching slightly.

What would have been nice is if there were 2 longer pins that would positively align the board with the other pins.

When I placed the board down before I tightened the nuts all the way was to push down on it after I felt that the pins had caught then I did the tightening. But it was all just feeling when it was seated.

[KurtE]

Thanks @mjs513, will try again later. Looking forward to T4++, So far I have not seen any perfect solutions... Probably best for most of my cases to punt on the SDIO pins...

[defragster]

@CWashburn, @defragster @mjs513 - I have now tried cranking down the nuts...

@defragster - I also have run your HiLow test which is pretty nice

Obviously pin 23 did not work (as expected). Sometimes pin12, did not work? But then tested again and it did...

Note: the output in RED. I plugged in a Sparkfun microsd sniffer (https://www.sparkfun.com/products/9419) and when I touched what is DAT2/DAT3 (DAT2,CD) it shows these two pins are shorted out to each other...

Glad HiLow works - the MultiChange report is not perfect - but catches sometimes to notify so I didn't revisit as the change printout would indicate as well. Though reading SerMon and touching those tiny pins not as easy as original test Pin13 light blink. Writing that I could add a MODE for pin13 report and exclude #13 from the test array and have it follow whatever pin changes from PullUp/PullDown and FLASH when two hits in a cycle?

I was wondering about a light solder tin on the T4's SDIO pads? Maybe extra thickness and better surface for the spring contact? Need to do something as it just isn't working.

Indeed using the T4 SDIO pins a chore to get to and get right. They did work well on the FRDM4236 board that soldered very easily! Suppose similar for the OSH Blackketter when I get one. Though the FRDM staggered layout and skipped GND/3.3V makes bridging them easier to avoid.

[mjs513]

@defragster - @KurtE - @@CWashburn

Well just tested USB with wired joystick and it worked as well. Don't have a rev D board to test audio yet - just ordered one.

As @KurtE said - SDIO pins are tough to crack. The breakout boards I put together I decided to punt on the SD Card but does have the USB. Can't wait for the Teensy 4++ with the sd card on board.

[defragster]

@defragster - @KurtE - @@CWashburn

Well just tested USB with wired joystick and it worked as well. Don't have a rev D board to test audio yet - just ordered one.

As @KurtE said - SDIO pins are tough to crack. The breakout boards I put together I decided to punt on the SD Card but does have the USB. Can't wait for the Teensy 4++ with the sd card on board.

Yes, USB works well - glad not just here - so easy!

I noted on the other thread linked above in p#31 and @CWashburn did some reply there in part …

_ pay attentionto the Teensy Shield being FLIPPED - will take atypical mounting?

[mjs513]

Yes, USB works well - glad not just here - so easy!

I noted on the other thread linked above in p#31 and @CWashburn did some reply there in part …

_ pay attentionto the Teensy Shield being FLIPPED - will take atypical mounting?

Thanks for the warning - I didn't see that post. You basically have to mount the Audio Shield upside down which kind of defeats the purpose of the shield or using a prop shield (since I would have to change axis orientation - argh).

[defragster]

Moving from other thread: forum.pjrc.com/threads/57913-Is-there-a-third-Teensy-4-0-breakout-board

Second Breakout posting - was there another thread for this?

The discounted one with missing pin #23 arrived and is now assembled. I did the same PinTest as the FRDM board posted - set all pins PULLDOWN and see that they hold low - then touch 3.3V to each and see that they go high and drop when removed, and no adjacent pins are triggered. Then send USB SerMon 'Enter' and it switches to PULLUP mode - and allows the same testing/reporting using a GND wire to each pin.

ALL pins passed like on the FRDM board - no indicated shorts or sticking pins … except of course the disconnected pin #23 cannot be triggered. This test excludes the SDIO pins #34-39 as they are NOT presented on the board edges.

I tested USB to work with the Ethernet USB adapter dongle to LAN.

PROBLEM: I tested the CardInfo and it FAILS … tried 4 or 5 times and with a second card.

>> In typing this I saw I could use PinTest on the exposed pins #34-39 soldered to the SDIO adapter. Pin #35 is not showing as connected. It will go Neither HI nor LO when touched in testing. I see the pad and I see solder on it but touching the PAD fails to respond at all.

Initializing SD card...initialization failed. Things to check: …

* Putting With SAME IDE code upload and that same SD card onto the PJRC Beta Breakout results in a working read of the files on the card on the root and multiple subdirectories. This card also worked on the FRDM board before it went 'offline'.


NOTES ON: Teensy 4.0 Ultimate Breakout Board

> Had to remove a bit of material from the spacer holder boards - they went from not fitting to plenty snug. I only finger snugged the nuts.
> It wasn't noted as to which of the two under spacers was designed to go on the bottom/middle?
> Would be nice to have pins #34-39 brought to a place to pin as they present an SPI bus, and Serial5.
> I got the minimal board - lots of room for battery and other - but few notes on what these or other things do. Perhaps a clear 'card' image? I need to re-read the printed page … but a picture would be cool.
> The WHITE LED for USBHost power indication is quite bright - of course if not the wrong color everything is either too bright or too dim - except PJRC T4 Bootloader LED is Awesome.
> On Tindie I see the Power input can be up to 18V - putting that on the PCB silkscreen might be easy enough to be a good idea.
> REALLY ODD - Danger :: the Teensy Shield layout is FLIPPED from the T4? First glance I saw the GND end and noted "USB END OUT" - then I noticed VIN and GND are not where expected - it is Flipped not Rotated. This would require putting shield on the bottom? Or making custom shields?

** I'll disassemble the T4 clamp and manually test SDIO pin #35 for connectivity in some hours - maybe the spring clip isn't seated?

<EDIT> :: unclamped the T4 from the Ultimate board. Indeed there is PCB Pin continuity between #35 under T4 and the SD socket, so that single spring pin didn't mate up it seems.

I'll do some more filler PCB relief as it may be bound up - As the Tindie notes says: "If the fit is too tight, run some sandpaper along the edge of the teensy until it fits without too much force."

Second Breakout posting - was there another thread for this?
...

<EDIT> :: unclamped the T4 from the Ultimate board. Indeed there is PCB Pin continuity between #35 under T4 and the SD socket, so that single spring pin didn't mate up it seems.

I'll do some more filler PCB relief as it may be bound up - As the Tindie notes says: "If the fit is too tight, run some sandpaper along the edge of the teensy until it fits without too much force."

Updated above - smoothed the filler PCB board to T4 could better shift. PinTest shows digital function on all pins including the SDIO #'s 34-39

CardIfno still giving failure? No idea why - two cards both work with same upload to PJRC T4 Beta which should match the wiring and setup for "BUILTIN_SDCARD";



NOTES ON {pt 2}: Teensy 4.0 Ultimate Breakout Board:
Found a 12V supply to external USB HDD bay with a fitting connector (not sure of what size is common - but I have 3 non fitting}:
> USB to PC was powering - showing Yellow VUSB power
> Sometimes - plugging external power maintains the VUSB Yellow?
> Unplug both and plug external and get BLUE VIN power
> Plug in USB and it stays BLUE VIN - expected - perhaps it depends on which is higher 5V?
> Unplug External 12V and Blue VIN stays lit with VUSB? Changed when toggled USB Host switch?
> MidBoard chip 'regulator' Hot to touch with 12V external power - it reads 124F or 51 C - nothing connected or soldered to PCB

External power is 12V 3A supply - USBHost Lan Test:
> Upload Ethernet LAN USBHost dongle code - at 600 or 816 MHz - which should work without heat sink.
>> With USB power and External connected with upload it does start - or USB alone as expected
{ Have USB connect dongle with 5v line switch to cut power but leave data and GND to PC }
>> Remove 5V USB power and powered from Ext VIN - T4 restarts/goes offline - will not run from onboard LDO with 12V input? Button will not take to Bootloader?
When running from USB power - switching OFF HOST power the LAN USB dongle shuts down and then when switched on it reattaches to the network. So that says the PCB and USB on USB power are all good, something about running from External VIN with this 12V supply, which as noted is for a long working external USB bare SATA drive connector box .

>> Found another 12V 1.5A supply with fitting plug that has the same behavior. Upload and run with VUSB and VIN it works. Cut the 5V VUSB line and the unit restarts or shuts down in some fashion. At this CPU speed the Host supplied VUSB it always enough.
- reading the Tindie doc it says 300 ma max at 12V - it is running at 600 MHz - just dropped to 528 Mhz and same result. And when VUSB is cut the LDO quickly goes too hot to hold a finger on. And I see the NOTE - Yes the Jumper is 'PREREG' - I wondered what that was for. I was hoping the external supply would be enough to drive even heavier USB Host loads - like a HDD which never work from Host Usb power through Teensy, where the LAN can.

[defragster]

Thanks for the warning - I didn't see that post. You basically have to mount the Audio Shield upside down which kind of defeats the purpose of the shield or using a prop shield (since I would have to change axis orientation - argh).

Yes, that could have been bad if the GND and VIN labels were not appreciated


Moved posts from other thread to above for better review in context.

CWashburn question to above here with notes from that other thread.

I'm assuming that you cut the VIN-VUSB trace on the Teensy, as not separating it could cause some power issues. As for the USB Host power, it isn't designed to receive power through the port, but there is an inline diode, so you should be fine.

I'm not exactly sure what you mean by cutting the VUSB trace. Could you explain in more detail? The LDO shouldn't be overheating just powering the teensy - it's possible that there is a short, but I test all the boards before I ship them.

Yes, the VIN<>VUSB trace was cut. Tested before installing on breakout with DMM on pads and then plugged it in to USB and it did not power.

RE: "Cut the 5V VUSB line " and "when VUSB is cut" :: if you mean that, I have a USB Dongle with a switch on the 5V line from the USB connector. When switched it lights an LED and disconnects the 5V line feeding the Teensy USB connector - but leaves GND and data lines connected.

The Teensy runs when the LDO gets hot, so not going to shutdown - but was surprisingly hot when fed from 12V external - and also disappointing in supplied power being less than onboard T4 from 5V with regard to powering a USBHost connected device. Would hope for at least 700mA.

[KurtE]

@defragster, @mjs513, @CWashBurn...

I disassembled the board for the 3rd and 4th time. I files the sides of the T4 a bit more. I tried to use feel and put each piece in place and then while holding down, put in screws and try to tighten... Turns out my feel was not too good and many pins did not work...

So loosened all of the screws and left the hilow test program running, and I manually moved around the chip and while holding things down retightened all of the screws and all of the normal pins minus 23, worked.

However still it shows 38, and 39 responding with each other... To eliminate that maybe the sparkfun MicroSD explorer was causing the issue in SD card slot, I removed it.

@defragster I added a quick and dirty test for pins shorting out to the one maybe next to it.

void testForShorts() {
  uint32_t ii;
  Serial.print("Quick Test for Shorts to adjacent pin");
  Serial.println("First pull pins down and see if the next one follows");
  for ( ii = 0; ii < NUM_DIGITAL_PINS-1; ii++) {
    pinMode( ii+1, INPUT_PULLDOWN );
    pinMode( ii, OUTPUT);
    digitalWrite(ii, HIGH);
    delayMicroseconds( 5 );
    if (digitalRead(ii+1)) {
      Serial.printf("%d:%d ", ii, ii+1);
    }
  }
  Serial.println("\n Now try Pull up and see if setting low follow");
  for ( ii = 0; ii < NUM_DIGITAL_PINS-1; ii++) {
    pinMode( ii+1, INPUT_PULLUP );
    pinMode( ii, OUTPUT);
    digitalWrite(ii, LOW);
    delayMicroseconds( 5 );
    if (!digitalRead(ii+1)) {
      Serial.printf("%d:%d ", ii, ii+1);
    }
  }
  Serial.println();  
}

I only called it once at startup...

It also complained that those two pins were shorted out., wonder also what is going on with pin 8...

Compile Time:: C:\Users\kurte\Documents\Arduino\Teensy Tests\HiLowTest\HiLowTest.ino Oct 25 2019 17:34:12
Quick Test for Shorts to adjacent pinFirst pull pins down and see if the next one follows
7:8 38:39 
 Now try Pull up and see if setting low follow
38:39 
PULLDOWN Start Vals:
  PULLDOWN :: TEST to 3.3V
  0,0,0,0,0,0,0,0,
d#=8 val=1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
d#=38 val=1,0,

d#=38 val=0,

Wonder what is with pin
I thought I would try the USB, so I loaded our test script mouse.ino which appears to work for this:


USB Host Testing
960
*** Device HID1 46d:c063 - connected ***
manufacturer: DELL
product: DELL USB Laser Mouse
*** HID Device Mouse1 46d:c063 - connected ***
manufacturer: DELL
product: DELL USB Laser Mouse
Mouse: buttons = 0, mouseX = 1, mouseY = -1, wheel = 0, wheelH = 0
Mouse: buttons = 0, mouseX = 6, mouseY = 0, wheel = 0, wheelH = 0
Mouse: buttons = 0, mouseX = 4, mouseY = -1, wheel = 0, wheelH = 0
Mouse: buttons = 0, mouseX = 4, mouseY = -2, wheel = 0, wheelH = 0