Teensy 4.0 Breakout Kit

I added a short header to the breakout - rushing I put it on the bottom instead of the top as intended - opps.

But it works I wired 34,35,36 in sequence jumpered to 37,38,39.

So this code should be alternating the first three between IN/OUTput and the opposite for the second three, then writes either 1 or 0 over time and expects to read the same back.

The code is not only showing FAILURES writing 1's both ways and not getting them - even with the delaymicroseconds between write/read, but the Teensy Restarts on occasion.

I'm not sure the code is doing everything right - it is in the other TempMon sample and being called too fast in batches.

I need to check the pins again …

Code:
uint32_t pinsSDIO[9] = { 34, 35, 36, 37, 38, 39, 34, 35, 36 };
void sdioTest( uint32_t cnt) {
  int ii, mm;
  if ( cnt % 2 ) mm = 0;
  else mm = 3;
  for ( ii = mm; ii < mm + 3; ii++ ) {
    pinMode( pinsSDIO[ii], OUTPUT);
    pinMode( pinsSDIO[ii + 3], INPUT);
  }
  for ( ii = mm; ii < mm + 3; ii++ ) {
    digitalWriteFast( pinsSDIO[ii], (cnt % 4) / 2 );
    delayMicroseconds( 4);
    if ( (cnt % 2) / 2 != digitalReadFast( pinsSDIO[ii + 3] ) ) {
      digitalWriteFast(LED_BUILTIN, !digitalReadFast(LED_BUILTIN) );
      Serial.print('-');
      Serial.print((char)('A'+ii));
      Serial.print(cnt % 2);
      Serial.println((cnt % 4) / 2);
      delayMicroseconds( 400 );
    }
    //else       Serial.print('+');
  }
}
 
News but, - not much good - but I managed to de-solder the ribbon clamp connector with clean pads intact! Dipping clean end of de-solder braid in flux paste is magic! Connector isn't usable though oddly enough with the clamp cut off and segmented the plastic and the one GND end held solder and came off after the rest.

Got back to clean pads between pin soldered T4 and the SDIO connector. I didn't test connector ends before soldering it back down - but after … Pin #36 has 145 Ohm short to 3v3 :( [web calc says that is 22.76 mA] This was showing before - but other stuff must have been wrong too. So no SDIO SD socket 'CLK' or SPI2 CS2 - but pins 34,35,37,38,39 should be usable. This end 'looks' clean so the bridge may be on the other end and I didn't catch it before pinning it under.

Very weird because before this 'edit' going back to KurtE's mod'd PinTest - those pins can do PWM - so maybe it needs an Analog setting where the LED lights at PWM value?
> When powered PinTest #13 blinks as expected.
> setting to 34 stops the blink as expected until wired to 34 - but set on 34 and wiring to 36 Shows it is powered when it should not be. Advancing PinTest to #36 and it blinks the LED - I suppose the #13 LED/resistor helps drop that current?
> Left the wire on 36 once the T4 repowered and it did not wake up. Sitting as I started this post - it just returned after a minute and - just repeated that and it does come up.

I need to clean it now to dry and try it again in the morning. Though my flux paste container says 'non-conductive' - that may not be true after contaminated by solder flux and other solder stuff.
First is the connector Off board and pieces - the second is the Flex ribbon direct soldered after:
FlexOff_000037.jpgFlexAfter_000037.jpg
Though first pic almost shows a shiny spot between 3v3 and #36 --- didn't come out when I tried.
 
Last edited:
Went back with the hot iron solder sucker to try to pull out solder from that edge. Actually the measured resistance was 122 oms not 145. Then I bumped the meter to 2K from 200 range and pin 37 had just over 500 ohm bridge to 3V3 also!

After trying the removal and reflowing with flux paste it was measuring 150 ohms. Since those pads had been used they were tinned but wicked and cleaned - where I had purposefully not tinned the pads on the other end - assuming the solder would flux through the holes as needed and not spread trapped solder under confines of the Flex cable.

Just a guess but 'bridge/short that may be what @mjs513 { maybe @KurtE? } encountered as well given here it shut the T4 OFF and refused to start seeming quite sincerely and not just nearly dead until removed.

@loglow - would it make sense to drop GND and 3V3 from that Flex data cable and route from elsewhere on the PCB? That would drop the Flex cable from 10 to 8 pins - not sure if that would allow upsizing pin spacing/connector on that end of the cable? That doesn't help the T4 end - and my problem may start there if I had the wrong range on the meter when I tested - though that is when I updated and used the PinTest and did not see anomalies then.

I'll update the pintest to have an Analog/PWM mode to the point where it shows on the LED ( and SerMon ) what my DMM is showing me when I see what values I read for the 500 and 120+ Ohm input. And perhaps a 'short' test to adjacent pins when they are OUTPUT and driven HIGH. Did another Alcohol clean and will be dry in the morning to test.
 
Where can I find KurtE's pintest? I looked on GitHub.

It is really nothing special. Defragster has updated it slightly to allow + and - to increment/decrement.

My current allows you to type in pin number, and just hitting enter again increments...
Code:
int current_pin = 13;
int next_pin_number = -1;
#define DBGSerial Serial
void PROGMEM setup()  {
  // Blink any pin.  Note: I put pin 13 as input to see if we can
  // jumper to it to see if we can find the pin...
  while (!Serial && millis() < 5000);
  DBGSerial.begin(115200);
  delay (250);
  DBGSerial.println("Find Pin by blinking");
  DBGSerial.println("Enter pin number to blink");
  DBGSerial.println("Defaults to pin 13");
  pinMode(13, OUTPUT);
}

void loop() {
  // put your main code here, to run repeatedly:
  if (DBGSerial.available()) {
    int ch;
    while (DBGSerial.available()) {
      ch = DBGSerial.read();
      if ((ch >= '0') && (ch <= '9')) {
        if (next_pin_number < 0) next_pin_number = 0; // sort of lame
        next_pin_number = next_pin_number * 10 + (ch - '0');
      } else {
        if (next_pin_number < 0) next_pin_number = current_pin + 1;
        digitalWrite(current_pin, LOW); // turn the previous pin to low...
        current_pin = next_pin_number;
        pinMode(current_pin, OUTPUT);
        if (current_pin != 13)
          pinMode(13, INPUT);
        digitalWrite(current_pin, HIGH);
        next_pin_number = -1;  // setup to enter next pin
        DBGSerial.printf("Now Blinking pin %d\n\r", current_pin);
        while (DBGSerial.read() != -1) ; // get rid of the rest of input
      }
    }
  } else {
    digitalWrite(current_pin, !digitalRead(current_pin));
    delay(250);
  }
}
Edit: should mention, it works that if the pin to blink is not 13, it sets pin 13 to input, so you can then try to jumper whatever pin is supposed to blink to 13 and if working the LED will blink...
 
mod PinTest was hidden as attachment in p#93

T4 breakout dried overnight and seeing pin 37 showing 700 Ohms to 3V3 and pin 36 now at 5K Ohms to 3V3. Pin #36 looks much better.

Pin #36 not on when 34 blink - but it is ON when 35 blink? … May not get to it for some hours for more or code update ...
 
checked the connections between the flex and the breakout (flex wasnt soldered to teensy yet) and they are good. did a clean of the breakout with the 91% I have (ordered 99%) and it looks much better now :) found a tiny pair of tweezers to put the resistors on, (are they needed?) trimed the 2x5 header for the bottom of the teensy, will trim the top part so its flush with the other headers on the t4
 
@firehopper - those resistors are only needed or used when the indicated BUS ( i2c or SPI ) actively uses those pins and the resistors apply a pull-up for those pins. If those pins are put to other purposes the resistors could impair function when pulled up.

I just tried SDIO SD and it still fails with the 'crosstalk'. And pintest exhibits new but similar strangeness - blink of #35 turns #36 on? Not done an exhaustive study or looked more yet.

I went back to the TempMon code with the HACK to write 34/35/36 and read 37/38/39 and then swap that. The problem may have been the comparison on reading '1'. Altered that test part of the code to use intermediate kk:
Code:
  uint32_t kk = (cnt % 4) / 2;
  for ( ii = mm; ii < mm + 3; ii++ ) {
    digitalWriteFast( pinsSDIO[ii], kk );
    delayMicroseconds( 4);
    if ( kk != digitalReadFast( pinsSDIO[ii + 3] ) ) {

After the last cleanup and removing the cable connector and reflowing running that test has not resulted in T4 restart given the short of pins to 3V3 was made higher impedance - can't use SDIO for SD but the T4 seems stable and no going bricked.
>> Running nearly an hour and no more Crash Restarts or T4 hangs on my 'SDIOTmpMonTest' - shows RTC persist and does the self pin test.

@loglow - would it make sense to add 0.10" to the PCB length to put space between the FLEX and SDIO solder pads? That extra 0.10" would aid in cleaner solder access and could then present GND and 3V3 pins to feed the rails when they are used - or just extra takeoff points when rails are not used. If those pads are in the same area the same 3V3 and GND signals could also hopefully route directly to the SDIO/SD pads and not share the cable. Shorted data lines could still hurt the build - but not render the T4 'bricked.

BAD NOTE: I can no longer see the USB Dongle to SD working. So the resolder cleanup of the cable resulted in loss of the USB lines :(
 
Last edited:
ah well then I wont put them on yet. need to make sure all the pins are working first. waiting for my socket kit to be shipped/get here.


@firehopper - those resistors are only needed or used when the indicated BUS ( i2c or SPI ) actively uses those pins and the resistors apply a pull-up for those pins. If those pins are put to other purposes the resistors could impair function when pulled up.

I just tried SDIO SD and it still fails with the 'crosstalk'. And pintest exhibits new but similar strangeness - blink of #35 turns #36 on? Not done an exhaustive study or looked more yet.

I went back to the TempMon code with the HACK to write 34/35/36 and read 37/38/39 and then swap that. The problem may have been the comparison on reading '1'. Altered that test part of the code to use intermediate kk:
Code:
  uint32_t kk = (cnt % 4) / 2;
  for ( ii = mm; ii < mm + 3; ii++ ) {
    digitalWriteFast( pinsSDIO[ii], kk );
    delayMicroseconds( 4);
    if ( kk != digitalReadFast( pinsSDIO[ii + 3] ) ) {

After the last cleanup and removing the cable connector and reflowing running that test has not resulted in T4 restart given the short of pins to 3V3 was made higher impedance - can't use SDIO for SD but the T4 seems stable and no going bricked.

@loglow - would it make sense to add 0.10" to the PCB length to put space between the FLEX and SDIO solder pads? That extra 0.10" would aid in cleaner solder access and could then present GND and 3V3 pins to feed the rails when they are used - or just extra takeoff points when rails are not used. If those pads are in the same area the same 3V3 and GND signals could also hopefully route directly to the SDIO/SD pads and not share the cable. Shorted data lines could still hurt the build - but not render the T4 'bricked.

BAD NOTE: I can no longer see the USB Dongle to SD working. So the resolder cleanup of the cable resulted in loss of the USB lines :(
 
okay, so put the headers on, and the flex cable, according to the pintest, the only pin I'm having issues with is 24. I need to re solder that one and see if it comes back
all the pins on the flex I could test work. does the D+ and D- have arduino pin numbers I can use with the test program?
 
Wow, thanks everyone for all the detailed tests and replies here!

Just wanted to pop in and say that I'm away from home until late on Wednesday (9/18) so I won't be able to ship anything else out until then. I might be able to reply a bit more in the meantime, but I'm not sure how much. That aside, I'll reiterate that I'm more than happy to send out additional breakout kits, components, and/or socket kits to any of you. I super appreciate all the testing and feedback!

I've ordered some of the top-loading style battery holders to test out.

Also, future kits are going to include different screws and some new standoffs too:
- 8x M2 x 4 mm pan-head phillips-drive machine screws
- 4x M2 x 6 mm brass female threaded hex standoffs

I'm looking forward to taking a bunch of macro photos and starting to put detailed build instructions together later this week.
 
@loglow - safe travels. Standoffs sound outstanding, the ones I have are too large for the holes provided.

I didn't get back to the iron to check on USB line(s) I lost - will be another day - they look so nice and bright in p#152 above, using the connecter they were very Dull and cold looking - I did look at the card and see earlier notes were based on the pin order to SDIO socket - not off the cable labels where I was actually working. From left the low measured resistance was between 4&5 [D-&36] and 5&6 [3V3&D+]. Those were the trouble spot before when USB worked. I just checked and the Flex cable across the T4 end for USB pins looks secure.

With that spacing the best 'directions' might indicate : slide off SDIO hood, solder SDIO pins, solder the Flex end - reinstall the SDIO hood and solder. Except it seemed there may not be room to get the hood in using the Flex cable connector? That hood gets in the way of soldering the connector if installed first. Obscene to say so but adding the 0.10" there would allow that to work better for more reliable builds?

Paul posted a unique freq sketch on each SDIO pin during Beta, that would be good to resurrect. Easy to test with DMM probe and see a value.

It seems I saw something about a way to excite the USB pins - but that may be a false memory as I never did it and wouldn't know how to find it.
 
@loglow - As @defragster mentioned, have a good safe trip...

Again would like to try out the newer setup, I probably need whole new everything (I do have more T4s...)

It will be interesting to see how those different battery holders work, in particular how high are they and does it make sense to use them if you are setting up to try to plug into breadboard. The current battery holder does not work if you put in headers pointing down... At least I don't think there is any room to put battery in or take it out later... Would maybe work if it could be rotated 90 degrees, but then don't think there is room to put the battery holder pads down....

@defragster, @firehopper - As to test USB pins... Run one of the USBHost_t36 sketches like one of the mouse or keyboard ones and plug in device... I can not try that one as well my ribbon ... These pins are special and do not have Digital IO capabilities.

I should probably look up the actual pins again and put them on my XLS document. But they were very specific to USB pins.
 
Help!!!

I seem to have bricked my T4 by simply pressing the mini-tactile power on/off switch!!! I simply tried it as part of the debugging of the breakout, and the T4 turned off after the five seconds but won't turn on again! :( :mad: Was on Vusb power. Unplugging/plugging USB doesn't help. The compiler cannot find the board, nor can the Teensy Loader. It's dead, dead, dead...

The on/off pin on the T4 board is sitting at 3v and is taken low when I press the switch - so that's not the problem.
There is +5v on the Vin pin, but nothing on the 3.3v (which I think is appropriate)

Any suggestions on unbricking (please)?
 
@firehopper, @dkryder - Thank you so much - that worked. I didn't even remove the Teensy from the breakout, just held down program button as suggested, and it came back to life :D I didn't know about that trick - is it documented somewhere?
 
its documented in a lots of places.. its a anti brick thing programmed in the bootloader, and supposedly its a feature of all teensy's I think.
 
okay, so resoldered pin 24 and it too functions. so now just need the low profile headers from loglow and then I can test the rest of it, btw if you put a thin bit of paper on the top side of the flex, it will hold better in the socket on the breakout. might also get better connections.. I havent had any major issues with mine but then again I havent tried a sd card or a usb device yet :)
 
okay, so resoldered pin 24 and it too functions. so now just need the low profile headers from loglow and then I can test the rest of it, btw if you put a thin bit of paper on the top side of the flex, it will hold better in the socket on the breakout. might also get better connections.. I havent had any major issues with mine but then again I havent tried a sd card or a usb device yet :)

Reading of the Flex Connector loose fit I wasn't going to use - but mine locked in tight - no wiggle - no play, so I soldered it … have since removed it :(

So far the 15 second Restore is T_3.5/3.6 and 4.0 where in Beta the T_3.6 showed some ability to lose some settings and then T_4's added complexity the same.

Holding the Button on USB plug is a common help so the bootloader stops any crashing user code from getting to that point.
 
@loglow (and others) - Again it will be interesting to try again. I am still undecided if I feel like the current flex cable is more or less easy to install and or error prone as compared to using the connector Paul used for the beta release boards.

The thing that was sort of scary was I felt like I was soldering sort of blind. Hard to hand hold the ribbon to the T4 and try to inspect that everything is correct...

Some of my concerns and or places I think I can and maybe did screw up on my first attempt to solder the ribbon include:

a) If the ribbon is not exactly positioned, such that the pads are exactly aligned with the pads on the board and/or the ribbon has even a very slight angle as compared to the T4, it is easy that one end of the other of the pads will short out to the pad next to it, especially if you used solder flux and maybe a little too much solder.

b) There are 3 test points on the T4 That are between the SD pins and the USB pins. again if for example you did not position the pads of the ribbon to exactly match the start and stop of the pads on the T4, then maybe one or more of these pads could short out to either SD or USB pads. Especially again if you used too much flux and solder. Not sure also if any vias could also be issues?

c) not sure what would happen if either the D+ or D- pads solder would short out to one of the main USB connectors mounting holes which are pretty close?

Ways to resolve?

a) Maybe detailed instructions, with warnings about exact placement?

b) Maybe first cover the test points, USB mounting holes with some form of insulation? Like Tape? Or liquid?

c) Make the flex cable such that maybe you don't solder through it, but instead shorten the pad part of ribbon to solder on like some displays do directly to their mounting boards. Again if you are soldering in from the far end of SD pins, they are the farthest from test points.

c2) But then there are the USB pads. Not sure if you could have the 2 USB pins be such that there is a cut out on the cable such that you could solder through that cut out to the front of the USB pads, which again are farthest from test points. Obviously you would need to reroute the other two signals that went between these two and likely have to reroute it on your breakout board as well. Question is, if you stay with 10 signals there or go down to 8 by dropping 3.3v and GND as you can get those elsewhere.

Again I like the idea of not blind soldering but seeing where I soldered and hopefully see any obvious solder bridges.

As for the main board, the SD adapter. Are there instructions on how one is expected to solder them? Example are you supposed to try to remove the cover and replace it after?

I know there are lots of trade offs here? Also not sure if there are alternatives to this adapter that has the same size, but you solder it from the front instead of the rear? i.e like the ones that Paul used on his breakout boards? Problem with the one he used is they are a lot wider so would not fit in the space you have. But postive of them is again they solder from the other side, so much easier to deal with soldering of both the ribbon connector and the SD....
 
i remember @loglow saying a some point that if you don't solder the flex to his data pads the host won't work yet i do not understand why i could not use maybe 30g wire from the data pads on the teensy to the data pads on the loglow breakout and also use a regular 8 pin flex. is it because the data signal would degrade through the thin wire? i see pictures of some of the beta work had thin wire used for some patches. or even run a short wire patch from the loglow flex to the board data pads. to be honest after reading the experiences i waiting for price points on unpopulated vs populated boards because earlier he said he would be willing to offer populated boards and if that included a soldered flex, that would a consideration.
 
@dkryder - I am not an expert here, but here is my two cents. You can probably hook up the USB pads of the T4 to his external D+/D- pins to get the USB to work.

However I am pretty sure using a straight 8 pin flex won't work, as the signals are split up...

Pardon this marked up copy of his cable image, I was playing around with ideas...

Flex_Cable_Mod.jpg

If you follow the two wires coming off of the USB part, you will see that they are in the middle of the 10 pin connector and split apart, so an 8 pin straight through would not work...

Also note: when I was playing with the image, I thought maybe hole in center of flex where blue is such that can solder the end on... I still think that might be a valid possibility? But if I were to do so, might suggest the cutout on other side of USB, to solder to edge of the pad closest to edge of Teensy. Again giving greatest separation from the solder point to test points and the like... But again would require rerouting the IO pins for the ones that were routed between the pads, which would probably change order on the one on breakout board...
 
@KurtE, thanks. you are correct. i had not realized it but the flex is not optional, it's a must have. only option is host/no host and if you want host then solder flex to board OR maybe wire the T4 /breakout data pads or wire from breakout pads to the flex data line holes. but that's probably just as challenging.
 
For the cable - taking drawing above for a quick hack in paint - removing the 3v3 and GND would help with the trouble observed here - and particularly the lockups maybe it wasn't a current problem but the current feeding to USB?

The problem I have it on the PCB end where there are too many connects in too tight a space resulting in bad connector soldering - or then iffy and shifting cable soldering to PCB. This might help the connector soldering with two pads not present - if the pin were clipped - for sure Flex direct to board would have less opportunity to bridge between or wick under with pin shifting to isolate the USB pads - and the SDIO 6 pads without GND and 3V3.
FlexSpace.png

* now non-symmetric and requires PCB change
 
Back
Top