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
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?
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
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.
I think the gpt_count sketch works on both 1052 and 1062 since pin 25 is the same (Serial6 Rx on breakout board)
FASTRUN void pulse() {
dSample[dScount][0] = ARM_DWT_CYCCNT;
dSample[dScount][1] = GPT1_CNT;
dScount++;
}
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.
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?
Taking about USB host signals, do the T4 also have pads to provide USB Device signals (as T3.x) ?On most of the breakout boards, I soldered pogo pins only on pins 30 & 31 (CAN FD), ON/OFF, and the USB host signals.
Thanks, that seemed logical - but I didn't want to dismiss something I didn't know for sure.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.
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.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?
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.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.
related posts starting on page #116:
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
@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
// ...
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.
// ...
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?
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 .
@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
@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!
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.
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...
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.
Wire.endTransmission(I2C_NOSTOP);
Wire.endTransmission(Ifalse);
// 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
}
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.