Teensy 4.1 Beta Test

[MichaelMeissner]

Looks like fun output of the different pin information...

Using a volt meter, none of the pins for the two memory solder pads match any of the 3 SPI buses (except for ground and 3.3v obviously). But except for the CS pad (1st pad where the dot is), the other 7 pads are connected to each other between the two pads. Using your table, the internal pins are EMC_25 to EMC_29 for the common SPI pins, and EMC_24 and EMC_22 for the two CS pins.

The i.MX1062 does support 4 SPI buses, so it looks like the 2 memory pads use that 4th SPI bus. Thus we have SPI and SPI1 for normal SPI accesses, SPI2 for the micro-SD card reader, and SPI3 for the memory chips.

[Ward]

So I'm starting work on the Ethernet interface now. In the past (for FlexIO and clock tree generation), my approach has been to start with known working code in MCUXpresso and then move that over to Arduino-land. For the clock configuration in particular, this has saved me considerable time since NXP's tool has a convenient graphical manager that generates pretty straightforward configuration code. The biggest challenge I see is that imxrt.h uses a different structure for register access than the Freescale SDK, so there will probably be a lot of head-scratching and binge drinking there.

That said, I'm open to suggestions for alternate approaches. How have others beaten the various peripherals of this part into submission? Do you give up on the Arduino environment entirely and do everything in Eclipse? Honestly that's an environment I'm far more comfortable with given my day job (STM32 in Eclipse with OWD/Segger). Any other advice? Thanks!

[Ward]

Also, before I totally reinvent the wheel, are there any existing functions/macros for things like setting the pin mux or pin configuration registers? What would be the most recent low-level library with good examples of canonical approaches to hardware manipulation?

[manitou]

I have run the NXP SDK examples for ethernet on the 1062 eval board. Take a look at https://github.com/PaulStoffregen/teensy41_ethernet
there are some "raw" ethernet examples (arduino) sketches that enable clocks and configure pins and ethernet ring buffers for the Teensy 4.1. On top of that we have implented lwIP examples using polling and callbacks that do UDP/TCP client/server things. The README has some performance comparisons

[blackketter]

I can't seem to find a reference for the circuit needed for the ethernet port. Is it as simple as wiring a RJ-45 with integrated magnetics and maybe a current limiting resistor for the LED?

[Ward]

@manitou Thanks for that! Well heck, looks like everything's done then. Is there anything useful I can add at this point or should I move on to something else? Maybe work on getting the existing Arduino Ethernet library integrated with the T4.1 hardware, or is the plan to just move to lwip for everything in the future? Thanks.

[manitou]

I can't seem to find a reference for the circuit needed for the ethernet port. Is it as simple as wiring a RJ-45 with integrated magnetics and maybe a current limiting resistor for the LED?

paul provided a limited number of RJ45's with magnetics and 6-pin ribbon cable for the pre-beta testing. I assume at some point he will provide schematics and BOM for the RJ45 connection.

For the USB host connection, the PJRC USB host cable will work (same as with T3.6)

[manitou]

@manitou Thanks for that! Well heck, looks like everything's done then. Is there anything useful I can add at this point or should I move on to something else? Maybe work on getting the existing Arduino Ethernet library integrated with the T4.1 hardware, or is the plan to just move to lwip for everything in the future? Thanks.

Paul's hope has always been (since T3.6 beta testing) wanting to provide an arduino-like library for the T3.6/T4.1 native ethernet. If you can do that, you will receive great adulation. Implementing a TCP/IP suite with timers, interrupts, and memory management is no small task and makes one appreciate off-loading all of that to a co-processor (e.g. Wiznet SPI ethernet). Here are some notes from the "private" thread used during pre-beta T4.1 testing

-----------
Ethernet and lwip testing and performance

I'll summarize my lwIP testing as I add to this sticky post

The beta teensy4.1 came with an RJ45 jack/PCB kit with 6 pin ribbon cable. The cable is attached to the 6 pins on the T4.1 as shown here

Initial testing was done in February 2020 with Arduino 1.8.11 and TD 1.51-beta1

---

low-level Ethernet tests:
Paul provided a low-level sketch to configure the T41 ethernet interface. The interface is configured with 12 RX and 10 TX ring descriptors using 512-byte packet buffers. The sketch provides ARP reply and ICMP echo (ping) reply using a fixed IP and MAC address. The sketch listens in promiscuous mode (ENET_RCR_PROM) and prints incoming packets (broadcasts and multicasts). ICMP ping round-trip times were 396 us, slowed somewhat by the packet printing.

PLL6 = 80202001 (should be 80202001)
GPR1 = 80020018
RCSR:0061, LEDCR:0480, PHYCR 8000
RCSR:00A1, LEDCR:0280, PHYCR 8000
enetbufferdesc_t size = 32
rx_ring size = 384
MIBC=40000000
ECR=F0000000
ECR=F0000112
MDIO PHY ID2 (LAN8720A is 0007, DP83825I is 2000): 2000
MDIO PHY ID3 (LAN8720A is C0F?, DP83825I is A140): A140
BMCR: 3100
BMSR: 786D

I extended Paul's sketch, adding hand-crafted UDP packets to create etherraw.ino based on 2016 K66 beta ethernet testing. I disabled promiscuous mode and increased packet buffers to 1536 bytes and updated to use single ISR to count packets. The 1062 has an option to coalesce packet interrupts, but I'm still using legacy mode.

• ARP request(broadcast), reply, respond OK, (192.168.1.17) at 04:e9:e5:00:00:01. request/response time 93 us. could build ARP table
• ICMP/ping reply OK. ping RTT time from linux host: 120 us (print's disabled in sketch)
• UDP receive test: linux box sends 20 1000-byte UDP packets as fast at it can. T41 receives all in 1660 us (bout 96 mbs), receiver clock is started when first packet arrives.
• UDP blast : T41 sends 20 1000-byte packets (with sequence numbers) to UDP sink program on linux, linux measured 96 mbs.
• UDP echo reply, RTT for 8-byte pkt with simple T41 sendto/recvfrom echo'd back from linux: 93 us, with T41 echoing, 98 us.
• UDP NTP query using sendto/recvfrom, RTT 182 us
• modified output() to keep trying til ring output buffer is available
• To simulate TCP performance, a UDP transmit function was configured like TCP (MSS=1460, max window 2*MSS) and uses a "slow start" of a full window of data, sending 1460-byte packets. The window size and RTT latency will determine TCP bulk transfer rates. With a simple linux UDP "ack" program (no delayed ACK), our T41 TCP-like transfer rate was 70 million bits/second (mbs) on the home wired-Ethernet. Increasing the window to 4*MSS increased the throughput to 95 mbs. Since the T41 hardware checksums are flakey (?maybe), we are calculating IP header checksum in software, and using 0 for UDP checksum.
  
  We include a micros() timestamp in each packet to measure RTT.
  RTT stats: 100 pkts min 330 max 463 avrg 335 (microseconds)
  The RTT jitter is caused by other traffic (broadcasts) on the home net, or the linux host having something better to do.

T41 ethernet registers:

PLL6 = 80202001 (should be 80202001)
GPR1 = 80020018
RCSR:0061, LEDCR:0480, PHYCR 8000
RCSR:00A1, LEDCR:0280, PHYCR 0000
enetbufferdesc_t size = 32
rx_ring size = 384
MIBC=40000000
ECR=F0000000
ECR=F0000112
MDIO PHY ID2 (LAN8720A is 0007, DP83825I is 2000): 2000
MDIO PHY ID3 (LAN8720A is C0F?, DP83825I is A140): A140
BMCR: 3100
BMSR: 786D
ENET_PALR 0x4e9e500
ENET_PAUR 0x18808
ENET_EIR 0x0
ENET_EIMR 0xa000000
ENET_ECR 0xf0000112
ENET_MSCR 0x12
ENET_MRBR 0x600
ENET_RCR 0x45f25104
ENET_TCR 0x104
ENET_TACC 0x1
ENET_RACC 0x80
ENET_MMFR 0x6004786d

---

lwIP tests: (v2.0.2, no RTOS NO_SYS=1)

I ported lwIP (v2.0.2) from 2016 T3.5/T3.6 beta ethernet testing. I updated the low-level interface to support the T41 ethernet and configured 5 Tx and 5 Rx ring descriptors with 1536-byte packet buffers. lwIP uses polling and callbacks (no RTOS) and provides ARP, IP, ICMP, UDP, TCP, DHCP, DNS, and multicast. There are numerous tuning and configuration options (lwipopts.h). Hardware checksums appear to be working with lwIP.

I developed test sketches for NTP, DNS, multicast, web server, web client, httpd with SD or SdFat-beta lib, tfttp server (SD, SdFat-beta, or SPIFFS), ftpd (get/put) with SD lib, and TCP/UDP client/server benchmarking. TCP performance improves from 59 mbs to 81 mbs by increasing TCP window to 4*MSS in lwipopts.h. Some of the benchmark results are reported in the table below (column T41e is the Teensy 4.1 ethernet).

                         Ethernet performance
                   T41e   1062SDK  T41fnet T41QNE  T41USBe  T35e  T4+W5500    1170     info
TCP xmit (mbs)       73        87     92      86      78     59         9       84
TCP recv (mbs)       93        71     78      78      30     81        11       91

UDP xmit (mbs)       97        97     97      89      95     85        11       98  blast 20 1000-byte pkts
UDP xmit (pps)   149476    137453 152052  152146   32331  66534     21514   149146  blast 1000 8-byte pkts
UDP recv (mbs)       91        95     96      94      40     67         9       99  no-loss recv of 20 1000-byte pkts
UDP RTT (us)         94       104    104     162    1651    183       150      250  RTT latency of 8-byte pkts

ping RTT (us)       120       108    103     162    2000    127        82      315

ePower (ma)          59       100     59      59     174    100       132           ethernet module current
 
  tests on 100mbs full-duplex Ether with linux box on switch
  T41fnet and T41USBe  FNET TCP/IP native (arduino wrapper) and USB host, no threads
  T41 QNEthernet, arduino API wrapper for lwIP   12/22/21
  W5500 SPI @37.5MHz, 2KB buffers
  1170 lwIP 100T SDK -O3 @996MHz  9/15/21

The memory usage for a sketch is 66 KB flash and 148 KB RAM. RAM usage includes 15 KB of Ethernet ring DMA buffers. Teensy also copies flash into RAM for faster execution. Packet buffers are allocated/freed from the heap (malloc()).

Below is power consumption of T4.1 with Ethernet. After powering up, the sketch delays a few seconds before transmitting TCP packets for about 8 seconds. Power stays high, even after the transfer is complete. A temperature probe on the PHY chip measures 40℃ .

Turn off power to PHY with

mdio_write(0,0,0); // auto negotiate off
mdio_write(0,0,0x0800); // power down

builtin microSD and native ether performance

  microSD read times (seconds)  (4.2MB file, 2KB reads)
      T4 SD lib  T3.5 SdFatv1  T4.1 SdFatv2  T4.1 SPIFFS EFLASH
tftp    4.76        2.2          2.2 s         2.3 s
http    3.6         0.9          0.9
ftp     2.8         0.6  
read()  2.76        0.26         0.19 s        0.2 s

lwIP TODO:

• upgrade to latest lwIP
• lwIP tuning options: memory/pbuf's, LITE options, memcpy
• IP frag is enabled, but not tested
• lwip_servers (httpd, ftpd, tftpd) with SdFat fails to build (worked on T3.5 SdFatv1) ? needs T4/VFS support
• DEBUG and stats_display() want to use printf
• integrate yield() with ethernet polling
• coalesce interrupts and use DMA, cache management (NXP SDK fsl_enet.c)
• mbed uses zero-copy (need to reclaim TX buffers), DMA?
• integrate multicast CRC/hash into lwIP API
• bettter integrate lwIP into IDE
• develop Ethernet/TCP/IP stack? lwIP variations? FNET? Paul would like to have the shield API be a drop-in replacement for existing Arduino Ethernet interface (maybe based on STM32duino lwIP or UIPEthernet?). Done? see T4.1 FNET and Arduino API wrapper 2020

lwIP updates:
6/23/20 D Drown refactors lwIP include files so no modifications to boards.txt is required to build lwIP sketches with the IDE. Lib now supports 1588 time stamps. Paul's repository updated from https://github.com/ddrown/teensy41_ethernet. Also see NTP server with GPS PPS and 1588.

8/30/21 QNEthernet, shawn's lwIP-based Ethernet lib https://forum.pjrc.com/threads/68066...for-Teensy-4-1 platformio

---

FNET and NativeEthernet tests: May, 2020

An Arduino-like API has been provided by @vjmuzik atop of FNET TCP/IP. The API includes the Arduino TCP/IP examples. I have tested ARP, ICMP, DHCP, DNS, multicast, and various TCP/UDP client/servers. The memory usage for a sketch is 88 KB flash and 118 KB RAM. RAM usage includes 6 KB of Ethernet ring DMA buffers, and Teensy copies flash into RAM. Packet buffers are allocated/freed from the heap (malloc()). Performance results are presented in the table above (T41fnet column). Increasing FNET_SOCKET_DEFAULT_SIZE from 2048 to 4*1460 in NativeEthernet.h improved T4.1 TCP recv from 60.5 mbs to 78.4 mbs and TCP xmit from 45.2 mbs to 92 mbs! Edit: there are now function calls to set buffer sizes.

fnet_perf.ino and tftp servers fnet_tftpd (with SD lib) or fnet_tftpd_SPIFFS
See discussions on NativeEthernet thread

---

References:

• Teensy 4.1
• DP83825I PHY data sheet and RJ45 PCB kit
• lwIP info and API
• my lwIP repository lib and test sketches
• T3.5/3.6 beta ethernet tests 2016
• NXP 1062 SDK lwIP TCP/UDP tests 2018
• USB ethernet tests (2019) and FNET TCP/IP stack
• T4.1 FNET and Arduino API wrapper 2020
• STM32duino lwIP API arduino-like
• other TCP/IP stacks: ENC28J60: UIPEthernet (Arduino-like), primitive ethercard (poll/callback), xxxajk SLIP IP stack
• earlier WIZnet ethernet tests (2012...) with Arduino ethernet lib
• network power consumption plots

[blackketter]

paul provided a limited number of RJ45's with magnetics and 6-pin ribbon cable for the pre-beta testing. I assume at some point he will provide schematics and BOM for the RJ45 connection.

Ah, ok. Can anybody with one confirm that it's just wires and connectors?

[Ward]

Can confirm. No ballast resistor needed for the LED. There are pads for tying the Ethernet connector shield (and by extension the wire side of the magnetics) to ground, as well as the circuit side center taps of the magnetics. I populated those with 0.1uF 100V caps, 1kV would be better for the wire side, but I didn't have one in my pocket. Honestly, if you're handy with a soldering iron, a magjack and some twisted pair (or better, twist up some wirewrap wire) is all you'd need.

@manitou, I've got blinkenlights and see ARP traffic, so we'll call that a win. Thanks again!

[defragster]

Ah, ok. Can anybody with one confirm that it's just wires and connectors?

The unit I got from PJRC was a ribbon cable to a digikey MagJack ( back in stock soon ) on a PCB - the PCB has 4 components. At a glance it looks to be one resistor and three caps.

[Ward]

Okay, I take back the "1kV" comment. Looking at the datasheet in the link defragster posted, there's a 2kV 1000pF cap in the package already.

[sstaub]

A short advice for an Ethernet library as a starting point. There is a lwip based lib for STM32duino here https://github.com/stm32duino/STM32Ethernet
The API follows the Ethernet lib of Arduino, maybe that helps.

[mjs513]

The unit I got from PJRC was a ribbon cable to a digikey MagJack ( back in stock soon ) on a PCB - the PCB has 4 components. At a glance it looks to be one resistor and three caps.

Think this might be the same: https://www.sparkfun.com/products/13021 or this https://www.kr4.us/SparkFun-RJ45-MagJack-Breakout.html. Not sure, what do you all think.

[manitou]

A short advice for an Ethernet library as a starting point. There is a lwip based lib for STM32duino here https://github.com/stm32duino/STM32Ethernet
The API follows the Ethernet lib of Arduino, maybe that helps.

This API looks promising. i've added it to the list of candidates at the end of post #108. The API uses a 1 ms timer to check for packets and network events.

[defragster]

PJRC unit had the 4 component parts added? Maybe not needed just overkill on Paul's part? Or maybe he knows something about working with the 'TINY' ethernet chip he could squeeze on the T_4.1 PCB?

Those don't show any resistor or caps in place in the images I can see. Also PJRC part had a similar 2x3 pin connector for the cable as he made it up that - given the ribbon bale with female ends pushed right on - the SFun item had a row of some pins that may not map 1::1 - maybe that is what the onboard parts did?

[Ward]

No, there were no SMT components populated...I added them. It's good practice to terminate the center tap on both sides of the Ethernet magnetics. The line side is typically shunted to ground through a 50- or 75-ohm resistor and a high-voltage cap. The device side is typically shunted to ground through only a cap. On this part, the line-side 75 ohm load resistors and cap are inside the jack. The breakout board I was sent had four enormous sets of pads, probably for 0805 components. Two were in parallel from the line side center tap to ground, and two were in parallel from the device side center tap to ground. I stuffed each pair with a single 0.1uF 100V 0603 (physically biggest I had) capacitor. Everything seems to be working fine. If you're designing your own magjack breakout, I'd recommend adding some ESD diodes as well, which are cheap insurance. I've seen Wiznet chips die without external overvoltage protection, TI is probably more robust.

[vjmuzik]

Once I get my hands on a T_41 I’ll be working on getting FNETs native support for the 1062 processor working, so it should handle setting up all the necessary registers and timers by itself. Since I’ve already gone through a lot of FNET when I was getting the USB Ethernet working I already roughly know what needs to be done to get it working. As it stands I could have Paul’s low level sketch interfaced with my port fairly quickly since I designed it to be easily interfaced with, but I believe the native support will be more stable in the long run so I would like for that to work.

[defragster]

Once I get my hands on a T_41 I’ll be working on getting FNETs native support for the 1062 processor working, so it should handle setting up all the necessary registers and timers by itself. Since I’ve already gone through a lot of FNET when I was getting the USB Ethernet working I already roughly know what needs to be done to get it working. As it stands I could have Paul’s low level sketch interfaced with my port fairly quickly since I designed it to be easily interfaced with, but I believe the native support will be more stable in the long run so I would like for that to work.

Cool, did you request a unit with your name on the post 1 list?

[vjmuzik]

Cool, did you request a unit with your name on the post 1 list?

I did, just a little later than everyone else.

[LuisHS]

Hi.
Will this new version allow uploading signed/encrypted images of the user firmware?

[defragster]

Hi.
Will this new version allow uploading signed/encrypted images of the user firmware?

Not seen any signs of that as a WIP at this point.

No. Teensy 4.0 is not using the encryption features.

We may at some point in the future (not likely until at least 2021) support encrypted firmware. But that is no simple matter. These powerful features come with many dangers if used improperly, including lots of ways to permanently brick your Teensy. When (if) we do support encryption, it very likely will be a different board and the changes will (probably) not be possible as a software update to existing boards.

All of the design that has gone into Teensy 4.0's bootloader and uploading process has revolved around making Teensy safe for experimentation and preventing boards from becoming bricked.

[KurtE]

Wondering about best way to gain access to the bottom pins, when not used with external memory.

As I posted with a few XLS outputs, these two memory chips map out to 7 additional IO pins, where 6 of these signals are common on both chip pads:

												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				MOSI2			P	54		(pin 1)	49	P			SCK2				1:13		4.27	EMC_27
									3.3V					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				MOSI2			P	54			49	P			SCK2				1:13		4.27	EMC_27
									3.3V				(pin 1)	48	P		RX8							4.24	EMC_24

Or from the other tab:

48	EMC_24	4:24	Serial8(5) RX 		FLEXSPI2_A_SS0_B	PWM1_B0						
49	EMC_27	4:27	Serial8(5) RTS		FLEXSPI2_A_DATA01, SPI2(1) SCK  	PWM1_A2				1:13		
50	EMC_28	4:28	Serial8(5) CTS		FLEXSPI2_A_DATA02, SPI2(1) MOSI	PWM1_B2				1:14		
51	EMC_22	4:22		Wire1(3) SCL	FLEXSPI2_A_SS1_B	PWM3_B3, QT2_3						
52	EMC_26	4:26	Serial1(6) RX 		FLEXSPI2_A_DATA00	PWM1_B1				1:12		
53	EMC_25	4:25	Serial1(6) TX 		FLEXSPI2_A_SCLK	PWM1_A1						
54	EMC_29	4:29	Serial1(6) RTS		FLEXSPI2_A_DATA03, SPI2(1) MISO	PWM3_A0				1:15

I can see a few different ways to get some/all of them:
a) Pogo pins - Sort of a pain especially with the .127...
b) Wondering about SMT connector. Maybe something like: https://www.digikey.com/product-deta...4-1-ND/2209146 ?
c) Quick and dirty castellated smt. Not sure if I do one to put the new pins in line so could maybe plug into breadboard. Or just two rows just behind SDCard slot... May try to layout one or the other.

But now back to playing

[KurtE]

Will this new version allow uploading signed/encrypted images of the user firmware?

I suspect the T4.1 functionality for this will be identical to T4's, as they use same processor and think same loader chip. Although maybe some slight changes to the firmware?

[AlanK]

a) Pogo pins - Sort of a pain especially with the .127...

Hi,
I haven't seen them, but I presume that, because of the duplication, most of the pogo pins could be 0.254 apart. Only two would have to go to pads that are adjacent. I don't know how long the pads are - if those for either chip are as generous as the ones on the audio board, then the two going to adjacent pads could be 0.254 spaced at an angle to the pads. Would that be possible?