Teensy 4.0 First Beta Test

[mxxx]

If you can do another test, to check whether the 12V supply's startup is a factor (difference between starting up the 12V supply while connected, versus pre-starting the 12V supply and then plugging it into the 5V regulator) that info would really help me to know whether I should focus more testing effort on the 5V stuff. I do have some LM1117 chips here, but they're all 3.3V, not 5V. I can get the 5V one in a few days, but maybe it's really that 12V 2.4A supply I need?

i'll hook up the 12V supply when i get back from work. what i can say is that the board does boot up properly when i hot-plug the 5V regulator (i.e., with pre-started 12V, only then plugging the 5V regulator), so yes, it doesn't seem to be the LM1117 per se that's causing problems. that said, so far i've tried with three different makes of 12V supply, it happens with all of them. fwiw, the one used in the picture above comes with this; it's in fairly common use with synth people, i'd assume.

[KurtE]

@Paul... I wonder if it is the same issue with the T3.6 that had issues booting up with some BECs including: https://smile.amazon.com/gp/product/B000MXAR12/
Which I had used on other Teensy boards, RPI, ...

It also appeared to mainly (only) happen if you just plug it in. I used them before with Robot where there is a LIPO 3S battery, going to a toggle switch, which connects up to the servos, and somewhere there, you then power up the BEC to hopefully power up the Teensy board.

[PaulStoffregen]

Unlikely to be related to Teensy 3.6. Since I have all this set up on my desk, I'll take another look at Teensy 3.6 soon, but getting this resolved for T4 is my top priority since it'll soon be holding up the next PCB spin.

This new chip has a special power supply called SNVS (secure non-volatile storage). It does much more than just run the RTC. NXP's documentation warns it needs to be powered up before or together with 3.3V power. On the beta1 boards, I have 3 schottky diodes combining VBAT, 3.3V, and the USB 3V regulator output.

I'm pretty sure what's happening here is related to the ~0.4V forward drop of the schottky diode. When 5V and 3.3V rise fast enough, the SNVS input comes up together with the 3.3V power. But when they rise very slowly, the SNVS input is ~0.4V "behind" the 3.3V power. Here's a capture of the case where the chip fails to start up.



That first little step, where the blue waveform comes up to not quite even 0.5V, but the SNVS input is stuck down near 0.1V appears to be the critical problem.

Amazingly, the chip *really* isn't starting up at a hardware level. Notice the top red trace stays at 0 volts. That's the output of the DC-DC switcher that supplies the CPU and most logic. The chip's startup circuitry isn't even turning on the built in DC-DC power supply.

After digging deeper into this, I'm pretty sure the PMIC_ON_REQ approach is going to fully solve this issue. The 3.3V regulator remains completely off during this critical startup. The on-chip USB regulator gets 5V power and creates ~2.5V output, which the schottky diode gives to the SNVS input (assuming no coin cell on VBAT). When the chip gets only SNVS power (and apparently USB power is also ok - saw a mention elsewhere the USB regulator is completely separate from the rest of the chip's startup sequence) it is able to boot up. The PMIC_ON_REQ signal has a 1M pullup resistor to the SNVS input, so it can't turn on until the SNVS input has power.

Here's the startup sequence when the 3.3V regulator is turned on by that pullup resistor to SNVS input.



I'm still wondering if there should be some attempt to delay the 3.3V startup? Right now I've only got one 12V supply that starts up so slowly to make this problem happen. I've done about a hundred tries, and the PMIC_ON_REQ way always starts up, the 3.3V always enabled was never works with that slow powerup ramp.

[KurtE]

Unlikely to be related to Teensy 3.6. Since I have all this set up on my desk, I'll take another look at Teensy 3.6 soon, but getting this resolved for T4 is my top priority since it'll soon be holding up the next PCB spin.

Sound good to me. Just thought I would mention it as it might be another good test case for the T4... Maybe I will try to find where I have one of these laying around (Amazon said I purchased two of them ) But the last one was back in 2015. But they still sell them and they are shown as an "Amazon Choice"

[mxxx]

I'm still wondering if there should be some attempt to delay the 3.3V startup? Right now I've only got one 12V supply that starts up so slowly to make this problem happen. I've done about a hundred tries, and the PMIC_ON_REQ way always starts up, the 3.3V always enabled was never works with that slow powerup ramp.

should i try to hack my board for PMIC_ON_REQ and see if that helps? just to make sure: i'd put a 2.2M or so resistor between the two test-points (= pull-up), and populate the second 0402 resistor to the right of the 3v3 regulator (+ remove the other one); which values would work? i think the smallest 0402 one i have here is 220R.

[mjs513]

T4 FLEXCAN

Know this is a little off topic right now but just wanted to put it out there but I got the FLEXCAN working on the T4 using the sdk drivers. Did a dump and now tonton81 and I can start work on the real library for the T4. Hopefully will be able to support FD as well.

[defragster]

T4 FLEXCAN

... I got the FLEXCAN working on the T4 using the sdk drivers. Did a dump and now tonton81 and I can start work on the real library for the T4. Hopefully will be able to support FD as well.

@mjs513 > That is good news! If that had avoided efforts to come online it would have been bad.

[mjs513]

Sound good to me. Just thought I would mention it as it might be another good test case for the T4... Maybe I will try to find where I have one of these laying around (Amazon said I purchased two of them ) But the last one was back in 2015. But they still sell them and they are shown as an "Amazon Choice"

I just ordered one and should be here on Thursday - just not sure of the hookup for it:
gnd-gnd
5v - vin

But would think you have to use serial4 to see if it came on line - not sure if plugging a usb cable at the same time is an issue?

[defragster]

I just ordered one and should be here on Thursday - just not sure of the hookup for it:
gnd-gnd
5v - vin

But would think you have to use serial4 to see if it came on line - not sure if plugging a usb cable at the same time is an issue?

Yes Serial4 monitor - or/also - simple Blink test with no connects. It seems 5V on Vin only as without cutting 5V from USB Plugging in USB would subvert the test giving it normal power - and also present the dueling supplies conflict.

<edit> Note: That VIN will directly feed USBHost as well - so make sure it is dialed down to 5V [4.8-9.0 Volts selectable output ]. Also that might be an added test as that 5V will be present and shared to USBHost devices at the same time the MCU is getting up to 3.3V, and using external 5V to drive that USBHost would be called for when sharing limited USB power would fall short.

[mjs513]

Yes Serial4 monitor - or/also - simple Blink test with no connects. It seems 5V on Vin only as without cutting 5V from USB Plugging in USB would subvert the test giving it normal power - and also present the dueling supplies conflict.

<edit> Note: That VIN will directly feed USBHost as well - so make sure it is dialed down to 5V [4.8-9.0 Volts selectable output ]. Also that might be an added test as that 5V will be present and shared to USBHost devices at the same time the MCU is getting up to 3.3V, and using external 5V to drive that USBHost would be called for when sharing limited USB power would fall short.

Will keep that all in mind - don't want to fry by 1052 - getting rather attached to it

The dueling supplies was really my concern - having that trace there on the T3.x was nice to have for designs.

Have to give it a test with something plugged into the usbhost connector for a test.

[Frank B]

Paul, can you post the position of the pads on the bottom? I need to make a (beta-)board for my own project, and I need some pogo-pins. Since the boards need 3 weeks, it would be good to order them now.

[PaulStoffregen]

Ok, here goes. These coordinates are in mils (1/1000th of an inch), relative to the bottom left corner (near the main GND pin), when the board it viewed transparent from the top.

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
USB2 D+, x=72, y=305
USB2 D+, x=72, y=395
SD DAT1, x=340, y=527.17
SD DAT0, x=340, y=483.86
SD GND, x=340, y=440.55
SD CLK, x=340, y=394.24
SD 3.3V, x=340, y=353.94
SD CMD, x=340, y=310.63
SD DAT3, x=340, y=267.32
SD DAT2, x=340, y=224.02

[Frank B]

Wow, thank you. The position of the main GND? (To check if my offsets are correct) - I'll post the eagle-library when I checked everything..

[Frank B]

Main GND: Is it x=50 / y=50 ? (Corner = 0/0)

[PaulStoffregen]

Yes, main GND pin is at x=50, y=50.

[mjs513]

Ok, here goes. These coordinates are in mils (1/1000th of an inch), relative to the bottom left corner (near the main GND pin), when the board it viewed transparent from the top.

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
USB2 D+, x=72, y=305
USB2 D+, x=72, y=395
SD DAT1, x=340, y=527.17
SD DAT0, x=340, y=483.86
SD GND, x=340, y=440.55
SD CLK, x=340, y=394.24
SD 3.3V, x=340, y=353.94
SD CMD, x=340, y=310.63
SD DAT3, x=340, y=267.32
SD DAT2, x=340, y=224.02

Just to confirm should this be

USB2 D+, x=72, y=395

D- instead of D+

[PaulStoffregen]

D- instead of D+

Opps, yes, copy & paste error! They can't both be D+. The one at y=395 is indeed D-.

[manitou]

Adafruit_nRF8001 still "to be done"

Teensyduino has its own copy of Adafruit_nRF8001 lib. It gets compile errors for Teensy 4 beta, because of
const char PROGMEM *p = (const char PROGMEM *)ifsh;
declared in print() function in Adafruit_BLE_UART.cpp. (In T4, PROGMEM is a linker section attribute .progmem)
I tried commenting out PROGMEM, then i got compile errors for EIMSK (not emulalted in T4?).

It turns out 2 years ago Adafruit updated their version of nRF8001 lib to support non-AVR MCU's (eliminates EIMSK usage for non-AVR). So I tried working with latest Adafruit_nRF8001 lib https://github.com/adafruit/Adafruit_nRF8001
I confirmed new lib worked on T3.2 with echoDemo example on iPhone, BUT I could not get it to work with T4 -- I tried different things to eliminate PROGMEM declaration in function ...

Maybe someone else can get it working.

[PaulStoffregen]

much like T3.6 (but unlike T3.2). in the latter case, to make sure the thing boots up properly, a/the solution is/was to use a supervisor (e.g. MIC803) and connect that to the "reset" pin ( + pullup).

I've committed a fix for the crash on Teensy 3.6 when the power ramps too slowly.

https://github.com/PaulStoffregen/co...a9dd9e14a0daf0

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

[mjs513]

Adafruit_nRF8001 still "to be done"


Maybe someone else can get it working.

@manitou = what breakout board are you using. You know Adafruit is recommending to:

Please note! We still manufacture and support the nRF8001 Bluefruit module sold here, but we really recommend going with the fresh new Bluefruit LE nRF51822 based modules,

[KurtE]

Ok, here goes. These coordinates are in mils (1/1000th of an inch), relative to the bottom left corner (near the main GND pin), when the board it viewed transparent from the top.

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
USB2 D+, x=72, y=305
USB2 D-, x=72, y=395
SD DAT1, x=340, y=527.17
SD DAT0, x=340, y=483.86
SD GND, x=340, y=440.55
SD CLK, x=340, y=394.24
SD 3.3V, x=340, y=353.94
SD CMD, x=340, y=310.63
SD DAT3, x=340, y=267.32
SD DAT2, x=340, y=224.02

Hi Paul (and others), I used the above data to see what the layout would look like in a diptrace pattern, where I started off with a T3.2 pattern, removed some of the other stuff and added this stuff in.

Although it might be a long time before T4 released and get hand on new 1062 version, it would be great to maybe make a simple Robot controller to experiment with...

I assume since the first posting said NO PICTURES, that you don't want me to post image of the diptrace pattern I created?

But doing so I wondered a few things:
Pins 24-33 The positions you give here. Are these the positions you would use for POGO pins, like maybe center of pads, or are these more like the positions of holes to put for T3.2ish like surface mount pins, where the holes are more toward the center of the board and the pads go out from there?

Recommended size for Pogo pin pads and holes? (more generic question).

If you were goint to setup board to connect to USB2, would you setup to use POGO pins? Or???

Not sure best setup for SD card. Do you have recommendations on sizes of pads?

Thanks

Kurt

[manitou]

@manitou = what breakout board are you using. You know Adafruit is recommending to:

I have other bluetooth modules. I was trying to get ye ol nRF8001 working, because it was on the TODO list in post #4. I have no vested interest in its support.

[mxxx]

I've committed a fix for the crash on Teensy 3.6 when the power ramps too slowly.

https://github.com/PaulStoffregen/co...a9dd9e14a0daf0

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

sure (can't do it before Saturday though ..., i'm out of town for work)

[mjs513]

Opps, yes, copy & paste error! They can't both be D+. The one at y=395 is indeed D-.

@Paul - know this may sound like a silly question but the dimensions you gave - those are for the current 1052 or the new 1062 board? If 1052 then I messed something up as usual

[PaulStoffregen]

Those coordinates are for the (planned) final locations on the 1062 board.

I should also emphasize, while unlikely at this point, those coordinates could still change. The PCB layout is not yet finalized.