Teensy 4.1 Beta Test

The 8 MB T_4.1 happily running STILL at "Pass 44884 error count: 0"

The 16 MB T_4.1 happily running again at "Pass 11686 error count: 0" and running fine after the '4740' after the time is spaz'd when I touched it.

Have purposefully touched and handled the 16MB with no side effect - but may have been discharged? Maybe in touching I smashed the solder and pin together? Will have to go reflow that chip which I have not done yet looking for repro.

The DataLogger I abuced from a sample has been made into a Library - and just got an update that does validation on collected data with SD writes … will let that run.
That's great news. Was beginning to think something wrong with PSRAM!
 
For what it is worth, I have updated my Excel document for the pinouts up on my github project: https://github.com/KurtE/TeensyDocuments/blob/master/Teensy4 Pins.xlsx
Which is an excel document which has a couple of pages on the T4.1 pins.

Hi KurtE

As far as you know, is this pinout up to date and correct now? I found a Kicad schematic on Github which has many different pin assignments. I guess the schematic is old, but would like to check first.

Also, a couple of the assignments in the 'card-like' page are in red text, e.g. pin 38 CS1-0 and 39 MISO1, is that significant? And, are you still guessing about the pin number ordering from pin 34 onwards?

Thanks
 
can we make this flash MTP accessible?

That was my thinking, i.e., to see if we could use MTP to access the flash or even PSRAM accessible. However, due to issues with MTP and getting it to work again with T4.x had to put it on hold. The flash can use SPIFFS so I would think so?
 
Hi KurtE

As far as you know, is this pinout up to date and correct now? I found a Kicad schematic on Github which has many different pin assignments. I guess the schematic is old, but would like to check first.

Also, a couple of the assignments in the 'card-like' page are in red text, e.g. pin 38 CS1-0 and 39 MISO1, is that significant? And, are you still guessing about the pin number ordering from pin 34 onwards?

Thanks
I removed the comments about guessing about order of pin numbers.... They are the pin numbers.
As for everything correct. I hope I have not made too many mistakes. Today I did update the XBar pins as I found I missed a couple and I was off by one row in the pins 0-5 area.
Again updated and pushed up to Github.

Pins 38, 39 SPI pins. They are in RED as they are not the default pins for this functionality. Although in case of CS1-0 it probably does not need to be RED as no pin by default is setup as hardware CS pin...

But in case of MOSO1

by default if you do SPI1.begin();
Pin 1 will be configured as the MISO pin. But you change this by doing: SPI1.setMISO(39);
 
Nope. The startup code checks the smaller pads first. If no PSRAM chip is found there, the larger pads aren't checked.

FlexSPI is highly configurable. You could create different code that uses only the larger pads and maps the chip at 70000000, which is where the linker script puts EXTMEM variables.

But if using the startup code in the core library, for 8MB RAM the smaller pads must be used.

Sorry for the late question but keep getting sidetracked - so easy to do.

If I only put on a FLASH chip the address of the flash would start at ???????, 0x70000000 or 0x7080000? or if in the initialization for flash only, this would just change from:
Code:
	  FLEXSPI2_FLSHA1CR0 = 0x2000;
	  FLEXSPI2_FLSHA1CR1 = FLEXSPI_FLSHCR1_CSINTERVAL(2)
		| FLEXSPI_FLSHCR1_TCSH(3) | FLEXSPI_FLSHCR1_TCSS(3);
	  FLEXSPI2_FLSHA1CR2 = FLEXSPI_FLSHCR2_AWRSEQID(6) | FLEXSPI_FLSHCR2_AWRSEQNUM(0)
		| FLEXSPI_FLSHCR2_ARDSEQID(5) | FLEXSPI_FLSHCR2_ARDSEQNUM(0);

	  FLEXSPI2_FLSHA2CR0 = 0x40000;
	  FLEXSPI2_FLSHA2CR1 = FLEXSPI_FLSHCR1_CSINTERVAL(2)
		| FLEXSPI_FLSHCR1_TCSH(3) | FLEXSPI_FLSHCR1_TCSS(3);
	  FLEXSPI2_FLSHA2CR2 = FLEXSPI_FLSHCR2_AWRSEQID(6) | FLEXSPI_FLSHCR2_AWRSEQNUM(0)
		| FLEXSPI_FLSHCR2_ARDSEQID(5) | FLEXSPI_FLSHCR2_ARDSEQNUM(0);
to
Code:
	  FLEXSPI2_FLSHA1CR0 = 0x4000;
	  FLEXSPI2_FLSHA1CR1 = FLEXSPI_FLSHCR1_CSINTERVAL(2)
		| FLEXSPI_FLSHCR1_TCSH(3) | FLEXSPI_FLSHCR1_TCSS(3);
	  FLEXSPI2_FLSHA1CR2 = FLEXSPI_FLSHCR2_AWRSEQID(6) | FLEXSPI_FLSHCR2_AWRSEQNUM(0)
		| FLEXSPI_FLSHCR2_ARDSEQID(5) | FLEXSPI_FLSHCR2_ARDSEQNUM(0);
then would start at 0x70000000? Guessing here.
 
As a heads up the extRAM_t4 lib will be changed to support SPIFFS only on the external FLASH chip. Since I have not heard any differently using PSRAM for SPIFFS will no longer be supported!
 
As a heads up the extRAM_t4 lib will be changed to support SPIFFS only on the external FLASH chip. Since I have not heard any differently using PSRAM for SPIFFS will no longer be supported!

So it is still required to hack the core startup.c to change clock frequency and set the FLASH size 0x4000, yes?

my T41 SPIFFS sketches all had my own copy of Frank's EFLASH config code embedded in the sketch, i tired of tracking the changes to the github lib. ;) And I haven't yet attempted to exercise the SPIFFS with latest 1.52 core ...
 
So it is still required to hack the core startup.c to change clock frequency and set the FLASH size 0x4000, yes?

my T41 SPIFFS sketches all had my own copy of Frank's EFLASH config code embedded in the sketch, i tired of tracking the changes to the github lib. ;) And I haven't yet attempted to exercise the SPIFFS with latest 1.52 core ...

Wont have to hack the core when I get done. Got tired of that also. It will be stand alone and should detect if you have no flash, 1psram and no flash (still need to add code for this config) and 1psram and flash or only flash when I get done with it. Here is a zip of the latest for spiffs only if you want to give it a try, almost there:
 

Attachments

  • extRAM_SPIFFS_t4.zip
    53.7 KB · Views: 83
...almost there:
I'll wait

yoda.jpg
 
Only config that I haven't been able test is the one for FLASH only. Any idea for a good library name now that its spiffs flash only.

didn't reply to that note the other day :( … if only for SPIFFS debug and development - having it on PSRAM seemed cool. A lot faster with no FLASH Abuse or wait. And for a suitably battery/constant power system PSRAM based SPIFFS could be good for a system to run and to constant data mods with file support. And faster to dump to SD or other for backup and pull for restore on startup.
 
ared the pads for flash chips usable as GPIO?

The answer is sort of yes... But the stuff added within the last couple of days will have these pins be initially configured to attempt to read these optional chips at startup to figure out if there there and the sizes. So this could be interesting to how they interact with whatever you have hooked up to these pads. From my Excel document... You can see what the pins are... Sorry I now this wont show up properly here.
Code:
														Back Memory Chips													
		EMC_26	4.26		1:12					RX1		P	52			GND											
		EMC_25	4.25							TX1		P	53			50	P		CTS8	MOSI2				1:14		4.28	EMC_28
		EMC_29	4.29		1:15				MISO2			P	54			49	P			SCK2				1:13		4.27	EMC_27
											3.3V				(pin 1)	51	P					SCL1				4.22	EMC_22
																											
		EMC_26	4.26		1:12					RX1		P	52			GND											
		EMC_25	4.25							TX1		P	53			50	P		CTS8	MOSI2				1:14		4.28	EMC_28
		EMC_29	4.29		1:15				MISO2			P	54			49	P			SCK2				1:13		4.27	EMC_27
											3.3V				(pin 1)	48	P		RX8							4.24	EMC_24
 
teensy41_2.jpg


On the bottom psram pads, between outer pins 32 and 30, the bottom 4 pads are, going left to right are:
  • Pad 48 (CS pin)
  • Pad 49
  • Pad 50
  • Ground

On the bottom psram pads, between outer pins 32 and 30, the top pads, going left to right are:
  • 3.3v
  • Pad 54
  • Pad 53
  • Pad 52

On the Flash pads between outer pins 30 and 28, the bottom 4 pads are, going left to right are:
  • Pad 51 (CS pin)
  • Pad 49
  • Pad 50
  • Ground

On the Flash pads between outer pins 30 and 28, the top 4 pads are, going left to right are:
  • 3.3v
  • Pad 54
  • Pad 53
  • Pad 52

I.e. except for the CS pin, the remaining 7 pads are the same between the two solder areas. The psram and flash chips all have a dot on the chip, and you line that up with the dot on the PCB.

The holes next to the micro-SD card reader, are in the same order as the Teensy 4.0, but in a different location. Going from top to bottom on the above picture of the back side, the pins are:
  • Pin 38 on the outer row
  • On/off
  • Program
  • Ground
  • 3.3v
  • Vbat
  • Pin 27 on the outer row

The pins for the USB host are labeled on the PCB (i.e. ground, ground, D+, D-, 5v).

I'm not sure the ethernet pins have names.
 
Last edited:
Need some help with c++ for using external_psram_size in a #if directive.

Right now I have this at the beginning of the sketch:
Code:
extern "C" uint8_t external_psram_size;
static const uint8_t psram_size = external_psram_size;

#include <extRAM_t4.h>
#include <spiffs.h>

extRAM_t4 eRAM;

//Setup files IO
spiffs_file file1;

#define DO_DEBUG 1

char buf[512] = "Hello World! What a wonderful World :)";
char fname[32] = "my_file1";
int szLen = strlen( buf );
elapsedMicros my_us;

#if (psram_size > 0)
	uint16_t writeaddress = 0x00;
	uint8_t valERAM;
	uint8_t *ptrERAM = (uint8_t *)0x70000000;  // Set to ERAM
	const uint32_t  sizeofERAM = 0x7FFFFE / sizeof( valERAM ); // sizeof free RAM in  } }
#endif
before setup. The T4.1 I am using has 1PSRAM and 1FLASH. The problem is that the #if (psram_size > 0) is never executed even though external_psram_size = 8. Tried variations on a theme including external_psram_size directly as the test case.

Any suggestions?
 
Need some help with c++ for using external_psram_size in a #if directive.


Any suggestions?

macros are used for testing compile-time variables, you're trying to use run-time variable with compile-time statements
#define X 2
#if X > 1
....
 
Back
Top