Teensy 4.0 First Beta Test

Status
Not open for further replies.
Those coordinates are for the (planned) final locations on the 1062 board.

Thanks Paul.
I should also emphasize, while unlikely at this point, those coordinates could still change. The PCB layout is not yet finalized.
Should have asked earlier - was laying out against my breakout board and things looked shifted against the 1052 layout. Know this is funny but can you tell me the coordinates of the Vin pin - looks like the width is going to wind up narrower. Know I saw it somewhere - 0.7 between edge pins?
 
TPS2055A circuit for T4
I pulled the spec but a little unsure of the connections = I put together a crude schematic and was wondering if someone could give me a sanity check before I lay it out in kicad?
Picture1.png
 
@mjs513 and @Paul...

Again to be clear and with full understanding that everything could change:
The bottom pins:
Code:
Pin 24: x=1182, y=550
Pin 25, x=1018, y=550
Pin 26: x=1182, y=450
Pin 27, x=1018, y=450
Pin 28: x=1182, y=350
Pin 29, x=1018, y=350
Pin 30: x=1182, y=250
Pin 31, x=1018, y=250
Pin 32: x=1182, y=150
Pin 33, x=1018, y=150
These positions would be for using POGO pins to connect up.

If instead you wish to use surface mount connector like: https://www.digikey.com/product-detail/en/samtec-inc/TSM-105-01-S-DV-TR/SAM14832CT-ND/9595124
The x Positions would probably be 1018 -> 1050 and the 1182 -> 1150 I think?

That is they are in line with Pin 9 and Pin 10 (A2 A1)
 
Paul- if the SD pads work out as mapped on T4 - is the T4 planned to ship with SD socket in place?

Kurt - that seems like it could simplify the soldering - That part seems same/cheaper than single pogo pins sourced in bulk from AliExpress - and maybe less heat stress/risk in soldering those and working.

Were you picturing the SMD POGO soldered to T4 or to the daughter board? On the other end of the board is the USBHost connect - is there a good solution for that? If it is similar and the SMD POGO is on the T4 - that could interfere with SD card insert/removal so I suppose they would be on the breakout.

...
Not sure if we'll do a similar breakout board for the 1062 boards. By that point, we'll be pretty close to release and I'll probably be focused again almost entirely on the software side, so a fancy breakout board for the 1062 boards seems unlikely.

With a little coordination and review when the 1062 layout gets set - there could be a 'fancy' breakout to share in short order: USB2 and all bottom pins with POGO's to get to the SD space.
 
If instead you wish to use surface mount connector like: https://www.digikey.com/product-detail/en/samtec-inc/TSM-105-01-S-DV-TR/SAM14832CT-ND/9595124
The x Positions would probably be 1018 -> 1050 and the 1182 -> 1150 I think?

That is they are in line with Pin 9 and Pin 10 (A2 A1)

Those pads are indeed designed for that sort of J-lead style header. That's the reason why they're centered at 1018 & 1182. The J bend shape needs long pads that are located beyond the 0.1 inch spacing of the header's rows.

Believe me, I would have loved to use smaller pads (like were on the 1052 betas)... the larger ones on the final board create large no-via zones that make the PCB routing difficult. But not nearly so hard as the BGA escape routing.


Paul- if the SD pads work out as mapped on T4 - is the T4 planned to ship with SD socket in place?

Nope. And to be honest, fitting a SD socket onto the bottom side is awkward at best. I wish I could have allocated more room, but there's only so much I can accomplish on this small board.
 
Nope. And to be honest, fitting a SD socket onto the bottom side is awkward at best. I wish I could have allocated more room, but there's only so much I can accomplish on this small board.

Can a SD socket be mounted at all below the board?
if yes, OK.
if not, maybe think about a 1 mm spacing (instead of 1.1 mm microSD spacing) as there are 1mm connectors around (I adapted one for T4 beta by bending the pins).
 
Those pads are indeed designed for that sort of J-lead style header. That's the reason why they're centered at 1018 & 1182. The J bend shape needs long pads that are located beyond the 0.1 inch spacing of the header's rows.

Believe me, I would have loved to use smaller pads (like were on the 1052 betas)... the larger ones on the final board create large no-via zones that make the PCB routing difficult. But not nearly so hard as the BGA escape routing.

I can imagine. So I updated my Diptrace file to setup for the J pins.

Again it would be great to hear a little more on what pad shapes and holes people have found good for the pogo pins. (Thanks Frank for earlier response!) I think it was boards by OneHorse that I found nice in that the pads were not round but sort of extended out a ways to make it easier to solder in the pogo.

Can a SD socket be mounted at all below the board?
if yes, OK.
if not, maybe think about a 1 mm spacing (instead of 1.1 mm microSD spacing) as there are 1mm connectors around (I adapted one for T4 beta by bending the pins).

Actually what I am wondering about is what Signal pins are these? I can hopefully go through PDF files and guess. That is it would be interesting to see what other capabilities these PINS have and if they are useful for other things, how hard would it be to then break them out. Some standard adapter/connector like the J pins? Or some way to setup pogo pins, maybe offset from each other?
 
@mjs513 > That is good news! If that had avoided efforts to come online it would have been bad.

Hi Tim - just saw this - jumping around too much I guess. Glad I got it working too - was frustrating. I did manage to get tonton81's WIP library working as well on Can2 - haven't tested CAN1 though. Really was only able to get that working because I did the SDK port. Tony's is a lot easier to use.
 
@Paul and others,

To maybe answer my own question about SDIO pins? I am assuming you are using SDHC1 pins? and not SDHC2...
If so then looking at the MUX for GPIO_SD_B0_00 through _05

MUX for GPIO_SD_B0_00:
Code:
000 ALT0 — Select mux mode: ALT0 mux port: USDHC1_[COLOR="#B22222"]CMD [/COLOR]of instance: usdhc1
001 ALT1 — Select mux mode: ALT1 mux port: FLEXPWM1_PWM0_A of instance: flexpwm1
010 ALT2 — Select mux mode: ALT2 mux port: LPI2C3_SCL of instance: lpi2c3
011 ALT3 — Select mux mode: ALT3 mux port: XBAR_INOUT04 of instance: xbar1
100 ALT4 — Select mux mode: ALT4 mux port: LPSPI1_SCK of instance: lpspi1
101 ALT5 — Select mux mode: ALT5 mux port: GPIO3_IO12 of instance: gpio3
110 ALT6 — Select mux mode: ALT6 mux port: FLEXSPI_A_SS1_B of instance: flexspi

MUX for GPIO_SD_B0_01:
Code:
000 ALT0 — Select mux mode: ALT0 mux port: USDHC1_[COLOR="#B22222"]CLK[/COLOR] of instance: usdhc1
001 ALT1 — Select mux mode: ALT1 mux port: FLEXPWM1_PWM0_B of instance: flexpwm1
010 ALT2 — Select mux mode: ALT2 mux port: LPI2C3_SDA of instance: lpi2c3
011 ALT3 — Select mux mode: ALT3 mux port: XBAR_INOUT05 of instance: xbar1
100 ALT4 — Select mux mode: ALT4 mux port: LPSPI1_PCS0 of instance: lpspi1
101 ALT5 — Select mux mode: ALT5 mux port: GPIO3_IO13 of instance: gpio3
110 ALT6 — Select mux mode: ALT6 mux port: FLEXSPI_B_SS1_B of instance: flexspi

MUX for GPIO_SD_B0_02
Code:
000 ALT0 — Select mux mode: ALT0 mux port: USDHC1_[COLOR="#B22222"]DATA0[/COLOR] of instance: usdhc1
001 ALT1 — Select mux mode: ALT1 mux port: FLEXPWM1_PWM1_A of instance: flexpwm1
010 ALT2 — Select mux mode: ALT2 mux port: LPUART8_CTS_B of instance: lpuart8
011 ALT3 — Select mux mode: ALT3 mux port: XBAR_INOUT06 of instance: xbar1
100 ALT4 — Select mux mode: ALT4 mux port: LPSPI1_SDO of instance: lpspi1
101 ALT5 — Select mux mode: ALT5 mux port: GPIO3_IO14 of instance: gpio3

MUX for GPIO_SD_B0_03
Code:
000 ALT0 — Select mux mode: ALT0 mux port: USDHC1_[COLOR="#B22222"]DATA1[/COLOR] of instance: usdhc1
001 ALT1 — Select mux mode: ALT1 mux port: FLEXPWM1_PWM1_B of instance: flexpwm1
010 ALT2 — Select mux mode: ALT2 mux port: LPUART8_RTS_B of instance: lpuart8
011 ALT3 — Select mux mode: ALT3 mux port: XBAR_INOUT07 of instance: xbar1
100 ALT4 — Select mux mode: ALT4 mux port: LPSPI1_SDI of instance: lpspi1
101 ALT5 — Select mux mode: ALT5 mux port: GPIO3_IO15 of instance: gpio3

MUX for GPIO_SD_B0_04
Code:
000 ALT0 — Select mux mode: ALT0 mux port: USDHC1_[COLOR="#B22222"]DATA2[/COLOR] of instance: usdhc1
001 ALT1 — Select mux mode: ALT1 mux port: FLEXPWM1_PWM2_A of instance: flexpwm1
010 ALT2 — Select mux mode: ALT2 mux port: LPUART8_TXD of instance: lpuart8
011 ALT3 — Select mux mode: ALT3 mux port: XBAR_INOUT08 of instance: xbar1
100 ALT4 — Select mux mode: ALT4 mux port: FLEXSPI_B_SS0_B of instance: flexspi
101 ALT5 — Select mux mode: ALT5 mux port: GPIO3_IO16 of instance: gpio3
110 ALT6 — Select mux mode: ALT6 mux port: CCM_CLKO1 of instance: ccm

MUX for GPIO_SD_B0_05
Code:
000 ALT0 — Select mux mode: ALT0 mux port: USDHC1_[COLOR="#B22222"]DATA3[/COLOR] of instance: usdhc1
001 ALT1 — Select mux mode: ALT1 mux port: FLEXPWM1_PWM2_B of instance: flexpwm1
010 ALT2 — Select mux mode: ALT2 mux port: LPUART8_RXD of instance: lpuart8
011 ALT3 — Select mux mode: ALT3 mux port: XBAR_INOUT09 of instance: xbar1
100 ALT4 — Select mux mode: ALT4 mux port: FLEXSPI_B_DQS of instance: flexspi
101 ALT5 — Select mux mode: ALT5 mux port: GPIO3_IO17 of instance: gpio3
110 ALT6 — Select mux mode: ALT6 mux port: CCM_CLKO2 of instance: ccm

So they do look interesting to me, as they can be additional GPIO pins and have full LPUART8, I2C3, ...
 
To maybe answer my own question about SDIO pins? I am assuming you are using SDHC1 pins?

Yes, confirmed, the bottom side pads (which are on the 1052 boards in reverse order) are indeed GPIO_SD_B0_00 to GPIO_SD_B0_05.

Just a quick reminder, those coordinates are not 100% finalized. I ordered another small size SD socket that looks more promising for a better fit. If it works better, I might move things around slightly before the final board rev.
 
@Paul
When you issue the new 1060 boards are you planning are retaining support for the 1052 board? Was thinking it might be advantageous for debugging to retain until kickstarter, i.e., communications between two similar T4s but then again maybe not? Just curious.
 
Yes, confirmed, the bottom side pads (which are on the 1052 boards in reverse order) are indeed GPIO_SD_B0_00 to GPIO_SD_B0_05.

Just a quick reminder, those coordinates are not 100% finalized. I ordered another small size SD socket that looks more promising for a better fit. If it works better, I might move things around slightly before the final board rev.
Sounds great, totally understand they are not finalized yet, also probably awhile before I see one...

But the exercise is (Diversion) giving me ideas of things that I may want to add to my own boards plus things that we may want to add to core/libraries.
Like UART8 is already used for Serial5, on different pins, but maybe should allow setTX and setRX to these pins.

SPI1 - I believe is not currently setup at all... so this could be 2nd or 3rd SPI

Wire - I think these would be duplicates of other pins so setSCL/setSDA...

Obviously up to 6 more GPIO pins can always come in handy...
 
When you issue the new 1060 boards are you planning are retaining support for the 1052 board?

I don't have this 100% planned out. But I can tell you 2 things for sure...

1: Any non-beta Teensyduino installers will have lines in boards.txt commented for any beta hardware. So even if everything else is in place, at the very least you'll need to edit boards.txt.

2: Eventually support for the 1052 will be dropped.

I don't have anything like a roadmap or clear plan for how 1052 will be phased out. But it'll probably look like libraries and bootloader updates (I have several planned) only targeting 1062. It's probably not going to look like suddenly ripping out all the #if defined(__IMXTR1052__) from the code... at least not for quite some time. Things that work today will (probably) keep working on 1052 for quite some time, maybe even into 2020? But if there is a compelling technical need for change, of course doing the things needed for non-beta boards & software are always the main priority.
 
Installed IDE 1.8.9 and TD 1.46b10 and a couple simple T4 compiles working.
T4 still stalls on Serial use while SerMon inactive.
Did a Verify build of Audio/analyze/FFT from IDE and FrankB's Compile.cmd :: Hex files identical, same build size and results. Both Verify builds at 30 seconds - seems faster than last I timed an Audio build, maybe diff INO.
 
I've committed a fix for the crash on Teensy 3.6 when the power ramps too slowly.

https://github.com/PaulStoffregen/cores/commit/1b1f95315f6de10e03c3acc64ba9dd9e14a0daf0

Any chance you could give this a try on your Teensy 3.6 with the MIC803 chip disconnected from the reset pin?

perfect, works!

(fwiw: using LM1117-5, as above. i've tried with two different 12V supplies, it'll come up every time now; previously it wouldn't boot at all without the MIC803)

re T4: should i try with the PMIC_ON_REQ hardware modification (as per #1910)? sounds simple enough, just not entirely sure what value that 0402 resistor should be.
 
re T4: should i try with the PMIC_ON_REQ hardware modification (as per #1910)? sounds simple enough, just not entirely sure what value that 0402 resistor should be.

Sure, give it a try. Just make sure you populate only 1 of those 402 resistors at a time.

Pretty much any resistor value should work, since the input impedance of the regulator is very high. The input leakage current spec in TI's datasheet is an incredibly low 10 nA. But I'd recommend using no higher than 10K. On some of the boards we used 0 ohms, on other 22 ohms. 220 ohms should be perfectly fine.

I still haven't decided how I want to handle the pullup resistor. Startup sequencing is even better with no resistor at all. But then you can lose power in certain scenarios when PMIC_ON_REQ goes high impedance. NXP's documentation on PMIC_ON_REQ leaves a lot to be desired (or figured out by experimentation & guesswork). I put some extra test points on a couple of the boards on the next prototype.

If you do the mod, I'd recommend a 1M resistor between PMIC_ON_REQ and the always-on power test point (the one closest to pin 12).
 
Sure, give it a try. Just make sure you populate only 1 of those 402 resistors at a time.

Pretty much any resistor value should work, since the input impedance of the regulator is very high. The input leakage current spec in TI's datasheet is an incredibly low 10 nA. But I'd recommend using no higher than 10K. On some of the boards we used 0 ohms, on other 22 ohms. 220 ohms should be perfectly fine.

I still haven't decided how I want to handle the pullup resistor. Startup sequencing is even better with no resistor at all. But then you can lose power in certain scenarios when PMIC_ON_REQ goes high impedance. NXP's documentation on PMIC_ON_REQ leaves a lot to be desired (or figured out by experimentation & guesswork). I put some extra test points on a couple of the boards on the next prototype.

If you do the mod, I'd recommend a 1M resistor between PMIC_ON_REQ and the always-on power test point (the one closest to pin 12).

ok, just removed the 22R resistor and populated the other pad with 220 ohms and ... it works (i didn't add the 1M pull-up yet).
 
- What is the disadvantage of using the USB host without the TPS2055A? (connecting power to USB#0)
- Are there solderpads for the flash quadspi -signals on the new beta-board (+additional cs) ? (sorry for asking this again.. I think I missed your answer ;-)
 
Last edited:
- What is the disadvantage of using the USB host without the TPS2055A? (connecting power to USB#0)

Chips like TPS2055A, together with a 100 to 220 uF capacitor, give you better (but still imperfect) support for hot plugging USB devices when running from very limited power, like the 5V from another USB cable.

If you omit those parts, you'll have USB power delivery similar the many cheap USB host shields sold for Arduino's boards. Some of those shields even send the 3.3V power rather than 5V to their USB host ports, which isn't enough for some types of USB devices to run (the USB spec says ~4.4V min, or ~4.0V for unpowered hubs). Many people are happy with those shields, which seems amazing to me since they're all designed so badly for their USB power delivery, but I guess that just goes to show that you don't always need to do things well.

The main issue is hot plugging USB devices. So if you make something where the USB device is permanently connected, or you're sure it will not be plugged in while the power is turned on, then this stuff is much less important.

When you do hot plug a USB device, it's discharged capacitors are suddenly connected to the charged (hopefully to 5V) capacitors on the USB host. Let's assume the cable is a short & perfect wire, so we can ignore all the complexities of resistance & inductance. When you short 2 capacitors together, electrons flow between them until both are at the same voltage. If one was initially discharged, the final result will be both at a lower voltage than the charged one started, because some of its charge was transferred to the other capacitor.

The USB spec says devices shall have no more than 10uF, unless they have some sort of inrush limiting circuit that restricts the current so the initial hot plug is no more than the equivalent of a 10uF capacitor in parallel with a ~50 ohm resistor. The spec also says hosts shall have at least 120 uF capacitance. The idea is to limit that "final voltage" drop, so the host doesn't reboot or crash.

The TPS2055A helps in many ways. First, if you're getting power from a USB cable, it limits the current charging the 100-220 uF capacitor you use, so you're meeting (or close to meeting) the USB spec when you plug into your PC. Second, it helps prevent Teensy from crashing if you plug in a bad USB device with more than 10 uF, like an Arduino with shield having lots of extra capacitors. If a hot plug event drains your host-side capacitor, that TPS2055A prevents it from dragging down Teensy's power too, so you gain a lot of resilience to crashing during hotplug events.

So the disadvantage of USB host without a current limiter chip like TPS2055A or TPD3S014 is USB hot plug events will tend to brown-out your power, causing Teensy to crash or reboot, and if you try to compensate by adding capacitors, you'll just move the problem to making your Teensy-based board put too much load on your PC.


- Are there solderpads for the flash quadspi -signals on the new beta-board (+additional cs) ? (sorry for asking this again.. I think I missed your answer ;-)

No.
 
Thanks :) I've ordered 10pcs.. did not find any source in Germany, so they'll come from china in 1-2 month :(

I guess I can connect the Display-LED-backlight and a small audio-AMP to the "out"-pin, too?
 
Status
Not open for further replies.
Back
Top