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)
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
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 @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?
@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.
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
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);
@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
CCM_CSCDR2 = (CCM_CSCDR2 & ~CCM_CSCDR2_LPI2C_CLK_PODF(63)) | CCM_CSCDR2_LPI2C_CLK_SEL;
CCM_CSCDR2 = (CCM_CSCDR2 & ~CCM_CSCDR2_LPI2C_CLK_PODF(63));
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.
/*!
* 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);
}
}
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.
@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.
@100khz ---- 125khz
@400khz ---- 391khz
@1.0mhz ---- 961khz
@3.0mhz ---- 2.78mhz
Great. Only really tested with the 9250 so will be good to verify that it works.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.