Teensy 4.0 First Beta Test

Status
Not open for further replies.
Got mine today! 3 days earlier than expected (USPS notifies me even when the label was printed). I'll be doing some testing tonight!
 
Paul - hope all going well with the test fixture - a teensy Teensy mechanical marvel - with exhaustive test pass to get right to assure full function!

I expect you've seen my notes on Externally Powered T4B2 unit? Other than you I suppose I'm the first to unsolder the blob and assure a cut in that VUSB<>VIN.

When doing that I was using a DMM to confirm it was open, and the cheap meter at hand kept registering some non zero resistance - so I cut some more and then quit and AFAIK no power is crossing that bridge.

Question: Are there any components that would hold power and confuse my meter readings as I crossed back and forth over those two pads? Or is there some downstream connection that would explain that?


I ask because of the 'external power' feeding USB/RTC when Teensy USB to HOST PC is unpowered - that is also kept alive by the same UART on I/O pins that caused the brown out restart issue. Without comment from you I don't know if this is expected/acceptable behavior.

The other issue is the fact that USB doesn't reconnect to PC when 5V is dropped {and the MCU has enough power to keep it alive by external means} - but hoping that is just a hang in the USB stack code? I suppose I am deficient in testing as on that T4B2 unit I did not put a debug monitor on Serial4 and record any messages.

Just put the powered Orico Hub/Drive box on the T4B2m - as soon as USB cable is PULLED it then supplies external power to the T4 and the Disk Write test continues. Restoring the USB cable does not restore USB connect to Host PC below is what the Serial4 debug output shows. [*Note using the inline switch that just cuts 5V power to host PC - the external drive box keeps the USB connect alive to serial Monitor without a break.] So it seems the USB stack never sees the drop and then never reconnects as it stays powered up?
Code:
USB1_TXFILLTUNING=00000000
USB reset took 6 loops
analogInit
usb_serial_reset
usb_serial_configure
usb_cdc_line_coding, baud=0
before C++ constructors
after C++ constructors
before setup
usb_cdc_line_coding, baud=0
usb_cdc_line_coding, baud=115200
usb_cdc_line_coding, baud=115200
after setup
usb_serial_reset
usb_serial_configure
usb_cdc_line_coding, baud=115200
usb_cdc_line_coding, baud=0
usb_cdc_line_coding, baud=115200
usb_cdc_line_coding, baud=115200
usb_serial_reset
usb_serial_configure
usb_cdc_line_coding, baud=115200
usb_serial_reset
usb_serial_configure
usb_cdc_line_coding, baud=0
usb_cdc_line_coding, baud=0
usb_cdc_line_coding, baud=115200
usb_cdc_line_coding, baud=115200

*Note 2: same test on T_3.6 USBHost port does not do this as it won't backfeed power from the Orico Hub/Drive device. I did not try that with external power … The T_3.6 I have cut VUSB<>VIN doesn't have HOST connector pins on just now.


@xxxajk - yes the USPS 'Informed Delivery' is good for getting tracking numbers as soon as 'big brother' sees the label printed. Very cool you got it before the holiday break!
 
Paul one more note to add along the lines of post #2977.

T4B2m powered and connected to debug Teensy UARTS on Serial 2 and 4. Nothing connect to USB Host port or elsewhere.

Pulling USB cable or using inline 5V USB power cut switch the T4 loses full power, but as noted before that COOL Breakoutboard green LED is glowing healthfully at less than half bright - fed by the UARTS.

When in this 'unpowered' state a 5 second press on the On/Off breakout button will turn the T4 OFF - there is a momentary dim on the green LED glow.
{ And another short press in this unpowered OFF state will also in fact turn the Power back to the ON (indicated by a minor increase in green LED glow) state when the T4 is given 5V USB power }

Plug in USB or switch the 5V USB line back on { the green LED diminishes to a much fainter glow } and the Teensy is OFF. Press the Breakout button and the T4 turns on as if it were turned off under normal power.

Except for the troubled user not seeing the T4 power up when power was applied (when Power Off pin hit GND 5 secs) - as long as this doesn't indicate a power handling issue it is just a functional note because you did post:
My biggest concern for testing is the powerdown circuitry. On the 1052 betas, the 3.3V power was always on. With this new board, the 3.3V regulator can be completely turned off. Power remains applied to the USB regulator, and its output feeds the SNVS regulator (which controls the power management stuff).
… Unlike the 1052 beta, please don't worry too much about bricking or damaging your board. We'll have plenty more in just a few weeks.
 
One possible use of GPT1 is for FreqCount (pin 25 is the external trigger). Here is a proof-of-concept (32-bit counter)
https://github.com/manitou48/teensy4/blob/master/gpt_count.ino
Jumper PWM pin 11 to 25 for testing.

GPTn can also do PWM, but NONE of the GPTn output pins are available on T4.

@manitou - does this sample need to be updated for new FAST_IO of 1062? Or has the pin 25 function or some other setup changed with 1062?
 
I got mine yesterday as well and now that I have my computer working again and have my data recovered, I can start experimenting with the T4 :)
 
@manitou - does this sample need to be updated for new FAST_IO of 1062? Or has the pin 25 function or some other setup changed with 1062?

I think the gpt_count sketch works on both 1052 and 1062 since pin 25 is the same (Serial6 Rx on breakout board)
 
On most of the breakout boards, I soldered pogo pins only on pins 30 & 31 (CAN FD), ON/OFF, and the USB host signals. On the latest boards with a coin cell holder, I also put one on VBAT. Those pins take a long time to solder, and too much tends to push the T4 out of its socket, so I've been populating only the most essential ones.

I believe only 1 or maybe 2 breakout boards have left PJRC with a pogo pin touching pin 25.

If anyone needs extra pogo pins, just say the word and I'll send you some in the mail. Or you can get them from this Aliexpress vendor (12.0 or 12.5 mm height).

https://www.aliexpress.com/item/100...ctor-9-5-10-0-11-0-11-5-12-0/32910364279.html
 
@manitou - thanks for doing it - and posting on Msg #4 so I could find the link.

On most of the breakout boards, I soldered pogo pins only on pins 30 & 31 (CAN FD), ON/OFF, and the USB host signals. On the latest boards with a coin cell holder, I also put one on VBAT. Those pins take a long time to solder, and too much tends to push the T4 out of its socket, so I've been populating only the most essential ones.

I believe only 1 or maybe 2 breakout boards have left PJRC with a pogo pin touching pin 25.

If anyone needs extra pogo pins, just say the word and I'll send you some in the mail. Or you can get them from this Aliexpress vendor (12.0 or 12.5 mm height).

https://www.aliexpress.com/item/100...ctor-9-5-10-0-11-0-11-5-12-0/32910364279.html

oppps ... That's it ... T4B2m with the First B2 PJRC breakout I'm using - and seeing the Serial6 port populated made me forget it wasn't POGO'd to anything. There was ONE EXTRA POGO in the last PJRC DIY delivery - I'll go put it on this Pin 25.
 
Me too.

To test each breakout board, I ran the "listfiles" example using a single Sandisk Ultra SD card. I only quickly glanced at the serial monitor to see it listed the card's directory. Haven't done any other testing with the FFC cable.

Mine arrived yesterday in town at our post box, which I picked up this morning!...

Just verified the SDCard is working. I ran our uSDFS logger program to it and it appears to be working fine!.

Right now I am a little afraid to unplug the board to see how you did it.

I was trying to decide if it would be better to put them like you have them where the cable folds up probably in half with one connector on board and one on breakout board. Or to have breakout board with slot cut in it and have the matching connector on bottom of breakout...

Edit: I also verified, I could boot this Teensy with the Adafruit CP2104 adapter plugged into Serial4... Where it did not work on previous T4...

Will test out a few more adapters as well.
 
Last edited:
I think the gpt_count sketch works on both 1052 and 1062 since pin 25 is the same (Serial6 Rx on breakout board)

@manitou - indeed 1062 on T4B2m works when pin 25 is POGO'd to the Serial 6 header as I wrongly assumed it was like the Beta1 breakout that was Full POGO where tested it before.

I didn't test your sketch as written, though it is printing the PWM freq as it should in loop - but pulling the "dSample[dScount][1] = GPT1_CNT;" in an _isr().

The T4 at 600 MHz _isr can run against a PWM pin to a freq of about 3.4M - much higher and the T4 goes 'missing'** [ FAULTs - but no blink, and BUTTON always recovers ]. In _isr() the CYC_CNT and GPT1_CNT are put into an array and the index incremented - response time for that looks to be about 200 cycles where in 800 _isr()'s the GPT CNT sits at 910 - so it is only getting 86% of those events and the other 14% _isr()'s show the GPT_CNT up by two.
'missing'** : just reconnected Serial4 - it is faulting - but no blink.

Seems safer with 'analogWriteFrequency(0, 3254040); ' showing GPT_CNT freq of 3260870. Most every isr() is hitting 200 cycles and only 9% of the samples have 2 GPT counts. For Ref connected T_3.6 FreqCount reports: fCnt=3260912

Collecting 18841 samples in 800 us with this _isr():
Code:
FASTRUN void pulse() {
	dSample[dScount][0] = ARM_DWT_CYCCNT;
	dSample[dScount][1] = GPT1_CNT;
	dScount++;
}

Now to adapt to T_3.6 and do a polling version for a photon related FORUM question diversion that only expects intermittent 5000 hits in 500 ms - but freq is 22M instead of 3.2M continuous in 800 us as tested here.


Paul: I don't expect you'll have need to send me another Beta T4 as this equivalent T4B2m looks good, but if you end up with an otherwise unused PCB parts kit for a Release T4 Breakout board w/SD & POGO's that might be handy when the T4 ships :)
 
Paul: I don't expect you'll have need to send me another Beta T4 as this equivalent T4B2m looks good, but if you end up with an otherwise unused PCB parts kit for a Release T4 Breakout board w/SD & POGO's that might be handy when the T4 ships :)

I have 4 leftover bare boards for the previous breakout (the one using 8 tiny pogo pins). Was going to just throw them out. Would those help? Currently they're completely bare boards, not even the SMT parts.

I also have 24 of the new breakout board (the one using FFC and a coin cell holder). 4 are built (but untested and missing audio boards), and the other 20 are still bare PCBs.

Let me know what you need for tests you want to do? Monday is a US postal holiday, so Tuesday is the soonest I can get a package in the mail.
 
I have 4 leftover bare boards for the previous breakout (the one using 8 tiny pogo pins). Was going to just throw them out. Would those help? Currently they're completely bare boards, not even the SMT parts.

I also have 24 of the new breakout board (the one using FFC and a coin cell holder). 4 are built (but untested and missing audio boards), and the other 20 are still bare PCBs.

Let me know what you need for tests you want to do? Monday is a US postal holiday, so Tuesday is the soonest I can get a package in the mail.

No current 'need' - I have three working Beta T4's 1,2,2m and three working prior breakouts. As noted 'I don't expect you'll have need to send me another Beta T4 as this equivalent T4B2m looks good'

The note was for later … ' if you end up with an otherwise unused PCB parts kit for a Release T4 Breakout board w/SD & POGO's that might be handy when the T4 ships ' … assuming there are plenty of anxious folks on the Beta list waiting to see one.

It seems you are at ease with any edge oddities on power as far as hardware goes - nothing like the brown out fail to start. Hopefully you'll be in good form when you get back to software after your hardware final build & test tasks. So good you have the demonstrably capable Robin there to keep the ship on course as you morph between tasks. Going to be interesting to see ship release plan ...
 
Question: Are there any components that would hold power and confuse my meter readings as I crossed back and forth over those two pads? Or is there some downstream connection that would explain that?

Yes, there are lots of deoupling caps which will give "strange" measurements on a mulitmeter in resistance measurement mode. Typically you would see the display show a fairly low resistance which gradually increases as the test current charges the capacitors. But the exact behavior varies quite a lot depending on the design of the multimeter.


I ask because of the 'external power' feeding USB/RTC when Teensy USB to HOST PC is unpowered - that is also kept alive by the same UART on I/O pins that caused the brown out restart issue. Without comment from you I don't know if this is expected/acceptable behavior.

Again I've having trouble parsing what you're saying.

Any chance you could explain this precisely? I can't know what you've connected or what you're doing to get the brown out restart issue again. Maybe photos of a quick video of the steps would help?


The other issue is the fact that USB doesn't reconnect to PC when 5V is dropped {and the MCU has enough power to keep it alive by external means} - but hoping that is just a hang in the USB stack code?

Yet again, I can't understand this. Maybe "MCU has enough power to keep it alive" means you have a 2nd power supply? Or maybe it means the power really is turning off, and "keep it alive" means something like current bleeding through the GPIO pins? Lack of details, like what you've really connected or what the actual 3.3V power line was (drop below 2.6V, or stay 3.3V) make this really confusing.
 
On most of the breakout boards, I soldered pogo pins only on pins 30 & 31 (CAN FD), ON/OFF, and the USB host signals.
Taking about USB host signals, do the T4 also have pads to provide USB Device signals (as T3.x) ?
Another Q: Is the SDIO oriented forward ot backward?
 
Yes, there are lots of deoupling caps which will give "strange" measurements on a mulitmeter in resistance measurement mode. Typically you would see the display show a fairly low resistance which gradually increases as the test current charges the capacitors. But the exact behavior varies quite a lot depending on the design of the multimeter.
Thanks, that seemed logical - but I didn't want to dismiss something I didn't know for sure.

Any chance you could explain this precisely? I can't know what you've connected or what you're doing to get the brown out restart issue again. Maybe photos of a quick video of the steps would help?
There is always a chance … hopefully prior posts have usable steps - this was a summary leading question referring issues in older posts - I'll catalog them below.

Noted: There is NO REPRO of "brown out restart issue" - but these observations go back to the first day 'May 17' of testing after getting the T4B2m where UART or external power don't exhibit 'ideal' behavior.


Yet again, I can't understand this. Maybe "MCU has enough power to keep it alive" means you have a 2nd power supply? Or maybe it means the power really is turning off, and "keep it alive" means something like current bleeding through the GPIO pins? Lack of details, like what you've really connected or what the actual 3.3V power line was (drop below 2.6V, or stay 3.3V) make this really confusing.
Yes, there is a second supply of power - It is the UARTS holding Rx and Tx High from T_3.1 and T_3.5. They feed the breakout LED as noted along the way - and when the LED has power - so do CORE MCU elements.

Code:
related posts starting on page #116:

5/17 p2876:: Teensy 4 Beta2 Mod tolerates powered UARTS on startup
Code:
added Notes - T_3.x UARTS power in all cases [except 2(b)/(c)] - no vBat power applied: 
1: The UART power glows the Breakout Green LED when breakout Power Button used to OFF, then cutting T4's USB power with switch the LED goes from GLOW to near half bright or Dim - don't recall that Glow/Dim difference - so assume the brownout change is diverting power to GND differently.
[COLOR="#FF0000"]2(a): When breakout Power Button used to OFF - and power removed ( 5V from USB cut or Cable pulled ) - and then power is restored it maintains the OFF state until breakout Power Button used to ON - UART power maintains the state.[/COLOR]
2(b): When breakout Power Button used to OFF - and power removed ( 5V from USB cut or Cable pulled ) - and T_3.x UARTS powered off - and then power is restored it returns in ON state. 
2(c):: UART 3.3V [RE 2(a)] is keeping the part of the MCU alive that is recording ON/OFF power button state. The same when vBat is powered and UART and other power removed.
3: As expected the Teensy Button has no effect in either of the above cases
4: Power button on breakout works normally as expected

Post 2877:
@Paul - regarding post #2876:'Notes #2' will leave to your consideration the perhaps unexpected state of the pin power keeping some part of the 'RTC' section alive when power otherwise removed.
It might allow a user to get stuck in this 'unexpected state' - it puzzled me more than a second when I hit the OFF button, then removed power , restored power - and the T4B2m didn't start as I thought it might looking for brownout repro - because the UART power kept the MCU alive to know it was 'OFF'
And > I'm not sure if this indicates anything about UART power [any power on pins] backfeeding to the RTC segment in a bad way or powering anything else that should be 'off'?

Other than that - I've not found a way to cause the prior 'Brown Out' failure to start on the T4B2m

With DVM I see about 0.92 volts on VBat when running and powered - and VBat otherwise unconnected.
Pulling USB cable with UART power on pins I see 2.21 on the end 3.3V pin and 0.82 volts on vBat that drops to 0.66V - but on plugging the USB the code below shows USB was maintained after leaving off some short time where DVM showed it drop to the 0.66 point where it seemed to hold.

UPDATE on GLOW/DIM Breakout Green LED:
> With no UART power the OFF T4's 3.3V end pin reads 0v.
> Adding UART power on breakout Serial# the OFF 3.3V end pin shows 1.9 volts.
> When the USB cable is pulled with UARTS powered to breakout I see 2.14 volts on the 3.3V pin as noted above

// ...

No response to those two posts - but did reply to #2878 re 15s Restore code

From 5/19 post #2889 when using external power with VIN<>VUSB trace cut
For the T4B2 going on the DYI breakout I pulled the solder blob off VIN<>VUSB and feeding it 5V & GND from a spare Teensy plugged into wall wart.
Paul: Something Odd with a USB write sketch. T4B2 - no external UARTS - 5V external Power.
Sketch is busy work finding 6542 primes up to 65535 and printing them with two delay(300)'s in loop, works fine. IDE TeensyPorts or TyComm both just FLASH data - no attempt to scroll 655 lines of prime numbers!
Using TyComm - with constant powere/USB connect - I can click GUI 'Serial Off' then On and there is no problem. Doing this same test on T4B2m also no problem.

Odd Thing: T4B2 external powered running Primes print sketch ( with or without VBat ) doing Prints with Blink:
1 >> UnPlug USB to PC - leaving the T4running on ext 5V showing Blink :: PC Device removal sounds; repeat for 2a or 2b below.
2a >> Plug USB back in - PC USB Attached sounds, but TyComm SerMon does not pick up printing. GUI button Toggle does nothing.
2b >> Plug USB back in - PC USB Attached sounds, but IDE SerMon TeenyPorts does not pick up printing - it leaves a BLANK screen. Close and reopen SerMon does not resume printing - Blink continues
3a >> Repower w/5V ext, POWER Off/On button, or reprogram T4B2 required to resume USB connection to printed output


* Note 1: It is fine if T4B2 restarts with no Serial connect - then connection is made it runs normally - either by TyComm GUI Serial button, or unplug USB, restart T4, then plug USB.
* Note 2: I can have SerMon as TyComm, disable Serial, go to IDE T_ports Sermon and it picks up, close T_ports Sermon, resume TyComm as Sermon - no problem.
* Note 3: The above were not meant to be smileys - but time for levity and sleep so I'm leaving them parsed.


Conclusion: Problem is externally powered T4 doing USB output when USB is disconnected, T4 continues running - but USB stays 'offline' when cable plugged in.

// ...

5/21 p#2952 :
Paul I have a Hub that seems to be putting power to the T4 through USBHost port? It is with the T4B2m on PJRC breakout, with UARTS active and connected on Serial #2 and #4.

I just got a new USB Drive Box with a Powered Hub built in. This HUB seems to be sending power back up - is that possible through the USB 'chip' on the breakout?

What I see: Power the UARTS and the T4B2m.
> Cut power to the USB ( I have a switch on 5V - leaves GND and USB +/- data lines attached )
> The T4 does not go offline - because the UART power is keeping the USB on MCU powered ( USB HUB DEVICE not connected yet )
> Plug in my Orico Powered Hub drive box - and The T4 BOOTS with "***********IMXRT Startup**********" messages out Serial4 to the T_3.1.

- I assume this means the Orico Hub unit is breaking a rule feeding power to the host? This does not happen when I plug in Amazon powered Hub - or a powered external Drive box.

<edit> MCU's USB not going 'offline' due to power from UART pins seems an issue when device powered by USB loses USB power?

5/14 p# 2968
Paul - I am now getting use out of the USB HUB/Drive enclosure - with HUB code in the Disk write samples - works the same on T_3.6 but using a T4 and finding the HUB will backpower the T4 from the HOST USB adapter as noted in prior post #2952 on this thread - link prior is in the 'USBHost_t36-USB-Mass-Storage-Driver-Experiments' {p#226 is when it went working} - I didn't see what that Orico USB hub/drive box does on a T_3.6. But on the T4 it results in external power applied when pulling the T4 USB device cable leaves it running - but as noted this thread post #2889 when a T4 is externally powered and USB Device connection to host PC is removed - the T4 USB Serial will not connect again until it does a restart ( Power Off/On button or external power removed ).

<EDIT>: I just tested the Orico Hub/Drive enclosure on T_3.6 USBHost - when I unplug the USB Serial power cable the T_3.6 shuts down and restarts when I plug the Serial USB cable back in. The code and drive/Hub works same on T4 as on T_3.6 - as expected since the author @wwatson has been working on it with only his T_3.6 to date. Maybe this is just a wiring issue on the T4 breakout letting the power flow in from the device on the host port - per post #2952 - the hardware on T_3.6 doesn't act the same.

KurtE says he's had devices like this before on robots where it would back feed the rPi and other parts so hopefully not hurting anything using this device?

Hoping the #2889 issue is just a USB stack adjustment and not USB controller in the MCU going to an odd state. I assume this is not Kosher - but not uncommon and the resultant behavior follows along with purposefully connecting External 5V when VUSB<>VIN is cut as I did and noted I a post linked here #2889.

Also noted post #2877 - but maybe part of the same issue was that while the PCB edit to Brown Out from UART pins was corrected on T4B2m - the power on these UART pins does keep the RTC segment and USB 'controller' alive on data lines when only the 5V line is cut in the cable - or when the Power Off button is pressed - the PC still sees the T4 USB as 'connected' as the UART pin power is feed the PCB green LED and the vBat section of the MCU as noted there.

If those posts don't have usable needed detail to understand them as 'software' issues let me know .


No answer to those posts left me wondering led to the 5/25 post # 2977 that comment refers back to with that summary query.
And another 5/25 post #2978 where it seems I rediscovered something posted above with regard to the power button working with UART supplied power.
 
Paul - 2990 is a summary with links and most context of posts you may have skimmed or missed without reply.

None of those issues were fatal - just not clean and all relate to power from UART pins, external 5V power, or backfed power from T4's Host port in some fashion that put power on the breakout green LED.

Pick the one that you best understand as something of concern. If steps are unclear let me know which post and I'll repro and explain as needed - perhaps where possible without the breakout board in case it is behind the power leakage with the Green LED or the Host port wiring.

As noted I confirmed the T_3.6 Host plug hardware does not accept power from that external device, so maybe a shortcut on the breakout causes that?
 
@defragster, @PaulStoffregen - Obviously Paul knows a lot more about all of this then I do! But a couple of quick guesses...

a) Power LED - Wonder if you had an LED hooked up on T3.x to 3.3v and back powered the T3.x the same way as the T4, if you might see similar voltages. Or voltages... Again maybe might be interesting to see if this is specific to T4... I know in the past with some of my T3.x boards, where maybe I had them hooked up to something that was still powered, that I might see glow in power led... I think this might have been with Dynamixel Servos or the like....

b) Powered USB Hub... I am thinking this is maybe more support chip differences between the T3.6 and your T4 breakout board.

That is if you look at the Teensy 3.5/6 schematic (https://www.pjrc.com/teensy/schematic.html)
You will see the chip TPD3S014 (http://www.ti.com/lit/ds/symlink/tpd3s014.pdf), which I think is controlling the USB power to the host port. And it has an enable pin connected to PTE6 which has a PD resistor connected to it and which the USBHost code specifically enables int USBHost::begin()...

I believe that the breakout boards are using a TPS055A chip? (looks like: https://www.ti.com/lit/ds/symlink/tps2058a.pdf) marking 2055a and it looks like the enable is simply tied to +5v. do not sure if there could be some voltage coming in on D+/D- or the like, which may float enable high enough?

So my guess is if someone wanted to hardware experiment to get T4 to act like T3.6 here could try:
1) Use same chip as T3.6 and use an IO pin with PD resistor to enable pin
2) Try current breakout board, Disconnect pin 4 (enable) currently tied to +5v, and run a jumper to some IO pin with PD resistor... Obviously will then need to enable this pin, when a program wishes to use USB Host...

c) VBat - I need to reread your posting - But if I am reading it correctly you are saying that when plugged into USB, you see a voltage on the V-BAT pin. So I tried that with the new shiny T4B2 with ribbon... The nice new and shiny... And I do get a voltage on VBAT pin when plugged in. But I also appear to show a voltage on 3.2 and 3.6 as well... Which sort of surprised me. As I thought from Schematic VBAT pin and 3.3v pin both went through diodes before combining and connecting to the VBat pin of the processor... But I am probably reading it wrong, and/or my 20 year old Metex meter is reading it wrong...

Again this is only guessing!
 
Last edited:
@manitou - indeed 1062 on T4B2m works when pin 25 is POGO'd to the Serial 6 header as I wrongly assumed it was like the Beta1 breakout that was Full POGO where tested it before.

I didn't test your sketch as written, though it is printing the PWM freq as it should in loop - but pulling the "dSample[dScount][1] = GPT1_CNT;" in an _isr().

The T4 at 600 MHz _isr can run against a PWM pin to a freq of about 3.4M

With a pin interrupt ISR, you'll be limited to about 3 mhz as you noted. The external clocking of GPT is good up to 1/4 ipg_clk (150mhz/4 == 37.5 mhz)
 
@defragster, @PaulStoffregen - Obviously Paul knows a lot more about all of this then I do! But a couple of quick guesses...

a) Power LED - Wonder if you had an LED hooked up on T3.x to 3.3v and back powered the T3.x the same way as the T4, if you might see similar voltages. Or voltages... Again maybe might be interesting to see if this is specific to T4... I know in the past with some of my T3.x boards, where maybe I had them hooked up to something that was still powered, that I might see glow in power led... I think this might have been with Dynamixel Servos or the like....

b) Powered USB Hub... I am thinking this is maybe more support chip differences between the T3.6 and your T4 breakout board.

That is if you look at the Teensy 3.5/6 schematic (https://www.pjrc.com/teensy/schematic.html)
You will see the chip TPD3S014 (http://www.ti.com/lit/ds/symlink/tpd3s014.pdf), which I think is controlling the USB power to the host port. And it has an enable pin connected to PTE6 which has a PD resistor connected to it and which the USBHost code specifically enables int USBHost::begin()...

I believe that the breakout boards are using a TPS055A chip? (looks like: https://www.ti.com/lit/ds/symlink/tps2058a.pdf) marking 2055a and it looks like the enable is simply tied to +5v. do not sure if there could be some voltage coming in on D+/D- or the like, which may float enable high enough?

So my guess is if someone wanted to hardware experiment to get T4 to act like T3.6 here could try:
1) Use same chip as T3.6 and use an IO pin with PD resistor to enable pin
2) Try current breakout board, Disconnect pin 4 (enable) currently tied to +5v, and run a jumper to some IO pin with PD resistor... Obviously will then need to enable this pin, when a program wishes to use USB Host...

c) VBat - I need to reread your posting - But if I am reading it correctly you are saying that when plugged into USB, you see a voltage on the V-BAT pin. So I tried that with the new shiny T4B2 with ribbon... The nice new and shiny... And I do get a voltage on VBAT pin when plugged in. But I also appear to show a voltage on 3.2 and 3.6 as well... Which sort of surprised me. As I thought from Schematic VBAT pin and 3.3v pin both went through diodes before combining and connecting to the VBat pin of the processor... But I am probably reading it wrong, and/or my 20 year old Metex meter is reading it wrong...

Again this is only guessing!

Thanks for reading Kurt.

There is a common thread - this chip has On/Off and more than just the RTC clock feeding on UART VamPower - And the USB stays alive different. Some of that is the chip - some the state of the software perhaps - some the breakout board.
 
I have 4 leftover bare boards for the previous breakout (the one using 8 tiny pogo pins). Was going to just throw them out. Would those help? Currently they're completely bare boards, not even the SMT parts.

I also have 24 of the new breakout board (the one using FFC and a coin cell holder). 4 are built (but untested and missing audio boards), and the other 20 are still bare PCBs.

Let me know what you need for tests you want to do? Monday is a US postal holiday, so Tuesday is the soonest I can get a package in the mail.

Instead of tossing them, if they are compatible with the final version of the board, why not do a contest or some other random promotion with them?
 
c) VBat - I need to reread your posting - But if I am reading it correctly you are saying that when plugged into USB, you see a voltage on the V-BAT pin. So I tried that with the new shiny T4B2 with ribbon... The nice new and shiny... And I do get a voltage on VBAT pin when plugged in. But I also appear to show a voltage on 3.2 and 3.6 as well... Which sort of surprised me. As I thought from Schematic VBAT pin and 3.3v pin both went through diodes before combining and connecting to the VBat pin of the processor... But I am probably reading it wrong, and/or my 20 year old Metex meter is reading it wrong...

This is the easiest, so answering it first.

TL;DR = this is normal & expected behavior.

What you're really seeing is the reverse leakage through the schottky diode. This is a property common to all schottky diode, and all diodes really, but with silicon junction diodes the reverse leakage current is usually so low that it won't give you a strong enough signal for the ~10M input impedance of a multimeter. With schottky diodes, the reverse leakage current is usually a several microamps (but varies quite a lot of temperature). Into a 10M load, a few microamps is plenty to give you a reading that looks as if the diode were pretty much just a wire.

The diode is indeed conducting ever so slightly in reverse. Your voltmeter is designed to be very sensitive, so it doesn't change the circuits its measuring. Put those 2 together and you get a number on the screen which says there is voltage present.

As with all voltage measurements on multimeters, the number doesn't tell you anything about the impedance. But if you normally use your multimeter for measuring power lines and other low impedance stuff, it's easy to get used to that number meaning a low impedance power source must be present.

If you try actually drawing some power, like connect a 1K or 10K resistor from VBAT to GND, you'll see the voltage goes to almost zero.
 
@KurtE, @defragster, @PaulStoffregen

If you try actually drawing some power, like connect a 1K or 10K resistor from VBAT to GND, you'll see the voltage goes to almost zero. /QUOTE] I had to check and you are right put a 4k resistor (had it laying on the desk) and measured the voltage and it does go down to almost zero, on my old meter I got 4.6mv vs 3.2V without the resistor.
 
This is the easiest, so answering it first.

TL;DR = this is normal & expected behavior.

What you're really seeing is the reverse leakage through the schottky diode. This is a property common to all schottky diode, and all diodes really, but with silicon junction diodes the reverse leakage current is usually so low that it won't give you a strong enough signal for the ~10M input impedance of a multimeter. With schottky diodes, the reverse leakage current is usually a several microamps (but varies quite a lot of temperature). Into a 10M load, a few microamps is plenty to give you a reading that looks as if the diode were pretty much just a wire.

The diode is indeed conducting ever so slightly in reverse. Your voltmeter is designed to be very sensitive, so it doesn't change the circuits its measuring. Put those 2 together and you get a number on the screen which says there is voltage present.

As with all voltage measurements on multimeters, the number doesn't tell you anything about the impedance. But if you normally use your multimeter for measuring power lines and other low impedance stuff, it's easy to get used to that number meaning a low impedance power source must be present.

If you try actually drawing some power, like connect a 1K or 10K resistor from VBAT to GND, you'll see the voltage goes to almost zero.

In the one post where I did record voltages they were not strong or fixed - so leakage explains that - just like the glowing LED - they are present and influencial.

RTC doesn't take a lot from a 2032 cell either - just enough to keep things alive. Which has some side effects on this awesomely complex MCU. None fatal - just avenues perhaps for end user confusion and odd states. The RTC is a bonus, but On/Off Power section and at least also USB also feed on that - not sure if there is anything else of import.

I cataloged them as I saw them just in case they did point to anything unexpected or problematic for long term use.
 
I finally solder on some smd header pins to the underside of the T4B2 (wire on top) and put it in my version of a breakout board and beside having to add a couple of jumpers got CAN1 CANFD and USB host working no problem (had to touch up my soldering on the chips though). Anyway that's the reason for the post.

A long time ago I posted about a shield type board I put together for the prop shield along with a conversion I did of Kris Winer's prop shield sketch into a library format. I just retested it on a T3.5 and had no problem reading the accel, gyros and magnetometers along with the MP3115 pressure sensor. However, using the same code and shield on the T4 breakout I can get everything working except the MPL driver.

To get it working on the T4 I had to convert from using i2c_t3 to Wire but not a big issue. The only change I had to make was convert:
Code:
Wire.endTransmission(I2C_NOSTOP);
to
Code:
Wire.endTransmission(Ifalse);
Initializing the gryo/accel/mag and reading worked like a charm. But as I said the MPL piece died on initialization. Tried tracing it and seems to die on a second read of a register for clearing interupts:
Code:
// Initialize the MPL3115A2 for realtime data collection 
void psIMU::initRealTimeMPL3115A2()
{
  // Clear all interrupts by reading the data output registers
  uint8_t temp;
  temp = readByte(MPL3115A2_ADDRESS, MPL3115A2_OUT_P_MSB);
	Serial.println(temp,HEX);
  temp = readByte(MPL3115A2_ADDRESS, MPL3115A2_OUT_P_CSB);  <==== Hangs here.....
    Serial.println(temp,HEX);
  temp = readByte(MPL3115A2_ADDRESS, MPL3115A2_OUT_P_LSB);
    Serial.println(temp,HEX);
  temp = readByte(MPL3115A2_ADDRESS, MPL3115A2_OUT_T_MSB);
    Serial.println(temp,HEX);
  temp = readByte(MPL3115A2_ADDRESS, MPL3115A2_OUT_T_LSB);
    Serial.println(temp,HEX);
  temp = readByte(MPL3115A2_ADDRESS, MPL3115A2_F_STATUS);
    Serial.println(temp,HEX);

  
   MPL3115A2Standby();  // Must be in standby to change registers
  
  // Set CTRL_REG4 register to configure interupt enable
  // Enable data ready interrupt (bit 7), enable FIFO (bit 6), enable pressure window (bit 5), temperature window (bit 4),
  // pressure threshold (bit 3), temperature threshold (bit 2), pressure change (bit 1) and temperature change (bit 0)
  writeByte(MPL3115A2_ADDRESS, MPL3115A2_CTRL_REG4, 0x80);  
  
  //  Configure INT 1 for data ready, all other interrupts to INT2
  writeByte(MPL3115A2_ADDRESS, MPL3115A2_CTRL_REG5, 0x80); 
  
  // Set CTRL_REG3 register to configure interupt signal type
  // Active HIGH, push-pull interupts INT1 and INT 2
  writeByte(MPL3115A2_ADDRESS, MPL3115A2_CTRL_REG3, 0x22); 
  
  // Set FIFO mode
  writeByte(MPL3115A2_ADDRESS, MPL3115A2_F_SETUP, 0x00); // disable FIFO mode
  
  MPL3115A2Active();  // Set to active to start reading
}

It does see all three I2C devices no problem so ruled that out. I ran a stand alone library for the MPL but it doesn't have the option for realtime data.

So before I start redoing the MPL stand alone library thought I would post to see if anyone has any ideas I can check

EDIT: The whole lib and example sketch is here: https://github.com/mjs513/WIP/tree/master/PSImu
 
Last edited:
This one is also easy. I believe it's already been covered, but just in case the answer hasn't been clear...

2(a): When breakout Power Button used to OFF - and power removed ( 5V from USB cut or Cable pulled ) - and then power is restored it maintains the OFF state until breakout Power Button used to ON - UART power maintains the state.

This is absolutely the correct expected behavior. The ON/OFF state is maintained as long as the low-power (or "SNVS") portion of the chip has at least 1 volt. It doesn't matter if you use a coin cell or if the power comes leaking through the GPIO pins. If there is enough power to keep the low-power part of the chip above 1V, it remembers the ON/OFF state.
 
Status
Not open for further replies.
Back
Top