If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

We will be expanding this list in the coming weeks, with names of many more forum contributors and people who have written Teensy specific libraries. We're only offering the beta test hardware to the people on this list.

For the first round of betas, we have 31 boards with the 1052 chip. These are meant for beta testing only, because the final Teensy 4.0 will use the similar 1062 chip (more RAM, faster I/O, CAN FD). After beta, software support for 1052 will be dropped. These 1052 betas are meant to give you the earliest access. Please understand their software support will be only temporary.

To jump in now with the 1052 beta, please email Robin directly (actual email, not forum PM) with the magic words "I have free time to beta test" and your shipping address. There is no charge for these betas. PJRC will pay for shipping. If you're outside the USA and the carrier charges international tariff/vat/fees when the package arrives, you'll need to cover that cost. We can't pre-pay it from here.

If you're busy with work or life, waiting is perfectly fine. The longer you wait, the closer your board will be to the final release. If you don't have any time to do testing, that's fine too. We will still send you a free Teensy 4.0 as a special "thank you". If you don't get a beta board, just email Robin after release and we'll send you a free Teensy 4.0 from the first production batch.

During this beta, I'd like to ask everyone to follow a few simple rules.

No photos!

Keep all conversations & info on this forum thread

(1052 only) Don't mess with the OTP fuses... On the 1062 boards, do mess with the fuses.

The first 2 allow us to share pretty much all technical info early, but still make an official release. Of course, after we announce Teensy 4.0 on the website and/or Kickstarter, photos will then be ok. Like with prior betas, this forum thread will get painfully long. Please bear with it. Having it all in 1 place before release helps us, and having all the info as text on a forum thread make it accessible for people who want technical details, but (probably) not "news" of a product release.

Wrong fuse settings can permanently brick your board. Final Teensy 4.0 will have critical fuse regions locked. For now, we're leaving all the betas unlocked for maximum flexibility. Overclocking is generally ok, but please use your best judgement if you edit any #define with the comment "Danger Will Robinson", or if you write directly to DCDC_REG3. NXP's datasheet rates the "absolute maximum" at 1.3 volts.

One final note - We're starting this beta very "early" with a ton of stuff not yet completed or fully working on the software side. Things will get better as we go. Messages #2 - #6 are placeholders for updates. I'd like to ask all our "plus" users to please edit these as needed.

That is for example the SDCard pins changed positions in the recent beta. Not sure how he would like to do this. Mini-Pogo pins like Paul did with earlier ones, or with the connector that he used in the recent ones. In which case the exact position does not matter. But as for details:

I then noted in a different message that these positions for pins 24-33 are what you would probably use for POGO pins. But if instead you wish to use through hole SMT pins like used on T3.2 or the like. which it is setup for (except it uses a 2x5 instead of a 2x7), and it is turned 90 degrees. Then the X positions change.

That is instead of x = 1018 you would use 1050 (Pins are between pins 9 and 16)
instead of X = 1182 you would use 1150 (Pins are between pins 10 and 15)

Paul : if you could put links to YOUR versions of the Ref Manuals it would make sure feedback/details come from the 'same page' - though of course some of your early code notes may be from prior RM version. And of course that will also be fun when it comes to 1052 .vs. 1062. Not sure if there is a placeholder post appropriate for that? Maybe post #2 with latest Software

I can tell you the first round of betas will have the pins in msg #181, including pins 24-33 brought to pads on the bottom side.

The pinout definitely will change, at least so we have access to the CAN FD pins on the RT1062 chip. The changes are expected to be fairly minor, between 2 to 5 pins altered. If you have any concerned or input about which pins, *NOW* is the time to read the many messages in this thread and start pouring over the info in NXP's RT1050 & RT1060 reference manuals.

The distinguishing macro symbol is __IMXRT1052__ Yes? Should we worry about 1062 symbol? or a KINETISK equivalent?

That is the only one I see > #if defined(__IMXRT1052__)
Not used much yet [3 matches across 2 files] - would be nice if that went to #if defined(__IMXRT1062__) sooner rather than later/never given those were the chips ordered for release.

<edit>:Frank follows with a good point - 1052 has to allow those items to be found/dropped/changed as pins move etc.

Robin has 12 of the 31 betas ready to ship. I believe so far 7 are claimed, so up to 5 more can ship today if anyone else (on the list) wants to jump in now. I still want to do more tests on the inductors this weekend, which is the reason I'm still holding many of the boards. My hope it to make most or all of the remaining 19 boards available early next week. We're also going to add more names to the list.

If all or most of the 31 are claimed next week, we might schedule one more soldering session on Jan 4th, which would likely yield another 10-12 boards. These will be the last of the 1052 boards. These 31 or ~40 will be the only boards for the next several weeks, until we get the 1062 chips and I can get around to making a board rev for the CAN FD pins.

When you get your board, you should see a number written on the bottom. They're numbered 2 to 33. For anyone counting, 9 didn't work for reasons unknown, and 1 is the beta I've been using, and so far the only board that's been abused with over-voltage overclocking. The boards also have a serial number in the mac address field in the fuse memory, where the number is 1000XX where XX is the number written on your board.

The bootloader makes the first 1536K of the flash available for uploading. The last 512K is "reserved", never programmed nor erased by the bootloader. The top 4K has a copy of a small program which gets copied to the beginning of the flash during the full erase after you've held the button for 15 seconds. Some portion of the top memory will become used by the EEPROM emulation. I'm still undecided what will be done with the rest of that 512K. Maybe a small filesystem like ESP uses? Or maybe we'll expand the bootloader's usage to allow larger programs? So many things left to do...

Tonight and tomorrow I'm going to put in a couple long sessions to fix up more of the core library and convert C code I wrote weeks ago to SPI & Wire libs and then package up installers. If your board arrives and I still haven't put installers on msg #2, please ping me and I'll quickly wrap things up whereever they're at and make a set of installers.

The bootloader now has a red LED to show you status. There is a known timing bug which causes it to flicker. I'll fix that in a couple weeks, after first working on much-needed stuff in the libraries, so please try to ignore the flickering. It's a known bug.

Here are the LED status signals:

Dim blinking = bootloader is waiting for USB enumeration (eg, external power without a USB cable, or a charge-only cable)

Brief dim flash after holding button for ~13 seconds = visual cue to release your finger *now* if you want to initiate full erase. (and of course if you release in time, the LED will be bright for many seconds while doing the full erase)

Will probably start on some on some of the components and libraries I have done stuff on, like serial, SPI, Wire, and maybe play with ili9341 code. But wondering approach for libraries like ili9341_t3, where a lot of the speed gains was due to the spi fifo queue, which Idont believe these chips support. Are you thinking we should integrate in DMA support? Or just make it work?

Will probably start on some on some of the components and libraries I have done stuff on, like serial, SPI, Wire, and maybe play with ili9341 code. But wondering approach for libraries like ili9341_t3, where a lot of the speed gains was due to the spi fifo queue, which Idont believe these chips support. Are you thinking we should integrate in DMA support? Or just make it work?

I formatted the list in Post #6 as a table.
At the last beta test there were some confusions, because several people worked on the same topic ( - for example make a lib compatible - ) without knowing about each other (happened to me sevreal times...). It would be great if you put your name there as soon as you start working on a topic, so that we don't do the same things.

I wrote to Robin today that I was ready to give my list position to another person since I won't be able to do much testing/developing until earliest mid February. But I will naturally read and follow here how it goes.

I'm still undecided what will be done with the rest of that 512K. Maybe a small filesystem like ESP uses? Or maybe we'll expand the bootloader's usage to allow larger programs?

If it was more than 512k, I'd say a filesystem would be good. With 512k only, I'd say use 256k for a giant eeprom, and add the remaining 256k to the programs..
Or..512k for eeprom.. this way it can be used for a filesystem - by the user.

To jump in now with the 1052 beta, please email Robin directly (actual email, not forum PM) with the magic words "I have free time to beta test" and your shipping address. There is no charge for these betas. PJRC will pay for shipping. If you're outside the USA and the carrier charges international tariff/vat/fees when the package arrives, you'll need to cover that cost. We can't pre-pay it from here.

If you are outside the US can you also include your phone number when you give me your address. We need to include it for customs.

Yeah - I already started looking at what's needed to get this implemented. To get the throttle back functions implemented need to look at throttling back the system clock. According to the manual 10.4.2.2 Thermal-aware power management - you can "implement temperature aware DVFS... as well temperature aware frequency scaling for other system components....". The example in the SDK just scales back the AHB_clk frequency until the lower temperature is reached then boosts it back up. With DVFS (still have to figure out how that works) you can change the modes to WAIT State or SUSPEND state. Looking through the sdk example now. Need a few things added to imrtx.h file to get it working though see post https://forum.pjrc.com/threads/54265...l=1#post193773.

Really not sure about the octop registers - only needs one so maybe we can hardcode that one.

I would'nt do throttling. For "critical", just a reset (that resets the chip, and disables pins) - on startup check the reset-reason and HALT. For "hot", just the event and leave the reaction to the user/program.. any other action could be unexpected and lead to questions or unwanted behaviour (if the T4 does something important or dangerous..this knows the user only)

Edit: with "eventresponder"
Maybe we can add some examplecode how to throttle for the case that the event "fires"... ?

Was actually looking at implementing both ways eventually. The SDK code is rather convoluted if you get into it and was planning on taking this incrementally especially since I never played around with this at this level . Plan was going to get the throttling done first then do the DVFS piece. Was thinking you could also use the temp monitor to get some temperature profiles just as a test. Any help would be appreciated.

EDIT: Actually, have a good sdk example could use for ideas and guidance - the power-mode-switcher application that @manitou mentioned. Relatively straight forward. Getting good at going through the SDK.