Teensy 4.0 First Beta Test

Status
Not open for further replies.
True, I will look into it this week since CANFD is pretty much in public testing phase now to find any bugs that may exist. This will give me time to work on watchdog before going back to work on CAN2.0
 
Great! Mjs513 posted some info in the Teensy4 software restart thread. It seems that every attempt to restart the T4 results in a shutdown? Not clear what the reason is and if there is already a solution for it.
 
Screenshot_20191003-151935_Adobe Acrobat.jpg

Wonder if this is relevant
Btw, wdt doesnt work in low power modes or deep sleep
In any case it is suggested the best wtd reset is via an external pin controlled by the wdt (tied to hardware reset pin)
 
Wonder if this is relevant
Btw, wdt doesnt work in low power modes or deep sleep
In any case it is suggested the best wtd reset is via an external pin controlled by the wdt (tied to hardware reset pin)

The NXP 1060 SDK has an example that works and does reset with WDOG1 on NXP 1060 eval board. So i think T4 problems might relate to T4 bootloader and/or core startup procedure or ?
ref: https://forum.pjrc.com/threads/57810-Soft-reboot-on-Teensy4-0?p=217524&viewfull=1#post217524


EDIT: i had only tested on NXP 1050 eval board, but confirmed wdog01 example does work on NXP 1060 eval board.

I made a teensy version ( wdog1.ino ) of the SDK WDOG1 example. The sketch works on T4B1 (1050), but fails to restart on production T4 (1060).
 
Last edited:
According to nxp threads i glimpsed over, they claim the dev boards are tied via hardware via trigger pin to reset pin , t4 version was made from the 1050 sdk
 
According to nxp threads i glimpsed over, they claim the dev boards are tied via hardware via trigger pin to reset pin , t4 version was made from the 1050 sdk

the 1060 eval board schematic is complex, and there is a RESET button to POR pin, but i don't see a "trigger pin to reset pin"
 
Notes on testing USB Host … OverClocking … and Current … and Temp:

Measuring current a 15s restore results in T4 booting blink at 55 and 56 mA. Sound right to suggest my DMM is reading right.

Working with USB Host and Ethernet LAN adapter on two T4's with a heat sink { copper .25" high not quite .5" square } it lets the T4 run at 912 Mhz.
> One is PJRC Ribbon final Beta T4 - the other is direct soldered on the initial @loglow board.
> one code set not printing temp - current a bit diff - both seem to have same 912 MHz behavior.

Room is cooler now - idling at 73C - room was warmer earlier and temp hit 78 and stayed running down to current 73C … alive and Ping working.

{ interesting because with boards.txt edited so 1008 MHz does 1008 not 996 - a sketch posted was FAULTING under 70C - @mjs513 T4-TEMPMON_buddabrot.ino using the debug_tt that reactivates the Fault code }

So back to USBHost - running the ASIXEthernet_Test.ino for the LAN - without LAN USB adapter attached:

>> Starting two T4's hit 208 or 215 mA as it comes up before USB LAN adapter is connected.
- nothing else connected PJRC beta has a green LED - otherwise current is just higher MCU MHz and USBHost device active.
- Did this measure because if the USB LAN adapter is connected at startup it fails to ever connect when OC'd to 912 MHz

>> To the running T4 connect the USB Adapter and current goes to 368 to 384 mA and connect to LAN
- This is where running temp with heat sink hits 73-78 degrees C


Under 912 MHz USBHost LAN works - it also works when plugged into Powered Hub plugged into T4.
>> Running through Powered HUB the T4 is only drawing 110 mA

The MSC HDD USBHost code also works to HDD at 960 MHz - but that is through powered HUB

Connecting the PJRC board through powered hub to LAN USB adapter works at 960 MHz
> Current is at .111 Ma
> reported temp is 76, where it was last 73 at 912 MHz
 
NOTE on temps:

Running at 960 MHz the T_4 with active USBHost noted above to LAN through powered hub maintained 78°C today not problem.

Going to another sketch @luni intervaltimer posted - and running at 1008 MHz ( actually 996 as it is a fresh TD 1.48 on IDE 1.8.9 ) USB print issues show up about 65°C. Occasional extra chars. Noted elsewhere I got a FAULT to occur that was trapped - but just from OC/Temp issue. Not sure now of temp on that or the situation.

But for the above when OC speeds go higher - wondering if it make sense to drop the threshold on TempMon in some fashion? Would have to add heat to get to 80 from the 78 observed. All this OC was with solid Copper heat sink (with square blob top surfaces) and static air. Blowing across the 65C test case with bad prints dropped temp and printing no longer showed issues. A bit warmer and it just QUIT with no Fault reported at 996 MHz.

Perhaps the Arm_Clock set code could adjust the temp down - at least for warning High as once it gets hot it seems to run away - well below 80 at 996 - better cooling keeps the temp down and function at 60C seems like it might be okay.
 
NOTE on temps:

Running at 960 MHz the T_4 with active USBHost noted above to LAN through powered hub maintained 78°C today not problem.

Going to another sketch @luni intervaltimer posted - and running at 1008 MHz ( actually 996 as it is a fresh TD 1.48 on IDE 1.8.9 ) USB print issues show up about 65°C. Occasional extra chars. Noted elsewhere I got a FAULT to occur that was trapped - but just from OC/Temp issue. Not sure now of temp on that or the situation.

But for the above when OC speeds go higher - wondering if it make sense to drop the threshold on TempMon in some fashion? Would have to add heat to get to 80 from the 78 observed. All this OC was with solid Copper heat sink (with square blob top surfaces) and static air. Blowing across the 65C test case with bad prints dropped temp and printing no longer showed issues. A bit warmer and it just QUIT with no Fault reported at 996 MHz.

Perhaps the Arm_Clock set code could adjust the temp down - at least for warning High as once it gets hot it seems to run away - well below 80 at 996 - better cooling keeps the temp down and function at 60C seems like it might be okay.

@defragster - could drop it but probably better just not have it as a option. Think we verified at above 960Mhz we are running into operating issues. At 1Ghz 65C will get reached rather rapidly.
 
@defragster @mjs513 , just for your records

My experience with overclocking is the following:

Yesterday, I could run your Buddhabrot example at 1008MHz for more than one hour without problem (I use set_arm_clock in the sketch and inserted a line for a TFT printout of F_CPU_ACTUAL in the sketch, so I think it was "real" 1008MHz, does that make sense?). I have a massive 10x10mm copper heatsink [Alphacool 17426 GPU RAM Copper heatsink] glued to the T4 processor with thermal glue [Silverbead Thermal Glue Adhesive SG100X]. The Buddhabrot sketch @1008MHz never exceeds 70 degrees with that heatsink and stays around 42 degrees C @600MHz and around 57 degrees C @996MHz.

T4 heatsink DD4WH.JPG

However, when I tried the sketch again today, I was unable to use 1008MHz, the sketch would not run, max CPU freq useable was 996MHz with max temp of about 57 degrees.

When I use the T4 Convolution SDR sketch, the maximum useable CPU frequency is 948MHz [temperature rises to 66 degrees C] (set during runtime with an encoder and set_arm_clock). With 960MHz I see problems with displaying on the TFT ILI9341 and after a while the sketch crashes and holds. With more than 960MHz the script almost immediately crashes, even with CPU temperatures around 68 degrees C.

It seems that overclocking is a little unstable above 948MHz and also dependent on processor load and temperature?
 
Last edited:
@defragster @mjs513 , just for your records

My experience with overclocking is the following:

Yesterday, I could run your Buddhabrot example at 1008MHz for more than one hour without problem (I use set_arm_clock in the sketch and inserted a line for a TFT printout of F_CPU_ACTUAL in the sketch, so I think it was "real" 1008MHz, does that make sense?). I have a massive 10x10mm copper heatsink glued to the T4 processor with thermal glue. The Buddhabrot sketch @1008MHz never exceeds 70 degrees with that heatsink and stays around 42 degrees C @600MHz and around 57 degrees C @996MHz.

...
However, when I tried the sketch again today, I was unable to use 1008MHz, the sketch would not run, max CPU freq useable was 996MHz with max temp of about 57 degrees.

When I use the T4 Convolution SDR sketch, the maximum useable CPU frequency is 948MHz [temperature rises to 66 degrees C] (set during runtime with an encoder and set_arm_clock). With 960MHz I see problems with displaying on the TFT ILI9341 and after a while the sketch crashes and holds. With more than 960MHz the script almost immediately crashes, even with CPU temperatures around 68 degrees C.

It seems that overclocking is a little unstable above 948MHz and also dependent on processor load and temperature?

Good feedback - the Buddhabrot sketch is courtesy of @mjs513. The IDE setting of 1008 actuals codes to 996 through the TD 1.48 setup. It can be changed there.

Seems noteworthy that over 75C works at 960 MHz and passing 60-65C at higher speeds is failing in odd in what should be a usable temp range. The voltage overboost is either not enough to run some portion - or too much for some other portion of the MCU?

Interesting your 10mmx10mm heat sink worked that well. Heat sink here noted below is 6 gm in weight and 0.5" square and has a thermal tape to attach - the glue probably better?

Different sketch stress can run differently - my 960MHz test mostly with USBHost - once through USB Hub it seemed stable - even at 78C.

@defragster - could drop it but probably better just not have it as a option. Think we verified at above 960Mhz we are running into operating issues. At 1Ghz 65C will get reached rather rapidly.

Seems right - comment or remove 996/1008 as a speed option. 960 MHz seems to run on two here even up to 78C in normal room temp with a simple copper heat sink that weighs 6 grams.

912 seems to have more headroom than 960 for current to feed HostUSB - but even 912 won't always feed USBHost LAN adapter directly where the 816 MHz option seems to without going to powered USB HUB. But even going through HUB where T_4's LDO is pushing just over 100 ma instead of over 250-350 - the 1Ghz range seems to fail.

So it seems over 912 or 960 seems on the edge of losing function when temps rise as noted into the 65°C range.
 
@Paul - @other :: Is there a reason nothing higher than 1 MHz is tried in this WIRE file?:: \hardware\teensy\avr\libraries\Wire\WireIMXRT.cpp
Code:
void TwoWire::setClock(uint32_t frequency)
{
        port->MCR = 0;
	if (frequency < 400000) { 		// 100 kHz
...
	} else if (frequency < 1000000) {	// 400 kHz
...
	} else {		// 1 MHz
		port->MCCR0 = LPI2C_MCCR0_CLKHI(9) | LPI2C_MCCR0_CLKLO(10) |	LPI2C_MCCR0_DATAVD(4) | LPI2C_MCCR0_SETHOLD(7);
		port->MCFGR1 = LPI2C_MCFGR1_PRESCALE(0);
		port->MCFGR2 = LPI2C_MCFGR2_FILTSDA(1) | LPI2C_MCFGR2_FILTSCL(1) | LPI2C_MCFGR2_BUSIDLE(3900);
	}
 
@Paul - @other :: Is there a reason nothing higher than 1 MHz is tried in this WIRE

I am no expert in I2C, but did fill in some of the stuff during the beta. I think the clock stuff was done before then...

Some of this is controlled by which clock is used by I2C.

This is setup in the first part of begin:

Code:
void TwoWire::begin(void)
{
        // use 24 MHz clock
    CCM_CSCDR2 = (CCM_CSCDR2 & ~CCM_CSCDR2_LPI2C_CLK_PODF(63)) | CCM_CSCDR2_LPI2C_CLK_SEL;
	hardware.clock_gate_register |= hardware.clock_gate_mask;
    port->MCR = LPI2C_MCR_RST;
    setClock(100000);
If you look at the clock tree(p1073 in pdf), you will see you have two main options: have it based off of pll3_sw_clk or based off of OSC (oscillator), now if you look at the CCM_CSCDR2 register (page 1122), it appears like we clear the LPI2C_CLK_PODF and set the LP12C_CLK_SEL so says derive clock from osc_clk... Which by comment is 24mhz...

Note: I have not seen anywhere in the code that sets up or uses pl3_sw_clk but if I understand it and it is configured not to be bypassed, (CCSR register), then maybe it is defined as 480mhz, which by the clock tree is then divided by 8 so: 60mhz, which we then is controlled by divider CSCDR2[LPI2C_CLK_ROOT] register fields which above we set to 0 so by 1...

But needless to say if you now change the root clock like this, then all of the values in the I2C set clock have to change to reflect this: (MCCR0, MCFGR1, MCFGR2)
...

But again I have never tried any of these updates... I know that Frank did some similar stuff in SPI to allow different clocks to be chosen and then we computed from those...
 
@KurtE

Believe that @manitou developed that section of code for setClock, way back when. For an explanation see post #403 in this thread. Also you can check the manual about page 2877 for LPI2C
 
@WMXZ discovered that set_arm_clock() changes at runtime can leave the millis() time reporting broken:

T4-set_arm_clock-and-micros()

And when millis() breaks - so does micros() which just reports that millis() value with microsecond extension based on MCU ARM_CycCounter.

A sketch there shows how to recreate it as broken and how it works when the clock is changed in STEPS - that keeps the micros() working.
 
@KurtE

Believe that @manitou developed that section of code for setClock, way back when. For an explanation see post #403 in this thread. Also you can check the manual about page 2877 for LPI2C

Good link @mjs513.

Would be nice if alternate clock or math could result in increased i2c speed as it seems these SSD1306 and other devices can run faster than 1 MHz?

I just noticed building the FRDM4236 breakout with i2c pin port onboard. Going from 400 KHz to 1 MHz dropped test group of Adafruit display images from 8+ seconds to under 4 seconds. Limit of 1 MHz means Teensy 4.0 at 150 MHz runs as fast as T_4 at 816 MHZ because of the wait for i2c transfer.

EDIT:
At 600 MHz on T4 it shows "loopTime=3884361" 3.88 seconds.
at 150 MHz on T4 runs at "loopTime=3940829" or 3.94 seconds.
at 816 MHz on T4 runs at "loopTime=3878884" or 3.87 seconds
 
@mjs513 @defragster - Yes it might be good to allow higher speeds. And the table 46-9 gives a pretty good idea of the settings.

Don't have time right now to try, but

You probably would need to change the setting above:
Code:
CCM_CSCDR2 = (CCM_CSCDR2 & ~CCM_CSCDR2_LPI2C_CLK_PODF(63)) | CCM_CSCDR2_LPI2C_CLK_SEL;
To maybe:
Code:
CCM_CSCDR2 = (CCM_CSCDR2 & ~CCM_CSCDR2_LPI2C_CLK_PODF(63));
To use the PLL3_SW_CLK .

Maybe need to make sure that ths clock is not bypassed.
Guessing:
Code:
CCM_CCSR = 0;
.  
Then again guessing we should have the 60mhz passed in. and again table (p2879) shows settings for 400k, 1mbps and 3.33mbps
But if you need a slower speed like 100khz, you might not be able to get that with the clock configured that way...

And again guessing.  Probably would need to setup with one of these settings and look with LA or Scope and see if correct.
 
@KurtE

Was going through the manual (Argh! my new favorite word when reading the manual) and checking the clock settings. But one other thing that needs to be verified otherwise we may run into other problems are the I2C Timing settings themselves for the different clocks in the table, i.e., CLKLO, CLKHI, etc. Since I am never one to reinvent the wheel if I don't have too and been timings with tonton81 on flexcan I went through the I2C example in the SDK and found something a little more generic that I going to play with to see what it gives me:
Code:
/*!
 * brief Sets the I2C bus frequency for master transactions.
 *
 * The LPI2C master is automatically disabled and re-enabled as necessary to configure the baud
 * rate. Do not call this function during a transfer, or the transfer is aborted.
 *
 * note Please note that the second parameter is the clock frequency of LPI2C module, the third
 * parameter means user configured bus baudrate, this implementation is different from other I2C drivers
 * which use baudrate configuration as second parameter and source clock frequency as third parameter.
 *
 * param base The LPI2C peripheral base address.
 * param sourceClock_Hz LPI2C functional clock frequency in Hertz.
 * param baudRate_Hz Requested bus frequency in Hertz.
 */
void LPI2C_MasterSetBaudRate(LPI2C_Type *base, uint32_t sourceClock_Hz, uint32_t baudRate_Hz)
{
    uint32_t prescale = 0;
    uint32_t bestPre = 0;
    uint32_t bestClkHi = 0;
    uint32_t absError = 0;
    uint32_t bestError = 0xffffffffu;
    uint32_t value;
    uint32_t clkHiCycle;
    uint32_t computedRate;
    int i;
    bool wasEnabled;

    /* Disable master mode. */
    wasEnabled = (base->MCR & LPI2C_MCR_MEN_MASK) >> LPI2C_MCR_MEN_SHIFT;
    LPI2C_MasterEnable(base, false);

    /* Baud rate = (sourceClock_Hz/2^prescale)/(CLKLO+1+CLKHI+1 + ROUNDDOWN((2+FILTSCL)/2^prescale) */
    /* Assume CLKLO = 2*CLKHI, SETHOLD = CLKHI, DATAVD = CLKHI/2. */
    for (prescale = 1; (prescale <= 128) && (bestError != 0); prescale = 2 * prescale)
    {
        for (clkHiCycle = 1; clkHiCycle < 32; clkHiCycle++)
        {
            if (clkHiCycle == 1)
            {
                computedRate = (sourceClock_Hz / prescale) / (1 + 3 + 2 + 2 / prescale);
            }
            else
            {
                computedRate = (sourceClock_Hz / prescale) / (3 * clkHiCycle + 2 + 2 / prescale);
            }

            absError = baudRate_Hz > computedRate ? baudRate_Hz - computedRate : computedRate - baudRate_Hz;

            if (absError < bestError)
            {
                bestPre = prescale;
                bestClkHi = clkHiCycle;
                bestError = absError;

                /* If the error is 0, then we can stop searching because we won't find a better match. */
                if (absError == 0)
                {
                    break;
                }
            }
        }
    }

    /* Standard, fast, fast mode plus and ultra-fast transfers. */
    value = LPI2C_MCCR0_CLKHI(bestClkHi);

    if (bestClkHi < 2)
    {
        value |= LPI2C_MCCR0_CLKLO(3) | LPI2C_MCCR0_SETHOLD(2) | LPI2C_MCCR0_DATAVD(1);
    }
    else
    {
        value |= LPI2C_MCCR0_CLKLO(2 * bestClkHi) | LPI2C_MCCR0_SETHOLD(bestClkHi) | LPI2C_MCCR0_DATAVD(bestClkHi / 2);
    }

    base->MCCR0 = value;

    for (i = 0; i < 8; i++)
    {
        if (bestPre == (1U << i))
        {
            bestPre = i;
            break;
        }
    }
    base->MCFGR1 = (base->MCFGR1 & ~LPI2C_MCFGR1_PRESCALE_MASK) | LPI2C_MCFGR1_PRESCALE(bestPre);

    /* Restore master mode. */
    if (wasEnabled)
    {
        LPI2C_MasterEnable(base, true);
    }
}
Not crazy about using SDK since they seem to overkill but in this case the timing function can come in handy for testing of the settings before finalizing in the code.
 
@KurtE - @defragster

I made the clock change.

At 100khz I am reading on the scope 227khz so its as I suspected - need to change the other timings as well but it does work at 100khz so just have to figure it out. Without the change at 100khz I was getting about 96khz on the scope which is pretty close to what @manitou got in his initial testing of the setClock function.

Unfortunately, I used a sensor that won't initialize at higher clocks so have to go dig out another sensor - think I have a ssd1306 display around somewhere but I know the 9250 will work so just have to go find it and hook it up.
 
@KurtE - @defragster

Did quite a bit of testing with changing I2C setClock function to try and get it up to 3.3Mhz - which seems to be the max. Switching from 24Mhz clock to the 60Mhz clock I did get it up to 3.03Mhz. Still have to fix the timings for the different clock frequencies. I left the settings the same for 100khz, 400khz and 1Mhz. I did add in the 3Mhz condition.

Using a Pesky Products MPU-9250 I tested the I2C frequencies using the I2C scanner and Kris Winer's MPU-9250 sketch to get the actual data. On the initial testing I didn't use any pullups on SCL/SDA and found you definitely need them to get a good signal especially at the higher frequencies. With the addition of 2.2k pullups got the following results:
Code:
Using a Pesky MPU-9250 with 2.2k pullups on SCL and SDA results got a lot better with the scanner and the MPU9250 sketch itself:
@100khz ---- reading 250khz
@400khz ---- reading 960khz
@1Mhz   ---- reading 2.3 Mhz
@3Mhz  ----- hangs when reading magnetometer data so just based on the scanner getting a little over 3Mhz.  Probably needs better pullups.

Still need to finish tweaking the I2C timings to get a closer approximation to 100/400/1Mhz but getting there.
 
@KurtE - @defragster

Did quite a bit of testing with changing I2C setClock function to try and get it up to 3.3Mhz - which seems to be the max. Switching from 24Mhz clock to the 60Mhz clock I did get it up to 3.03Mhz. Still have to fix the timings for the different clock frequencies. I left the settings the same for 100khz, 400khz and 1Mhz. I did add in the 3Mhz condition.

Using a Pesky Products MPU-9250 I tested the I2C frequencies using the I2C scanner and Kris Winer's MPU-9250 sketch to get the actual data. On the initial testing I didn't use any pullups on SCL/SDA and found you definitely need them to get a good signal especially at the higher frequencies. With the addition of 2.2k pullups got the following results:
Code:
Using a Pesky MPU-9250 with 2.2k pullups on SCL and SDA results got a lot better with the scanner and the MPU9250 sketch itself:
@100khz ---- reading 250khz
@400khz ---- reading 960khz
@1Mhz   ---- reading 2.3 Mhz
@3Mhz  ----- hangs when reading magnetometer data so just based on the scanner getting a little over 3Mhz.  Probably needs better pullups.

Still need to finish tweaking the I2C timings to get a closer approximation to 100/400/1Mhz but getting there.

Cool - hopefully not too much brain damage from the 'Argh!' fight with the refman - is this with the code I saw earlier - or has it been updated in past hours?

Weird clock not letting it go properly lower or higher ...
 
@defragster

Yep - same code, no changes. The only diff was that I used pullups. A necessity at least for this board.

Not really - when we increased the clock the timing had to change. See table 46-9, pg 2879 for examples. I would up using the ones calculated from the code I found in the SDK for clock timings with some of added info from the table. Just have to get it set up correctly and tested now. Going to rewire the setup since its a mess.
 
Ok - tweaked timings now they for the most part match the manual at 400/1M/3.3Mhz:
Code:
@100khz ---- 125khz
@400khz ---- 391khz
@1.0mhz ---- 961khz
@3.0mhz ---- 2.78mhz

Again this is for the MPU9250 so may be a bit different on your setup.

View attachment WireIMXRT.zip

Just in case you want to give it a try.
 
I did want to try it with SSD1306 - will do that now with this update. That board has PullUps … they show on the PinTest code posted on breakout thread.
 
Status
Not open for further replies.
Back
Top