Teensy 4.0 Breakout Kit

Was thinking about removing it tomorrow if I can get it off
Adding flux or solder to heat both ends at once from the side … it might push or lift off

This works to see about 0.4V between pins. But using Hz measure on that Meter mjs513 also got the same freq appears on pairs of pins 34/35, 36/37, 38/39 ? Not sure if that is from shared timers?
Code:
FASTRUN void sdioTestFreq( uint32_t cnt) {
  int ii, nn;
  for ( ii = 0; ii < 6; ii++ ) {
    nn = 1 + ii;
    analogWriteFrequency( pinsSDIO[ii], nn * 200 );
    analogWrite( pinsSDIO[ii], nn * 32 );
  }

  while(1);
}

Will have to find the PAUL freq code ...
 
TallDog Beta T4 Breakout : USB HDD within a POWERED HUB

TallDog Beta T4 Breakout : USB HDD within a POWERED HUB ( orinco unit tested on MSC thread - 'logger_RawWrite' )

WORKS at 8 MB/s with 8K(*4) buffer and 12.8 MB/s bumping to 16 or 24 K DWORD buffer.

This unit will not Feed power back until it is run once to init USB connect with T4 USB powered - then if Teensy is unplugged it backfeeds power through USBHost adapter and keeps the Teensy 4 running - so far with no smoke or issues on the breakout in test.

I have a USB Dongle that cuts the 5V power line - leaving the data/GND lines in place so it continues to do t_sermon as if externally powered when restarted/programmed - t_sermon is detecting a drop on the switchover but the Hub/Drive maintain power.

This is a NEW / OLD ~2013 Toshiba 120GB drive pulled from a Laptop when disk was replaced.

Just switched to standard powered HUB and an SSD drive used in MSC test before… test started and stalled - not seen that before on PJRC breakout with this test code.

There is something else HINKY - USB HDD/SSD on powered HUB won't start on first power up it seems? I have to reprogram and then it works? Never saw whatever this behavior is in DOZENS of drive swaps and many more test runs using the PJRC breakout USB host testing the same code - and don't see it now.

@loglow: just conjecture but maybe something about that tiny USB power chip? If swapped for the same larger pitch 8 pin unit Paul used - and having to grow the PCB at least 0.10" to fit it looks like.
 
Ok. This morning did 2 things. Removed the pull-up resistor on pin 36 and replaced the TPD chip, didn't like how I did it before. Really need to use the larger style version that @defragster mentioned.

Same results on the SD Card, if I use spi pins not BUILTIN_SDCARD - that doesn't seem to work at all.

Tried USB and that just doesn't work for me. Maybe some debugging later but...…...
 
Found Paul's freq change T4_Beta post #2443 updated for 1062 in FAST IO mode. Included here in updated code with a mod - when xx=2 at file top. Two other modes noted in code, xx=0 is the initial and xx=1 is the above p#203 shows voltage change:

Oddly Paul's code shows same volts on 5 of 6 pins - it reads 0.7V higher on my pin #36 ???

Code:
[ATTACH]17629[/ATTACH]

@...
Using Paul's freq sketch in the referenced post I am getting these values (kHz)
Code:
34  - 1.85-1.9
35  - 3.73
36  - 7.48
37  - 14.98
38  - 3.73
39  - 1.857-1.9

not sure what that means

@firehopper - thanks.
 
@...
Using Paul's freq sketch in the referenced post I am getting these values (kHz)
Code:
34  - 1.85-1.9
35  - 3.73
36  - 7.48
37  - 14.98
38  - 3.73
39  - 1.857-1.9

not sure what that means

@firehopper - thanks.

On T4_TDB {TallDogBreakout} here the Paul values are each a UNIQUE Double or Half of one of the other pins! That pin #38 is not looking right matching #35.

Running Paul w/xx=2 kHz from cheap meter below {same you got @mjs513?}::
Bottom of a bare Prod T4 in KHz { voltages on all pins is 1.799 }:
34: 1.26
35: 2.51
36: 5
37: 9.97
38: .32
39: .63

Edge pins of T4 TDB in KHz { voltages on all pins but noted #36 are 1.794 or 1.795 }:
34: 1.26
35: 2.51
36: 5 {2.58 to 2.63 V ???}
37: 9.97
38: .32
39: .63

Prod T4 bare - for xx = 1 these voltages:
34: .45
35: .89
36: 1.35
37: 1.80
38: 2.25
39: 2.70

T4 TDB for xx = 1 these voltages:
34: .45
35: .89
36: 1.63 to 1.80
37: 1.80
38: 2.25
39: 2.69
 
@defragster. Strange just can't figure out why it doesn't work when it should unless its the sd card socket itself?
 
@defragster. Strange just can't figure out why it doesn't work when it should unless its the sd card socket itself?

If your voltages/freq's are not seen as similar to 'Prod T4' in post #210 I can only assume T4 damage or assembly issue - bridges, Flux or other artifacts affecting the results?
> your test equip may give diff ranges - but on Paul's Freq they should come out to the multiples in p#210, and the voltages should probably be similar across pins - and if you have a fresh Production T4 that works to test SDIO pads.

Test xx=0 for the cross wired self test pointed to #36 early - but working now - though the other two tests both show something odd about that SDIO CLK pin - which I'm assuming is why SD won't work here.

This T4 seems busted for SD so until I can build in another socketed T4 of the same or updated TDBreakout I'm going to skip this and do a better job of DMM testing during assembly - which will be easier with socketed T4 - then start with the SDIO tests to cable end in this sketch before connecting to PCB, then connect cable and test before adding any SD devices and then USB.
 
I know there are a lot of EE types who understand a lot more about the stuff like cross talk and the like. And I know some of my own boards have probably lots of issues.

So take this for what it worth (very little). Could it be that some of these IO pins are routed pretty close together for a distance?

If you look closely at the images, like:
T4-breakout-SD-Card-pins.jpg

So these pins 34-39 route pretty close to each other and some of them route really close to bottom of pins near them.
Example 34 routes just under pin 35. Likewise 35 routes real close to 36... Now I solder those pins in from above there. So could any of this cause these signals to talk a little?

But again, just throwing some darts!
 
So far I haven't gotten my t4 to read SD cards. Using the updated sdfat for t4. The same program reads the SD card I tried on the t4 on a t3.6 all my SD pins seem to work on the t4 breakout, is there something wrong with the layout maybe? I don't have the t4 mounted yet only have the flex in the socket. Waiting for the low profile headers to mount it. Don't think that's it but it might be.
 
So far I haven't gotten my t4 to read SD cards. Using the updated sdfat for t4. The same program reads the SD card I tried on the t4 on a t3.6 all my SD pins seem to work on the t4 breakout, is there something wrong with the layout maybe? I don't have the t4 mounted yet only have the flex in the socket. Waiting for the low profile headers to mount it. Don't think that's it but it might be.

Tried the new SDFAT library yesterday as well and using SDIO just didn't work. I tried the new lib in the PRJC breakout board so I know it works as well. Cleaned up the solder around the SD socket so the lines up straight and still no joy. No idea on what to try next.
 
@mjs513 - As mentioned previously my SDCard/USB connection is toast, so I am not much help here...

If mine was at the stage yours is? I would plug in either the Sparkfun microsd sniffer (https://www.sparkfun.com/products/9419) or one of the similar ones I made for T3.6 testing and again check the IO pins...

Then If I were real brave, I wonder if maybe the IO pins associated with the SD are too long or the like to work with how they are configured.
That is if you look at NXP_SDHC.cpp for SDHC_InitGPIO (line 833)
Code:
 static void SDHC_InitGPIO(void)
  {
      IOMUXC_SW_MUX_CTL_PAD_GPIO_SD_B0_04 = 0; //DAT2  
      IOMUXC_SW_MUX_CTL_PAD_GPIO_SD_B0_05 = 0; //DAT3  
      IOMUXC_SW_MUX_CTL_PAD_GPIO_SD_B0_00 = 0; //CMD   
      //3.3V                                           
      IOMUXC_SW_MUX_CTL_PAD_GPIO_SD_B0_01 = 0; //CLK   
      //GND                                           
      IOMUXC_SW_MUX_CTL_PAD_GPIO_SD_B0_02 = 0; //DAT0 
      IOMUXC_SW_MUX_CTL_PAD_GPIO_SD_B0_03 = 0; //DAT1 
  
      [COLOR="#FF0000"]const uint32_t CLOCK_MASK = IOMUXC_SW_PAD_CTL_PAD_PKE |
                                  IOMUXC_SW_PAD_CTL_PAD_DSE(1) |
                                  IOMUXC_SW_PAD_CTL_PAD_SPEED(2);[/COLOR]
  
      const uint32_t DATA_MASK = CLOCK_MASK |
                                 (IOMUXC_SW_PAD_CTL_PAD_PUE | IOMUXC_SW_PAD_CTL_PAD_PUS(1));
  
      IOMUXC_SW_PAD_CTL_PAD_GPIO_SD_B0_04 = DATA_MASK;
      IOMUXC_SW_PAD_CTL_PAD_GPIO_SD_B0_05 = DATA_MASK;
      IOMUXC_SW_PAD_CTL_PAD_GPIO_SD_B0_00 = DATA_MASK;
      IOMUXC_SW_PAD_CTL_PAD_GPIO_SD_B0_01 = CLOCK_MASK;
      IOMUXC_SW_PAD_CTL_PAD_GPIO_SD_B0_02 = DATA_MASK;
      IOMUXC_SW_PAD_CTL_PAD_GPIO_SD_B0_03 = DATA_MASK;
  }
You see maybe Drive Strength of 1 What happens if you try changing this to higher DSE?
 
@mjs513 - As mentioned previously my SDCard/USB connection is toast, so I am not much help here...

If mine was at the stage yours is? I would plug in either the Sparkfun microsd sniffer (https://www.sparkfun.com/products/9419) or one of the similar ones I made for T3.6 testing and again check the IO pins...

Then If I were real brave, I wonder if maybe the IO pins associated with the SD are too long or the like to work with how they are configured.
That is if you look at NXP_SDHC.cpp for SDHC_InitGPIO (line 833)
Code:
 static void SDHC_InitGPIO(void)
  {
      IOMUXC_SW_MUX_CTL_PAD_GPIO_SD_B0_04 = 0; //DAT2  
      IOMUXC_SW_MUX_CTL_PAD_GPIO_SD_B0_05 = 0; //DAT3  
      IOMUXC_SW_MUX_CTL_PAD_GPIO_SD_B0_00 = 0; //CMD   
      //3.3V                                           
      IOMUXC_SW_MUX_CTL_PAD_GPIO_SD_B0_01 = 0; //CLK   
      //GND                                           
      IOMUXC_SW_MUX_CTL_PAD_GPIO_SD_B0_02 = 0; //DAT0 
      IOMUXC_SW_MUX_CTL_PAD_GPIO_SD_B0_03 = 0; //DAT1 
  
      [COLOR="#FF0000"]const uint32_t CLOCK_MASK = IOMUXC_SW_PAD_CTL_PAD_PKE |
                                  IOMUXC_SW_PAD_CTL_PAD_DSE(1) |
                                  IOMUXC_SW_PAD_CTL_PAD_SPEED(2);[/COLOR]
  
      const uint32_t DATA_MASK = CLOCK_MASK |
                                 (IOMUXC_SW_PAD_CTL_PAD_PUE | IOMUXC_SW_PAD_CTL_PAD_PUS(1));
  
      IOMUXC_SW_PAD_CTL_PAD_GPIO_SD_B0_04 = DATA_MASK;
      IOMUXC_SW_PAD_CTL_PAD_GPIO_SD_B0_05 = DATA_MASK;
      IOMUXC_SW_PAD_CTL_PAD_GPIO_SD_B0_00 = DATA_MASK;
      IOMUXC_SW_PAD_CTL_PAD_GPIO_SD_B0_01 = CLOCK_MASK;
      IOMUXC_SW_PAD_CTL_PAD_GPIO_SD_B0_02 = DATA_MASK;
      IOMUXC_SW_PAD_CTL_PAD_GPIO_SD_B0_03 = DATA_MASK;
  }
You see maybe Drive Strength of 1 What happens if you try changing this to higher DSE?

Morning @KurtE

You must be reading my mind. Have a sniffer on order so I can check the pins - should be here tomorrow afternoon.

Was thinking about the DSE as well but wasn't brave enough to change it yet. Cleaned up a bit of the solder on the flex cable on the T4 end - have to recheck everything then maybe.
 
@KurtE

Tried changing both DSE and Speed but no luck. Now I just tried attaching a SD Card reader to SPI2 and defined connections in SD Cardinfo as:
Code:
const int chipSelect = 36;

void setup()
{
  //UNCOMMENT THESE TWO LINES FOR TEENSY AUDIO BOARD:
  SPI.setMOSI(35);  // Audio shield has MOSI on pin 7
  SPI.setSCK(37);  // Audio shield has SCK on pin 14
  SPI.setMISO(34);
No luck with SPI2 either. (those pins did ring out using BlinkAnyPin. As a test I hooked it up to SPI (10,11,12,13) and it worked fine.

EDIT: Put LA on 34-36: only pin that work was 36(CS) all other pins stayed high (no sd card attached).
 
Last edited:
@KurtE

Tried changing both DSE and Speed but no luck. Now I just tried attaching a SD Card reader to SPI2 and defined connections in SD Cardinfo as:
Code:
const int chipSelect = 36;

void setup()
{
  //UNCOMMENT THESE TWO LINES FOR TEENSY AUDIO BOARD:
  SPI.setMOSI(35);  // Audio shield has MOSI on pin 7
  SPI.setSCK(37);  // Audio shield has SCK on pin 14
  SPI.setMISO(34);
No luck with SPI2 either. (those pins did ring out using BlinkAnyPin. As a test I hooked it up to SPI (10,11,12,13) and it worked fine.

EDIT: Put LA on 34-36: only pin that work was 36(CS) all other pins stayed high (no sd card attached).

That won't work on SPI! It needs to be SPI2...
Note: the SPI2.setMosi and like don't do much of anything as we only have one pin defined for each of these...

But I assume somewhere you tried SPI2.begin(), along with SPI2.beginTransaction(....)
As SPI2.transfer(0); for example without doing beginTransaction will fail (unless you grab my later stuff).

EDIT: also as a sanity test, have you tried running the same with one of the T4 beta breakout boards? I know I had a display running earlier on SPI2 off of the Sparkfun adapter...
 
@mjs513 I confirmed that my current stuff works for an ST7789 display hanging off of the last T4 beta board is working ...
 

Attachments

  • st7735_t3_graphictest-190920a.zip
    3.1 KB · Views: 71
@mjs513 I confirmed that my current stuff works for an ST7789 display hanging off of the last T4 beta board is working ...

@KurtE
That's good news. Will have to give it a try later - playing with the little one right now :)
 
That won't work on SPI! It needs to be SPI2...
Note: the SPI2.setMosi and like don't do much of anything as we only have one pin defined for each of these...

But I assume somewhere you tried SPI2.begin(), along with SPI2.beginTransaction(....)
As SPI2.transfer(0); for example without doing beginTransaction will fail (unless you grab my later stuff).

EDIT: also as a sanity test, have you tried running the same with one of the T4 beta breakout boards? I know I had a display running earlier on SPI2 off of the Sparkfun adapter...

Don't assume - no -to be honest didn't think about it. Was actually thinking about hooking up one of the displays to test it out.
 
I just posted on the @blackketter OSH T4 breakout thread where an SD extension board was made for the SDIO pins - where I wondered about caps or other needed.

For background ref I replied with this link where @onehorse made 'Super Fast Micro SDIO Card Reader Add-On for Dragonfly STM32L476' and shows his schematic:
… onehorse alternate store for Tlera and found this that has caps on 4 data wire SPI - but on data and CLK lines in schematic image: tindie.com/products/tleracorp/sdio-card-reader-for-dragonfly/

Not sure how he came up with that design - but it worked for him. I know @loglow design has some caps - but didn't see how they are integrated?
 
That won't work on SPI! It needs to be SPI2...
Note: the SPI2.setMosi and like don't do much of anything as we only have one pin defined for each of these...

But I assume somewhere you tried SPI2.begin(), along with SPI2.beginTransaction(....)
As SPI2.transfer(0); for example without doing beginTransaction will fail (unless you grab my later stuff).

EDIT: also as a sanity test, have you tried running the same with one of the T4 beta breakout boards? I know I had a display running earlier on SPI2 off of the Sparkfun adapter...

Ok - couldn't resist. Just ran this as a test:
Code:
void loop() {
  // put your main code here, to run repeatedly:
  SPI2.beginTransaction(SPISettings(10000000, MSBFIRST, SPI_MODE0));
  digitalWrite(36,LOW);
  SPI2.transfer(0);
  SPI2.transfer(0);
  digitalWrite(36,HIGH);
  SPI2.endTransaction();
  delay(1); 
}
with the following results:
Capture.JPG
So would say SPI2 has life in it.

UPDATE: Hooked up a SSD1351 display to spi2 and ran graphicstest without a problem.
 
Last edited:
dat2 is 312.5 hz
dat3 is 156.5 hz
cmd is 5.0 khz
3v is 3.36volt
clk is 2.50 khz
gnd is gnd
dat0 is 1.25 khz
dat1 is 625 hz

so I know the teensy side is working. however it looks to be a bad routing. the connections at the socket are not where they should be going.

okay so if you look at the bottom of a micro sd card, with the connections to the right
pin 1 at the top

pin 1 is dat 2
pin 2 is dat 3
pin 3 is cmd
pin 4 is vdd aka 3.3 volt
pin 5 is clk
pin 6 is vss aka gnd
pin 7 is dat 0
pin 8 is dat 1

now if you flip it over pin 8 is now at the top and the connector should have it this way
pin 8
pin 7
pin 6
pin 5
pin 4
pin 3
pin 2
pin 1
but it doesn't it has pin 1 at the top. so its not working due to the connections being at the wrong places!
basicly. the connections to the sd card is..

sd card pin 8 (dat1) is connected to teensy pin 39 (dat2)
sd card pin 7 (dat0) is connected to teensy pin 38 (dat3)
sd card pin 6 (gnd) is connected to teensy pin 37 (cmd)
sd card pin 5 (clk) is connected to teensy pwr (3.3v)
sd card pin 4 (3.3v) is connected to teensy pin 36 (clk)
sd card pin 3 (cmd) is connected to teensy gnd
sd card pin 2 (dat3) is connected to teensy pin 35 (dat0)
sd card pin 1 (dat2) is connected to teensy pin 34 (dat1)

so these breakouts will not work with sd cards the usb is fine..

this is why its not working :)

oh another note, the breakout card I have. reflects this info. not the proper way it should be..

tada! firehopper saves the day :) okay. I'm a bit sleep deprived, been up since 2am because I had to be at work at 6 am and couldnt sleep anymore :)
 
Back
Top