Teensy 4.1 Beta Test

Thank you. If you like, I can go through the datasheet and double-check for you.
It would be great if you and anyone else goes through this and lets me know the places I messed up. I go through different pieces of it at different times as I work on some of the different sub-systems and find some things off. Like over the weekend figured out the XBar data was off...
 
@mjs513 @defragster @Paul - Now that 1.52 is released it would great if we could maybe muck a little with linker scripts and allocaters and ...

Example we should probably add in defines in the linker script to have a way at run time to know where things are. Example (probably completely wrong)
I added:
Code:
	_setext = ADDR(.bss.extram);
	_eetext = ADDR(.bss.extram) + SIZEOF(.bss.extram);
Then mucked with an example sketch
Code:
 EXTMEM uint8_t extmem_notinit[512]; 
  EXTMEM uint8_t extmem_init[] = {1,2,3,4,5,6,7,8};

...
  Serial.printf("Addr extmem_notinit %x", (uint32_t)extmem_notinit); 
  Serial.printf("Addr extmem_init %x", (uint32_t)extmem_init);

And it compiled and I went to the temp folder and used the compiler/linker command nm to print out symbols to file... Brought into sublime text and sorted and it included:
Code:
70000000 b $d
[COLOR="#FF0000"]70000000 B _setext[/COLOR]
70000000 B extmem_notinit
70000200 B extmem_init
[COLOR="#FF0000"]70000208 B _eetext[/COLOR]
aaaaaaab A _flexram_bank_config
Which I know is not complete as I am assuming that we will need to know where the initialized and uninitialized areas are, and for init, probable where in flash that is...

But we could then hopefully get data on knowing where the HEAP either should start or end...

And on side not: I also think it would be interesting if we could have some alternate linker scripts that maybe reserves something like 2MB just below EEPROM that maybe we could have a SPIFFS logical drive and maybe this area could then be preserved even through uploads... But maybe wishing for too much.
 
And on side not: I also think it would be interesting if we could have some alternate linker scripts that maybe reserves something like 2MB just below EEPROM that maybe we could have a SPIFFS logical drive and maybe this area could then be preserved even through uploads... But maybe wishing for too much.

yes, this would be helpful to circuitypython/micropython "disk drive" and maybe Teensy could support popping up a USB drive ... Paul had some discussion on the circuitypython thread
 
And on side not: I also think it would be interesting if we could have some alternate linker scripts
Me too, esp to keep more code in the program flash to minimze ITCM-Usage (-> maximize DTCM space) if desired by the user. Only "FASTRUN" code would be copied to ITCM.
I have such scripts including a nice way to switch to them via Arduino-menu.

I've modfied boards.txt a bit more, now I can select if I want GCC 9 or GCC 5 via menu.
 
Hi,
I finally received the pre-sample last Thursday. This w-e I soldered the psram and the test went ok. Then I decided to solder the header pin and test my Amiga emulator port now running on the T4.0 but it seems I don't have 3.3 v on none of the 2 pins. There is a small wire from the regulator to the pin 3 but no voltage on pin 3 also. Is there an easy location I can use to bridge. I was thinking usb header or psram track. I need to power my display from the 3.3 v.... What is best to use. Anyone had same issue with presamples?

On the beta board I received, the ground pin between VIN and 3.3v was not connected. Similarly, the ground pin between pins 13 and 41 was not connected. The ground pin next to pin 0 and the ground pin in the middle row of pins between the micro-SD card and the program button were connected.

The 3.3v pin between pins 12 and 24 were not connected. The normal 3.3v pin next to pin 23 and the 3.3v pin in the middle row of pins between the micro-SD card and the program button were connected.

There was a white jumper wire connecting a chip to the 3.3v pin.
 
Hi Michael and mjs513

I also have the same white wire but no 3.3v there for me.
Or the wire is not soldered properly or the side connected to the pin is the issue.
Or may be ground is the issue too...

Will try again this evening...

Thanks...
 
Michael,
Thanks again! The ground pin was indeed the problem. Not the 3.3 v. The one on the corner is ok. not the one next to 3.3 v at opposite side.
 
Fantastic!!!
Commodore amiga emulation working full speed now on the T4.1.
No need to split the 512k memory in 2 parts to fit it with all pointers boundary issue...
And I can even go for 1MB chipram + 7(4) MB fast ram!
Waw. I did not expect it.
I am really impressed by the PSRAM usage. It is just seamless!

And I can add the sound now as I was on the edge to add it on the T4....

This little beast is what I was looking for.
Combining memory and fast CPU.

SNES emulation will also be easy!
MAME bigger ROMs...
And I guess python fans are also happy ;-)

Great job Paul and others for the PSRAM driver!
Would be great to have such PSRAM driver on the T4.0.
I guess there is no real reason not to have it.
Is the PSRAM sharing the same SPI as the main flash?
 
Great job Paul and others for the PSRAM driver!
Would be great to have such PSRAM driver on the T4.0.
I guess there is no real reason not to have it.
Is the PSRAM sharing the same SPI as the main flash?

As I understand it, the SPI is not the same. I was asking a similar question before and the answer was it uses FlexSPI rather than the normal SPI (LPSPI). I believe the necessary pins are not brought out in the Teensy 4.0 that you could use the second flexspi device. The first flexspi device is used for the flash memory.
 
@Jean-Marc - the PSRAM and FLASH pads on the bottom pull unique FLEXSPI pins for QSPI from the 1062 on the T_4.1. Those pins are not available on the T_4.0 :( You'll see the MCU package is larger on the 4.1 than 4.0 in order to have more room to pull out the pins added for ethernet and QSPI and the extra I/O.
 
I did change the flash initialization which may be the reason we have different times at the same time I added fs_unmount. Not sure if that would make a difference but maybe.

Re: T4.1 SPIFFS

With 1.8.12 and 1.52 and the new SPIFFS lib, I decided to update my Ethernet lwip_tftpd_SPIFFS sketch. I got compile errors because of typedef conflict between lwip and spiffs for s32_t and u32_t. I solved it by hacking spiffs_config.h and using #define ... sigh :(
 
Re: T4.1 SPIFFS

With 1.8.12 and 1.52 and the new SPIFFS lib, I decided to update my Ethernet lwip_tftpd_SPIFFS sketch. I got compile errors because of typedef conflict between lwip and spiffs for s32_t and u32_t. I solved it by hacking spiffs_config.h and using #define ... sigh :(

Where's the Ethernet lwip_tftpd_SPIFFS posted.
 
Ok - getting this error when I try and compile. Have to go do something but will be back:
Code:
libraries\lwip\src/include/lwip/ip_addr.h:40:22: fatal error: lwip/opt.h: No such file or directory
 
Ok - getting this error when I try and compile. Have to go do something but will be back:
Code:
libraries\lwip\src/include/lwip/ip_addr.h:40:22: fatal error: lwip/opt.h: No such file or directory

well that error means you haven't hacked boards.txt to add the include mod described in the README .... then you'll get the typedef conflict ;)

(i could create a SPIFFS version of tftpd for the NativeEthernet -- I've only done the SD lib version ... someday. And i'm still thinking about hacking STM332duino ethernet lib since it has refactored lwip lib so you don't need the boards.txt hack AND it has the Arduino Ethernet API like NativeEthernet llib)
 
Re: T4.1 SPIFFS

With 1.8.12 and 1.52 and the new SPIFFS lib, I decided to update my Ethernet lwip_tftpd_SPIFFS sketch. I got compile errors because of typedef conflict between lwip and spiffs for s32_t and u32_t. I solved it by hacking spiffs_config.h and using #define ... sigh :(

Yeah - I forgot to read the readme. Anyway don't think there is anyway around it but to hack spiffs_t4 itself. Tried a few things but everything I tried caused other things. Only recourse would be to modified SPIFS lib to use different typefef names - argh.
 
Yeah - I forgot to read the readme. Anyway don't think there is anyway around it but to hack spiffs_t4 itself. Tried a few things but everything I tried caused other things. Only recourse would be to modified SPIFS lib to use different typefef names - argh.

I just checked my notes. I had to fix those typedef conflicts with the previous version of SPIFFS lib when used with lwip

Code:
           hack libraries/SPIFFS_t4/src/spiffs_config.h
           //  typedef signed int s32_t;
           #define s32_t int
           //  typedef unsigned int u32_t;
           #define u32_t uint32_t

... whatever
 
I just checked my notes. I had to fix those typedef conflicts with the previous version of SPIFFS lib when used with lwip

... whatever

No longer a hack. I have a feeling this might come up again since I've seen that before so I just changed spiffs_config.h so it reads like this:
Code:
  //typedef signed int s32_t;
  //typedef unsigned int u32_t;
  //typedef signed short s16_t;
  //typedef unsigned short u16_t;
  typedef signed char s8_t;
  typedef unsigned char u8_t;

  #define s32_t int  
  #define u32_t uint32_t
  #define s16_t int16_t
  #define u16_t uint16_t
and pushed the change to library.
 
Re: T4.1 SPIFFS

With 1.8.12 and 1.52 and the new SPIFFS lib, I decided to update my Ethernet lwip_tftpd_SPIFFS sketch. I got compile errors because of typedef conflict between lwip and spiffs for s32_t and u32_t. I solved it by hacking spiffs_config.h and using #define ... sigh :(

I created fnet_tftpd_SPIFFS a tftp server using SPIFFS on EFLASH with FNET and NativeEthernet libs
 
Has anyone from Europe already received the beta board (except the pre beta tester)? Mine has been in Belgium for a week now and is not moving anymore. I think I will order a Teensy 4.1 from sparkfun, with shipping by Fedex or UPS - no USPS this time.
 
Has anyone from Europe already received the beta board (except the pre beta tester)? Mine has been in Belgium for a week now and is not moving anymore. I think I will order a Teensy 4.1 from sparkfun, with shipping by Fedex or UPS - no USPS this time.

My beta board has yesterday reached Italy. still waiting.
Meanwhile, I ordered some T4.1 from Exp-Tech.de, arrived via USP in no time. (No custom issue within Europe)
 
Has anyone from Europe already received the beta board (except the pre beta tester)? Mine has been in Belgium for a week now and is not moving anymore. I think I will order a Teensy 4.1 from sparkfun, with shipping by Fedex or UPS - no USPS this time.

Mine was shipped by PJRC on April 28th. Turned around for several days in SF, then took a week to make it to LA where it was last scanned on May 17th. Thus, far from arriving here in France - deeply disappointed by USPS.
 
One month to italy, now at customs... the beta is to be written off.
Exp-tech is not an option. 17.85€ shipping. :mad: 10€ upcharge to the real price. WHAT?

Actually Teensy in Italy cost 1.5 times up to 2 times the original price.
I think it is time to establish a PJRC store in Europe to cut out these profit-makers. I'd be happy to do that work, just because.
 
Back
Top