Does the PHY chip on the T4.1 have a unique MAC address?

paulfer

Member
Maybe Shawn can help me?

I want to use a unique ID on the Teensy. Does the PHY chip on the T4.1 have a unique MAC address?

I see one can get the MAC as follows:

Code:
uint8_t mac[6];
  Ethernet.macAddress(mac);  // This is informative; it retrieves, not sets
  printf("MAC = %02x:%02x:%02x:%02x:%02x:%02x\r\n",
         mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);

Failing that, I can make a UID from the UNix time. But I am just curious.

Regards.
 
Every Teensy 4.1 comes with a unique mac address. It's stored in the non-volatile fuse memory of the IMXRT1062 processor, not the PHY chip. The mac address is written into fuse memory by PJRC during product testing. The upper 24 bits are an OUI assigned by IEEE to PJRC.

Likewise, if you build a DIY circuit board using the T4 bootloader chip, it comes with a unique mac access (same OUI assigned by IEEE to PJRC) which the bootloader chip writes into the fuse memory on first use.

The mac address is Teensy-specific. If you were to just buy a IMXRT1062 chip from NXP, those fuses come as all zeros in a brand new chip as delivered by NXP.
 
Every Teensy 4.1 comes with a unique mac address. It's stored in the non-volatile fuse memory of the IMXRT1062 processor, not the PHY chip. The mac address is written into fuse memory by PJRC during product testing. The upper 24 bits are an OUI assigned by IEEE to PJRC.

Likewise, if you build a DIY circuit board using the T4 bootloader chip, it comes with a unique mac access (same OUI assigned by IEEE to PJRC) which the bootloader chip writes into the fuse memory on first use.

The mac address is Teensy-specific. If you were to just buy a IMXRT1062 chip from NXP, those fuses come as all zeros in a brand new chip as delivered by NXP.
Thanks Paul. And am I correct in assuming the code I posted in the original post above will retrieve that MAC? (using the QNEthernet.h)
 
Every Teensy 4.1 comes with a unique mac address. It's stored in the non-volatile fuse memory of the IMXRT1062 processor, not the PHY chip. The mac address is written into fuse memory by PJRC during product testing. The upper 24 bits are an OUI assigned by IEEE to PJRC.
Is this also true for T4.1s that do not have the Ethernet PHY chip? It would make sense to set it even if there is no PHY, in case the user added their own PHY chip after purchase.
 
Yes, expected by design noted in post #2.
That's good. I have several T4.1s without PHYs. I plan to use the low bits of the MAC address as a unique identifier for USB Test and Measurement class devices. Does the T4.0 also get a MAC address? It doesn't seem to have the ability to connect a standard PHY.
 
I've tested the T4.0 and can't find a valid MAC address.
Just stole this code {and added printf()'s} from QNEthernet and T_4.0 returns a MAC just fine:
Code:
uint8_t gmac[24];
void enet_get_mac(uint8_t *mac) {
  if (mac == NULL) {
    return;
  }

  uint32_t m1 = HW_OCOTP_MAC1;
  uint32_t m2 = HW_OCOTP_MAC0;
  mac[0] = m1 >> 8;
  mac[1] = m1 >> 0;
  mac[2] = m2 >> 24;
  mac[3] = m2 >> 16;
  mac[4] = m2 >> 8;
  mac[5] = m2 >> 0;

  Serial.printf("HW_OCOTP_MAC1 = %08X   HW_OCOTP_MAC0 = %08X   \n", m1, m2 );
  for ( int ii = 0; ii <= 5; ii++ ) {
    Serial.printf("\tMAC %d = %02X   \n", ii, mac[ii] );
  }
}
Calling enet_get_mac( gmac ); on T_4.1 shows:
Code:
HW_OCOTP_MAC1 = 000004E9   HW_OCOTP_MAC0 = E50BEE85  
    MAC 0 = 04  
    MAC 1 = E9  
    MAC 2 = E5  
    MAC 3 = 0B  
    MAC 4 = EE  
    MAC 5 = 85
And on a T_4.0:
Code:
HW_OCOTP_MAC1 = 000004E9   HW_OCOTP_MAC0 = E5109B62  
    MAC 0 = 04  
    MAC 1 = E9  
    MAC 2 = E5  
    MAC 3 = 10  
    MAC 4 = 9B  
    MAC 5 = 62
 
Last edited:
Strange, if you use this code on a T4.0 you get all 00s

Code:
#include <QNEthernet.h>
using namespace qindesign::network;

uint8_t mac[6];

void setup() {
  // put your setup code here, to run once:
  delay(1000);

  Ethernet.macAddress(mac);  // This is informative; it retrieves, not sets
  printf("MAC = %02x:%02x:%02x:%02x:%02x:%02x\r\n",
         mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);
}

void loop() {
  // put your main code here, to run repeatedly:

}
 
Every Teensy 4.0 also gets a unique mac address, same as with Teensy 4.1.

Teensy 4.0 does not have the pins available to connect a PHY chip.

I don't know whether QNEthernet supports Teensy 4.0 at all. From these messages, sure looks like it only supports Teensy 4.1. Reading the fuse registers directly should always work on either board.
 
Strange, if you this code on a T4.0 you get all 00s
I went into the source files and found that enet_get_mac() [ in ...\GitHub\QNEthernet\src\lwip_t41.c] and put in a sketch with edits for Print's and results are as shown.

Based on Paul's CrossPost #13 - there may be an #ifdef type exclusion for T_4.0 returning the MAC when no direct hardware support. But the code p#11 will work to get the PJRC supplied MAC value on a T_4.0.
 
It is useful to know the T4.0 also have a MAC address.

I have a T4.0 ethernet project which needs a MAC address. I was going to use an external I2C MAC address chip. Now I know I don't need this anymore.

The project is Single Pair Ethernet in which the T4.0 is communicated over SPI to the MAC/PHY chip.
 
Every Teensy 4.0 also gets a unique mac address, same as with Teensy 4.1.

Teensy 4.0 does not have the pins available to connect a PHY chip.

I don't know whether QNEthernet supports Teensy 4.0 at all. From these messages, sure looks like it only supports Teensy 4.1. Reading the fuse registers directly should always work on either board.

The QNEthernet library should support Teensy 4.0 just fine, including accessing the MAC address. I tested this. If it doesn’t, that’s a bug. I’ll explore more later today.
 
Last edited:
It is useful to know the T4.0 also have a MAC address.

I have a T4.0 ethernet project which needs a MAC address. I was going to use an external I2C MAC address chip. Now I know I don't need this anymore.

The project is Single Pair Ethernet in which the T4.0 is communicated over SPI to the MAC/PHY chip.

Note that the QNEthernet library supports a W5500 driver for the Teensy 4.0. It’s possible for other drivers to be written too.
 
Strange, if you use this code on a T4.0 you get all 00s

...code...

This needs a Serial.begin(115200); before it can print to the console.

The QNEthernet library should support Teensy 4.0 just fine, including accessing the MAC address. I tested this. If it doesn’t, that’s a bug. I’ll explore more later today.

Fixed. I just pushed the latest to GitHub.
 
Fixed. I just pushed the latest to GitHub.

Just to clarify this fix: it’s only for the “unsupported” driver with no connectivity because other drivers are supposed to get the MAC address. The reason it wasn’t getting the MAC address for a Teensy 4.0 was because the “unsupported” driver does basically nothing. If the W5500 driver was used instead (see qnethernet_opts.h or project build options), the Teensy 4.0 build would have gotten the address correctly.

By default, all platforms including the Teensy 4.0 are assigned this “unsupported” driver because there’s no native Ethernet support.
 
Back
Top