Teensy 4.0 First Beta Test

Status
Not open for further replies.
Just to confirm for reference note - the latest Ribbon T4B2m on breakout [ 2nd tested white wire B2m ]:
--> I cannot cause a brown out fail to start.
> With VBat powered by a cr2032 when unpowered by USB or any UARTS WILL Honor the power button:
>> take a 5 second POWER press as an OFF when again powered if unpowered when ON
>> take a short POWER press as an ON when again powered if unpowered when OFF
> with single UART Rx/Tx on Serial4 to T_3.1 - and 0V VBat - the POWER button is ignored when unpowered - no visible Green LED glow.
> with UART Rx/Tx on Serial4 to T_3.1, and Serial2 to T_3.5 - and 0V VBat - the POWER button is Honored when unpowered - visible Green LED glow.

And the EEPROM GetPut posted works well for uint32_t in [0], and then groups of expanded Float+MyObject to end of EEPROM
> when Packed to odd bytes [19], or unpacked with 24 bytes
-- and when started on any of 4 byte boundary offsets
-- works across Multiple cycles through EEPROM
>> It works on USB cable pull, or processor restart/Reset
>> With EEPROM fix - the spurious error with shifted data is gone - probably from unseen failure to write the starting index location as @manitou discovered

Prior note tested CAN2 on CANFD port.

Also tested USB_Host SD card and HDD and USB FLASH to work.
 
I've committed a fix for the eeprom problems after a cold boot.
I'll second what everyone else has said. That looks like it fixed it. Ran 2 tests:

(1) write from serial monitor a series of numbers or chars to the EEPROM, verified it wrote those values to the EEPROM. Un/Re-plugged the USB cable in wrote a different set of chars to the eeprom and yeah verily it wrote it fine to the EEPROM.

(2) Hooked up the Prop Shield and ran CalibrateSensors with MotionCal App. After cal did the send to CAL and got the check that it sent. From calibrate sensor sketch (moded it to read the cal data and send to Serial1) I verified that it wrote the values:
Code:
Calibration Data
Magnetic (Hard Iron) Offsets
  17.22 uT
  -8.51 uT
  64.54 uT

Magnetic Soft Iron Mapping
  0.9758  -0.0193  -0.0073
  -0.0193  0.9986  -0.0025
  -0.0073  -0.0025  1.0267

Expected Magnetic Field Strength
  40.01 uT
Next ran the PrintCal sketch and got pretty much the same numbers as another verification:
Code:
  Calibration Data

Magnetic (Hard Iron) Offsets
   17.22 uT
  -8.51 uT
   64.55 uT

Magnetic Soft Iron Mapping
   0.9756  -0.0192  -0.0077
  -0.0192   0.9985  -0.0026
  -0.0077  -0.0026   1.0270

Expected Magnetic Field Strength
   40.01 uT

As reference this is a screenshot from motion cal:
Capture.JPG
 
I've committed a fix for the eeprom problems after a cold boot.

https://github.com/PaulStoffregen/cores/commit/710f215feec990f15026278be1a2d634ee29c450

The bootloader does indeed fully initialize the FlexSPI LUT memory. Even if a LUT contains a stop instruction, turns out the hardware gets upset if any of LUT's the 8 instructions are invalid, even after a stop. I didn't realize this until now (kind of assumed it didn't read anything after the stop instruction - NXP's manual doesn't really say either way but kind of implied it reads the LUT's instructions in order), so the code was depending on the bootloader leaving the LUTs in a "clean" state. These extra initialization writes should fully solve the problem where the LUT table has unknown garbage after a cold boot.

I am glad that fixed it! I was wondering, which is why in the last test run, I printed out LUT60-63 and that was going to be my next thing to try but got hit by another diversion...

What made me wonder about this was section 26.7.7 (page 1784 of new rev of manual) The note under the table:
If the instruction number needed is less than 8 for a flash
transaction, STOP instruction should be programmed for the
unneeded instructions (instruction code 8'h00).

I also confirmed the fix :D I ran the last test again and now after re-powering the T4...
Code:
CCM_CCGR6: fcff3fc3 CCM_CCGR7: ffffffff
byte 0 98
FLEXSPI MCR0:ffff8010 MCR1:7736ffff MCR2:200001f7 AHBCR:78 INTEN:0 INTR:40 RFDR0:77f2db4a
    LUT60:64bf3240 LUT61:d292adcc LUT62:16f89264 LUT63:865f453b
FLEXSPI MCR0:ffff8010 MCR1:7736ffff MCR2:200001f7 AHBCR:78 INTEN:0 INTR:40 RFDR0:44
    LUT60:24010405 LUT61:0 LUT62:0 LUT63:0
input 99 byte 0 99
EEPROM length: 1080
Contents:
0:63 1:1 2:2 3:3 4:4 5:5 6:6 7:7 8:8 9:9 a:a b:b c:c d:d e:e f:f 
10:10 11:11 12:12 13:13 14:14 15:15 16:16 17:17 18:18 19:19 1a:1a 1b:1b 1c:1c 1d:1d 1e:1e 1f:1f 
20:20 21:21 22:22 23:23 24:24 25:25 26:26 27:27 28:28 29:29 2a:2a 2b:2b 2c:2c 2d:2d 2e:2e 2f:2f 
30:30 31:31 32:32 33:33 34:34 35:35 36:36 37:37 38:38 39:39 3a:3a 3b:3b 3c:3c 3d:3d 3e:3e 3f:3f 
40:40 41:41 42:42 43:43 44:44 45:45 46:46 47:47 48:48 49:49 4a:4a 4b:4b 4c:4c 4d:4d 4e:4e 4f:4f 
50:50 51:51 52:52 53:53 54:54 55:55 56:56 57:57 58:58 59:59 5a:5a 5b:5b 5c:5c 5d:5d 5e:5e 5f:5f 
60:60 61:61 62:62 63:63 64:64 65:65 66:66 67:67 68:68 69:69 6a:6a 6b:6b 6c:6c 6d:6d 6e:6e 6f:6f 
70:70 71:71 72:72 73:73 74:74 75:75 76:76 77:77 78:78 79:79 7a:7a 7b:7b 7c:7c 7d:7d 7e:7e 7f:7f 
80:80 81:81 82:82 83:83 84:84 85:85 86:86 87:87 88:88 89:89 8a:8a 8b:8b 8c:8c 8d:8d 8e:8e 8f:8f 
90:90 91:91 92:92 93:93 94:94 95:95 96:96 97:97 98:98 99:99 9a:9a 9b:9b 9c:9c 9d:9d 9e:9e 9f:9f 
a0:a0 a1:a1 a2:a2 a3:a3 a4:a4 a5:a5 a6:a6 a7:a7 a8:a8 a9:a9 aa:aa ab:ab ac:ac ad:ad ae:ae af:af 
b0:b0 b1:b1 b2:b2 b3:b3 b4:b4 b5:b5 b6:b6 b7:b7 b8:b8 b9:b9 ba:ba bb:bb bc:bc bd:bd be:be bf:bf 
c0:c0 c1:c1 c2:c2 c3:c3 c4:c4 c5:c5 c6:c6 c7:c7 c8:c8 c9:c9 ca:ca cb:cb cc:cc cd:cd ce:ce cf:cf 
d0:d0 d1:d1 d2:d2 d3:d3 d4:d4 d5:d5 d6:d6 d7:d7 d8:d8 d9:d9 da:da db:db dc:dc dd:dd de:de df:df 
e0:e0 e1:e1 e2:e2 e3:e3 e4:e4 e5:e5 e6:e6 e7:e7 e8:e8 e9:e9 ea:ea eb:eb ec:ec ed:ed ee:ee ef:ef 
f0:f0 f1:f1 f2:f2 f3:f3 f4:f4 f5:f5 f6:f6 f7:f7 f8:f8 f9:f9 fa:fa fb:fb fc:fc fd:fd fe:fe ff:ff 

Raw Data
EEprom Page:0 addresses(601f0000 - 601f1000): first free: 601f008a
  000(00)=08  001(01)=09  002(02)=0a  003(03)=0b  060(04)=44  061(05)=45  062(06)=46  063(07)=47  120(08)=80  121(09)=81  122(0a)=82  123(0b)=83  180(0c)=bc  181(0d)=bd  182(0e)=be  183(0f)=bf
  240(10)=f8  241(11)=f9  242(12)=fa  243(13)=fa *300(14)=b3 *301(15)=b3 *302(16)=b3 *303(17)=b3  243(13)=fb  000(00)=78  000(00)=0d  000(00)=79  000(00)=0d  000(00)=00 *001(01)=01 *002(02)=02
 *003(03)=03 *060(04)=3c *061(05)=3d *062(06)=3e *063(07)=3f *120(08)=78 *121(09)=79 *122(0a)=7a *123(0b)=7b *180(0c)=b4 *181(0d)=b5 *182(0e)=b6 *183(0f)=b7 *240(10)=f0 *241(11)=f1 *242(12)=f2
 *243(13)=f3  000(00)=78  000(00)=0d  000(00)=78  000(00)=0d  000(00)=78  000(00)=59  000(00)=31  000(00)=32  000(00)=35  000(00)=31  000(00)=32  000(00)=37  000(00)=38  000(00)=31  000(00)=61
  000(00)=63  000(00)=31  000(00)=61  000(00)=62 *000(00)=63
This also verified how the data was output into the first sector...
 
EEPROM side note - probably not worth investigating...

With eeprom_read_byte - it always scans the complete used part of the sector to find the last time a value was set:
Code:
uint8_t eeprom_read_byte(const uint8_t *addr_ptr)
{
	uint32_t addr = (uint32_t)addr_ptr;
	uint32_t sector, offset;
	const uint16_t *p, *end;
	uint8_t data=0xFF;

	if (addr > E2END) return 0xFF;
	if (!initialized) eeprom_initialize();
	sector = (addr >> 2) % FLASH_SECTORS;
	offset = (addr & 3) | (((addr >> 2) / FLASH_SECTORS) << 2);
	//printf("ee_rd, addr=%u, sector=%u, offset=%u, len=%u\n",
		//addr, sector, offset, sector_index[sector]);
	p = (uint16_t *)(FLASH_BASEADDR + sector * 4096);
	end = p + sector_index[sector];
	while (p < end) {
		uint32_t val = *p++;
		if ((val & 255) == offset) data = val >> 8;
	}
	return data;
}
I know when I was playing around with the OpenCM9.04 boards eeprom code, I got a slight speed up when I started from the end and scanned back toward the start of the sector as I could return as soon as I found any value for the index...

Something like:

Code:
uint8_t eeprom_read_byte(const uint8_t *addr_ptr)
{
	uint32_t addr = (uint32_t)addr_ptr;
	uint32_t sector, offset;
	const uint16_t *p, *begin;

	if (addr > E2END) return 0xFF;
	if (!initialized) eeprom_initialize();
	sector = (addr >> 2) % FLASH_SECTORS;
	offset = (addr & 3) | (((addr >> 2) / FLASH_SECTORS) << 2);
	//printf("ee_rd, addr=%u, sector=%u, offset=%u, len=%u\n",
		//addr, sector, offset, sector_index[sector]);
	begin= (uint16_t *)(FLASH_BASEADDR + sector * 4096);
	p = begin + sector_index[sector] -1;
	while (p >= begin) {
		uint32_t val = *p--;
		if ((val & 255) == offset) return val >> 8;
	}
	return 0xff;
}
Note: made changes here on fly did not try in code, need to verify some edge conditions like page full, page empty...
 
Just got my shiny new Breakout board and new T4 (now calling it T4B2B - last B is for Battery Holder) :).

Ran ListFiles from SD library with out issue. Only thing is can't specify CS as pin 36 had to specify it as BUILTIN_SDCARD. Also you have to specify:
Code:
  SPI.setMOSI(35);
  SPI.setSCK(37);
  SPI.setSCK(34);
to get it to work.

Also ran the uSDFS code that we used to identify partitions and it worked and identified the single partition and FAT32 format. Believe @defragster already ran some other tests with uSDFS library.

EDIT1:
On the exFAT partition with the default settings for buffersize I am seeing:
Code:
Change drive
A_00001.dat
stat FR_OK 0
 opened FR_OK 0
................................................................
.................................... (3010996 - [B]10.882777 MB/s[/B])
 (open: 9016 us; close: 8979 us; write: min,max: 2977 3979 us)
 
Last edited:
Just got my shiny new Breakout board and new T4 (now calling it T4B2B - last B is for Battery Holder) :).
...

Battery holder is on the breakout though … I was calling it Ribbon due to the SD pin spacing change ...

I wondered about a new indicator - but so far the T4 on the newest board - with the Ribbon still has White Wire edit and only the SD ribbon pin spacing was the noted intended change so T4B2m? {or T4B2r if it shows any diffs}

Anyhow it is a really nice looking package - and indeed PCB washed nice and clean on nice base!

Anyone lurking here on the Beta list if you have time to practice some 'Normal Use' - or following the Msg#4 and #6 status/issues list - it would be a good time to send an email if not too late and 'Get Some' - and have a chance to see it early and maybe come across something otherwise unfound that would be a bother later.
 
Battery holder is on the breakout though … I was calling it Ribbon due to the SD pin spacing change ...

I wondered about a new indicator - but so far the T4 on the newest board - with the Ribbon still has White Wire edit and only the SD ribbon pin spacing was the noted intended change so T4B2m? {or T4B2r if it shows any diffs}

Anyhow it is a really nice looking package - and indeed PCB washed nice and clean on nice base!

Anyone lurking here on the Beta list if you have time to practice some 'Normal Use' - or following the Msg#4 and #6 status/issues list - it would be a good time to send an email if not too late and 'Get Some' - and have a chance to see it early and maybe come across something otherwise unfound that would be a bother later.

In that case I will call it T4B2R = for ribbon :) Hate to just use wire.

I actually meant to add to my post that the quality of workmanship and attention to details on the products that PJRC puts out, example the breakout boards, not to mention the Teensies never ceases to amaze me :).
 
In that case I will call it T4B2R = for ribbon :) Hate to just use wire.

Yeah - there are two versions with wire - but the Ribbon is the first with added bottom silkscreen of the Model #

I actually meant to add to my post that the quality of workmanship and attention to details on the products that PJRC puts out, example the breakout boards, not to mention the Teensies never ceases to amaze me :).

Quality is impressive - From Teensy itself to the multiple breakout designs and assembly allowing for using the various functional parts. Makes it clear that a lot of thought/work/planning/mastery goes into each Teensy. And amazing that they cost near/under an UNO/etc for so much more. Not to mention the reliable 'magic sauce' bootloader MCU is included in that - offering good design protect of that effort and long term usability with ease.
 
SD Library:

Was running through the examples from the SD library:
Cardinfo.ino - works no problem
listfiles - woks no problem
readwrite.ino - not working:
Code:
Initializing SD card...initialization done.
Stops - nothing write
:
Datalogger.ino - not working:
Code:
Initializing SD card...card initialized.
stops at this point

UPDATE:
1. Ran DataLogger on the T4B2M (wire on bottom) using the Builtin_sdcard and got the same results as the T4B2R.
2. Ran DataLogger on both versions of the T4 except using the SD card on the audio shield and in both cases the sketch ran and wrote files to the SD Card.
 
Last edited:
SDFAT Library

Reran the SDFAT library modifications i made back in post #2685 but with a Lexar633x 128GB card - reformatted with the formatting sketch to FAT32 in SDFat Library and ran the sdinfo sketch - this time at 50Mhz:

Code:
SdFat version: 1.0.5

Assuming the SD is the only SPI device.
Edit DISABLE_CHIP_SELECT to disable another device.

Assuming the SD chip select pin is: 10
Edit SD_CHIP_SELECT to change the SD chip select pin.

type any character to start

init time: 2 ms

Card type: SDXC

Manufacturer ID: 0X95
OEM ID: SU
Product:      
Version: 0.2
Serial number: 0X520AB128
Manufacturing date: 3/2015

cardSize: 128042.66 MB (MB = 1,000,000 bytes)
flashEraseSize: 128 blocks
eraseSingleBlock: true
OCR: 0XC0FF8000

SD Partition Table
part,boot,type,start,length
1,0X0,0XC,8192,250075136
2,0X0,0X0,0,0
3,0X0,0X0,0,0
4,0X0,0X0,0,0

Volume is FAT32
blocksPerCluster: 128
clusterCount: 1953456
freeClusters: 1953455
freeSpace: 128021.63 MB (MB = 1,000,000 bytes)
fatStartBlock: 10436
fatCount: 2
blocksPerFat: 15262
rootDirStart: 2
dataStartBlock: 40960

type any character to start
Still works with the SD Card Reader on the Audio Shield.
 
Anyone lurking here on the Beta list if you have time to practice some 'Normal Use' - or following the Msg#4 and #6 status/issues list - it would be a good time to send an email if not too late and 'Get Some' - and have a chance to see it early and maybe come across something otherwise unfound that would be a bother later.

Indeed, at this moment I have 5 more beta+breakout boards ready to go, and parts to build 10 more. After those 15 are claimed, the beta will be officially closed. Everyone else who didn't get beta hardware will automatically get a production board (without the fancy breakout hardware) when we release (likely mid-July time frame).

I'm going to send an email reminder soon to everyone on the beta testers list who hasn't requested hardware yet. If you're following this thread and reading this message and have time to do any beta testing, now's the moment to claim one of those last 15 beta boards.

The current betas with the white mod wire are electrically identical to the final PCB, where that extra wire was added in layer #4. The production PCB are being fabricated now, so I can say with absolute confidence we will not have any more hardware changes. It's all software-only testing from here.
 
Indeed, at this moment I have 5 more beta+breakout boards ready to go, and parts to build 10 more. After those 15 are claimed, the beta will be officially closed

Wow, I totally missed that I was on the Beta list!!!! Missed that message entirely (and I am following the thread quite closely)!!
First thing: thanks a lot, it's an honor! I really mean it.

Unfortunately I've no spare time for at least 3 more weeks (deadline for a Teensy-based project :) + a trip), so, while I would love to get a beta T4 board, I could not contribute much up to, say, end of June. :(
I could run some tests I have in mind on the T4beta after that, if you think my contribution would still be of some use...?
But I don't want to hijack a beta board if someone can put it to better use.

Thanks again for putting me on the list!
 
SDFat vs SDFat-Beta

Just discovered that Bill Greiman has updated his SDFat library to SDFat -Beta. It runs out of the box without any modifications for the T4. It also supports FAT16/FAT32 and exFAT SD cards. I have been testing it on the T4B2W version. Just can't figure out how to get it to read the builtin_sdcard (one on board). Supposedly all you have to do is something like this:
Code:
#define SD1_CONFIG SdSpiConfig(36, DEDICATED_SPI, SD_SCK_MHZ(18), &SPI1)
.
 
The production PCB are being fabricated now, so I can say with absolute confidence we will not have any more hardware changes. It's all software-only testing from here.

Hi Paul, is it the same form factor as the Teensy 3.2? Are there any photos or images? I just went through the last 30 pages of the thread but couldn't see any :)

Steve
 
Hi Paul, is it the same form factor as the Teensy 3.2? Are there any photos or images? I just went through the last 30 pages of the thread but couldn't see any :)

Steve

You should look at the first page, to get a summary of information. Also note in the first posting of this thread:
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.
 
Yes I read the post from December but wondered if Paul posted anything more recently (126 page forum threads aren't the easiest to navigate).
To be honest all I want to know right now is the size of the board in mm to see if I can upgrade my 3.2 products to use it without too much bother.
 
yep understood, fingers crossed its no wider than 19mm ;)

It is the same 7 pins wide across the short end and 14 pins down the long edges and pin spacing is still 0.1". Looks like a T_3.1 overall - with the legs gone from the same size MCU body with some shifting in components ...
 
There is actually most of the information about what will be the new board contained within this thread:

Examples: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=200758&viewfull=1#post200758
Where Paul states:
VIN at x=50, y=650

The plan is for T4 to match the form factor T3.2, at least for overall size and the 28 outside pins.

Also information about the location of the main surface mount pins

Posting: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=200666&viewfull=1#post200666
Talks about the locations of the surface mount pins under the new T4:

Code:
Pin 24: x=1182, y=550
Pin 25, x=1018, y=550
Pin 26: x=1182, y=450
Pin 27, x=1018, y=450
Pin 28: x=1182, y=350
Pin 29, x=1018, y=350
Pin 30: x=1182, y=250
Pin 31, x=1018, y=250
Pin 32: x=1182, y=150
Pin 33, x=1018, y=150
USB2 D+, x=72, y=305
USB2 D+, x=72, y=395

Note I did not include the SD Card pin locations here as they changed:

As I noted in another posting, that Pins 24-33 are the locations for pogo like pins... If you are going to use pogo pins. If you are going to use the surface mount solder pins like T3.x
I believe: The x Positions would probably be 1018 -> 1050 and the 1182 -> 1150 I think? (Posting 1981)

Later the SD Card pads changed to allow a HFW8R-1STE1LF (or similar FFC connector): https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=206543&viewfull=1#post206543
Code:
SD DAT1, x=361.22, y=487.80
SD DAT0, x=361.22, y=448.43
SD GND, x=361.22, y=409.06
SD CLK, x=361.22, y=369.69
SD 3.3V, x=361.22, y=330.32
SD CMD, x=361.22, y=290.95
SD DAT3, x=361.22, y=251.58
SD DAT2, x=361.22, y=212.21

While not stated here in these messages: From Posting #3 You have the
additional 5 pins at the far end: ON/OFF, Program GND 3.3v and VBAT

Where ON/OFF is near pin 13 and VBAT near pin 12...
 
SDFat vs SDFat-Beta

Just discovered that Bill Greiman has updated his SDFat library to SDFat -Beta. It runs out of the box without any modifications for the T4. It also supports FAT16/FAT32 and exFAT SD cards. I have been testing it on the T4B2W version. Just can't figure out how to get it to read the builtin_sdcard (one on board). Supposedly all you have to do is something like this:
Code:
#define SD1_CONFIG SdSpiConfig(36, DEDICATED_SPI, SD_SCK_MHZ(18), &SPI1)
.
Not sure if Bill ported the T4 specific uSDHC code (for build-in uSD card) to his library (the "SdFat-beta/src/SdCard/SdioTeensy.cpp" only handles Teemsy3.5 3.6)
So only SPI may be working
Bill however reorganized the SdFat-Beta 27 days ago so maybe he is working on something
 
@WMXZ
From what I saw the T4 specific uSDHC code for SDIO hasn't been ported over yet. Right now just trying to get the SPI code working for SPI1 on the T4 but can't figure out to get to register to SPI1. The construct that I posted and the option in SDConfig should just use HW SPI going to SPI1 but just seems like it just goes to SPI pins?

EDIT: At least with the Beta I didn't have to do any modifications to account for the 1062.
 
Status
Not open for further replies.
Back
Top