teensy 3 MAC address

Status
Not open for further replies.
Using ubuntu 16.04, IDE 1.8.8/1.37 on T3.6@180mhz, works for me with Fast Faster or Fastest using Frank's example
Code:
#include <TeensyMAC.h>

void setup() {
  Serial.begin(9600);
}

void loop() {
  delay(500);
  Serial.printf("Serial: %u\n", teensySerial());
  Serial.printf("MAC: 0x%012llX\n", teensyMAC());
}


MAC: 0x04E9E5032337
Serial: 2056230
MAC: 0x04E9E5032337
Serial: 2056230
MAC: 0x04E9E5032337
Serial: 2056230
MAC: 0x04E9E5032337
Serial: 2056230
...
still works after unplugging/plugging USB cable.

Tested on 2 different T3.6


wow, this is super strange
so, the only thing I have different is some data saved in the eeprom
I will try to erase the entire eeprom and test again, but this is really funny...
 
perhaps you should post the sketch that is failing. And does the simple sketch above work for you ?
 
Yeah, verily. the following sketch on T3.6@180mhz exhibits the bad behavior you describe.
Code:
/*
  eeprom perf (cycle power to confirm)
*/
#include <TeensyMAC.h>
#include <EEPROM.h>


unsigned long t;
void setup()
{
  int i,val,errs=0;

  Serial.begin(9600); while(!Serial); delay(5000);
  Serial.print("EEPROM length: "); 
  Serial.println(EEPROM.length());
  Serial.println("initial read");
	for (i=0;i<100;i++) {
		val = EEPROM.read(i);
		if (val != i) {
			Serial.print(val);
			Serial.print(" should be ");
			Serial.println(i);
      errs++;
		}
	}
  Serial.print("read errs "); Serial.println(errs);
#if 0
	t=micros();
	for (i=0;i<100;i++) EEPROM.write(i, i);
	t=micros()-t;
	Serial.print("write "); Serial.println(t);
#endif
}

void loop()
{
	int i,val;
	t=micros();
	for (i=0;i<100;i++) val = EEPROM.read(i);
	t=micros()-t;
	Serial.print("100 reads (us) "); Serial.println(t);
 Serial.println(val);  // reference val
   Serial.printf("Serial: %u\n", teensySerial());
  Serial.printf("MAC: 0x%012llX\n", teensyMAC());
	delay(2000);
}

it runs correctly after compile/upload, but unplug/plug USB results in trailing 00's in MAC ?
(you need to run it once with EEPROM write block enabled #if 1 if you want to pass my EEPROM read check in loop())

I don't know why it fails with EEPROM :confused: (doesn't fail @120mhz)

Frank's system register 0x40041000 reads 0 after the unplug/plug, instead of having the stored value of the MAC ?
 
Last edited:
The sketch also works on my MAC running Mac Sierra Tried faster and Fastest with LTO at 180mhz. Also tried modifying and retrieved the serial number and MAC as first lines in code before Serial.begin()...

Is there anything else different about your hardware? Like are you powering from USB or is there external power turning it on and off?
 
so, the only thing I have different is some data saved in the eeprom

You could have save us quite a bit of time, and had an answer much sooner, if only you had posted the actual code you were really using!

This is why we have the "Forum Rule" about posting complete code. Please, follow this rule. It really is easy to post your *actual* code, and it really does make helping you much easier and faster.
 
You could have save us quite a bit of time, and had an answer much sooner, if only you had posted the actual code you were really using!

This is why we have the "Forum Rule" about posting complete code. Please, follow this rule. It really is easy to post your *actual* code, and it really does make helping you much easier and faster.

Sorry Paul, I didn't want to upset you. I always try to post the code, but this time the code is the same of Frank's library.

Code:
#include <TeensyMAC.h>

void setup() {
  Serial.begin(9600);
}

void loop() {
  delay(500);
  Serial.printf("Serial: %u\n", teensySerial());
  Serial.printf("MAC: 0x%012llX\n", teensyMAC());
}

on post #90 I said that both teensy have something stored in the eeprom, but it's not used in the current Sketch
I will try to wipe the eeprom and see if something changes

Update: tried to clear the EEPROM with eeprom_clear but still not behaving correctly using Frank's code.
Tested on Ubuntu with arduino 1.8.3 and teensyduino 1.37

@KurtE: for this test is just teensy 3.6 with nothing connected, powered (and serial) over usb
 
Last edited:
the sketch in post #103 exhibits the strange behavior ...

the smallest test case is to just add #include <EEPROM.h> to Frank's small sketch
 
Last edited:
well, upon further review, Frank's sketch
Code:
#include <TeensyMAC.h>

void setup() {
  Serial.begin(9600);
}

void loop() {
  delay(500);
  Serial.printf("Serial: %u\n", teensySerial());
  Serial.printf("MAC: 0x%012llX\n", teensyMAC());
}
on T3.6@180mhz works after compile/upload, but if you unplug/plug in USB power, then it reports 0 in lower bytes of MAC. (with no EEPROM refs). @120mhz MAC value is good across power cycles. ? this contradicts what i was getting in earlier posts??, using 1.8.3/1.37.

EDIT: from the K66 beta test thread, this function
Code:
void mactst() {
    uint64_t num64;
    uint32_t num;
    __disable_irq();
      FTFL_FSTAT = FTFL_FSTAT_RDCOLERR | FTFL_FSTAT_ACCERR | FTFL_FSTAT_FPVIOL;
    *(uint32_t *)&FTFL_FCCOB3 = 0x41070000;
    FTFL_FSTAT = FTFL_FSTAT_CCIF;
    while (!(FTFL_FSTAT & FTFL_FSTAT_CCIF)) ; // wait
    num64 = *(uint64_t *)&FTFL_FCCOB7;
    __enable_irq();
    num = num64;
    Serial.println(num,HEX);
    num = num64>>32;
    Serial.println(num,HEX);
}
properly prints the MAC address across power cycles @180mhz (though i actually had remembered that it did not work @180mhz)



EDIT: ARGH On another T3.6@180mhz, the simple sketch is working across power cycles ???? now i'm really confused.
? It will fail if EEPROM.h is present @180mhz, BUT after that, it fails across power cycles, even with EEPROM.h removed???
this is getting above my pay grade
 
Last edited:
@Manitou : How is the 'Power Cycle' done if not pulling USB? Perhaps a warm reset/restart?

Where does the TeensyMAC.h in use come from?

Before Paul did the edit for T_3.6's MAC under HSRUN I discovered the MAC could be read before HSRUN was enabled, once the MCU does that it is cached so a failure returns what was there on subsequent calls. That could explain it surviving until power loss, assuming re-programming is not HSRUN speed and leaves the value in the process - and that area isn't cleared.
 
@Manitou : How is the 'Power Cycle' done if not pulling USB? Perhaps a warm reset/restart?

Where does the TeensyMAC.h in use come from?

Before Paul did the edit for T_3.6's MAC under HSRUN I discovered the MAC could be read before HSRUN was enabled, once the MCU does that it is cached so a failure returns what was there on subsequent calls. That could explain it surviving until power loss, assuming re-programming is not HSRUN speed and leaves the value in the process - and that area isn't cleared.

yes, by power-cycling i meant, closing the monitor, pulling the USB cable, then plugging it back in, and enabling the monitor.

Frank's TeensyMAC https://github.com/FrankBoesing/TeensyMAC

EEPROM.h does an init() that messes with the FTFL stuff as i recall
 
EDIT: from the K66 beta test thread, this function
Code:
void mactst() {
    uint64_t num64;
    uint32_t num;
    __disable_irq();
      FTFL_FSTAT = FTFL_FSTAT_RDCOLERR | FTFL_FSTAT_ACCERR | FTFL_FSTAT_FPVIOL;
    *(uint32_t *)&FTFL_FCCOB3 = 0x41070000;
    FTFL_FSTAT = FTFL_FSTAT_CCIF;
    while (!(FTFL_FSTAT & FTFL_FSTAT_CCIF)) ; // wait
    num64 = *(uint64_t *)&FTFL_FCCOB7;
    __enable_irq();
    num = num64;
    Serial.println(num,HEX);
    num = num64>>32;
    Serial.println(num,HEX);
}
properly prints the MAC address across power cycles @180mhz (though i actually had remembered that it did not work @180mhz)

I will give it a try with my code and see
 
well, upon further review, Frank's sketch
Code:
#include <TeensyMAC.h>

void setup() {
  Serial.begin(9600);
}

void loop() {
  delay(500);
  Serial.printf("Serial: %u\n", teensySerial());
  Serial.printf("MAC: 0x%012llX\n", teensyMAC());
}
on T3.6@180mhz works after compile/upload, but if you unplug/plug in USB power, then it reports 0 in lower bytes of MAC. (with no EEPROM refs). @120mhz MAC value is good across power cycles. ? this contradicts what i was getting in earlier posts??, using 1.8.3/1.37.

EDIT: from the K66 beta test thread, this function
Code:
void mactst() {
    uint64_t num64;
    uint32_t num;
    __disable_irq();
      FTFL_FSTAT = FTFL_FSTAT_RDCOLERR | FTFL_FSTAT_ACCERR | FTFL_FSTAT_FPVIOL;
    *(uint32_t *)&FTFL_FCCOB3 = 0x41070000;
    FTFL_FSTAT = FTFL_FSTAT_CCIF;
    while (!(FTFL_FSTAT & FTFL_FSTAT_CCIF)) ; // wait
    num64 = *(uint64_t *)&FTFL_FCCOB7;
    __enable_irq();
    num = num64;
    Serial.println(num,HEX);
    num = num64>>32;
    Serial.println(num,HEX);
}
properly prints the MAC address across power cycles @180mhz (though i actually had remembered that it did not work @180mhz)



EDIT: ARGH On another T3.6@180mhz, the simple sketch is working across power cycles ???? now i'm really confused.
? It will fail if EEPROM.h is present @180mhz, BUT after that, it fails across power cycles, even with EEPROM.h removed???
this is getting above my pay grade



After a looong time I finally had time to test it, and the code posted here fixes the eeprom bug. thanks
 
Certain T_3.6 elements - EEPROM I recall - are inaccessible over 120 MHz when the CPU is overvolted for High Speed Run operation. There is a system call to drop speed& voltage - make the call - then return the voltage&speed:

Code:
kinetis_hsrun_disable();

// over 120 MHz restriced access 

kinetis_hsrun_enable();

This drops the voltage and the CPU to 120 MHz between those calls. Certain system clocks will be changed with this and some buses will not function properly if active resulting in missed data - Serial UART ports was one for instance.

If more info is needed Paul probably left more distinct notes in the forum try search for :: kinetis_hsrun_
 
With Teensy 3.6 at any CPU setting above 120 MHz, running this code (https://github.com/FrankBoesing/TeensyMAC/blob/master/examples/PrintInfo/PrintInfo.ino) and library (https://github.com/FrankBoesing/TeensyMAC) works fine if the code is uploaded via USB; however, on power cycles (i.e. unplugging and re-plugging the USB cable) results in 0 for the serial and an incorrect mac address. Arduino version 1.8.9 and Teensyduino 1.46 on Linux Debian 9.

here is the sketch I use https://github.com/manitou48/teensy3/blob/master/getmac.ino
 
Awesome, I can confirm that works. Thanks!

hmmm, i just ran it on T3.6 and it seems to repeat the first 3 bytes ... need to find my working copy

maybe this

Code:
void prmac() {
    uint64_t num64;
    uint32_t num;
    __disable_irq();
      FTFL_FSTAT = FTFL_FSTAT_RDCOLERR | FTFL_FSTAT_ACCERR | FTFL_FSTAT_FPVIOL;
    *(uint32_t *)&FTFL_FCCOB3 = 0x41070000;
    FTFL_FSTAT = FTFL_FSTAT_CCIF;
    while (!(FTFL_FSTAT & FTFL_FSTAT_CCIF)) ; // wait
    num64 = *(uint64_t *)&FTFL_FCCOB7;
    __enable_irq();
    num = num64;
    Serial.println(num,HEX);
    num = num64>>32;
    Serial.println(num,HEX);

}
 
hmmm, i just ran it on T3.6 and it seems to repeat the first 3 bytes ... need to find my working copy

maybe this

Code:
void prmac() {
    uint64_t num64;
    uint32_t num;
    __disable_irq();
      FTFL_FSTAT = FTFL_FSTAT_RDCOLERR | FTFL_FSTAT_ACCERR | FTFL_FSTAT_FPVIOL;
    *(uint32_t *)&FTFL_FCCOB3 = 0x41070000;
    FTFL_FSTAT = FTFL_FSTAT_CCIF;
    while (!(FTFL_FSTAT & FTFL_FSTAT_CCIF)) ; // wait
    num64 = *(uint64_t *)&FTFL_FCCOB7;
    __enable_irq();
    num = num64;
    Serial.println(num,HEX);
    num = num64>>32;
    Serial.println(num,HEX);

}

You're right, now that I take a closer look - the bytes are repeated.

The prmac function seems to work fine.
 
I just went back to this thread: https://forum.pjrc.com/threads/57595-Serial-amp-MAC-Address-Teensy-4-0 - helped get user to find T4 Serial# - but updated T4 code wasn't integrated back to TeensyID yet.

It links to this : https://github.com/sstaub/TeensyID - that should work for T3.x and T_LC

I haven't tested - assume it works. Not sure if it does anything differently.

As posted on that thread - I pulled the startup code PJRC uses to get the Serial# - that is in the T_3 cores too. Not sure if it does anything differently.
 
Hello,

Sorry for reviving old thread. I have working with Teensy MAC Address, and have no problem so far, that is till today. I found 2 strange Teensy 3.2, that always give strange MAC number. I use two libraries :

from sstaub (https://github.com/sstaub/TeensyID)
from FrankBoesing (https://github.com/FrankBoesing/TeensyMAC)

Both libraries gives a little different MAC number. Here is the result:

Code:
===============================
TEENSYMAC
===============================

Teensy1
Serial: 4294967295
MAC: 0x04E9FFFFFFFF
MAC as array: 04:E9:[COLOR="#FF0000"]FF[/COLOR]:FF:FF:FF

Teensy2
Serial: 4294967295
MAC: 0x04E9FFFFFFFF
MAC as array: 04:E9:[COLOR="#FF0000"]FF[/COLOR]:FF:FF:FF

Code:
===============================
TEENSYID
===============================

Teensy1
USB Serialnumber: 4294967295 
Array Serialnumber: FF-FF-FF-FF 
String Serialnumber: ff-ff-ff-ff
Array MAC Address: 04:E9:[COLOR="#FF0000"]E5[/COLOR]:FF:FF:FF 
String MAC Address: 04:e9:e5:ff:ff:ff
Array 128-bit UniqueID from chip: 26210000-D9A40014-00422007-48284E45
String 128-bit UniqueID from chip: 26210000-d9a40014-00422007-48284e45
Array 128-bit UUID RFC4122: 00422007-4828-404E-8045-04E9E5FFFFFF
String 128-bit UUID RFC4122: 00422007-4828-404e-8045-04e9e5ffffff

Teensy2
USB Serialnumber: 4294967295 
Array Serialnumber: FF-FF-FF-FF 
String Serialnumber: ff-ff-ff-ff
Array MAC Address: 04:E9:[COLOR="#FF0000"]E5[/COLOR]:FF:FF:FF 
String MAC Address: 04:e9:e5:ff:ff:ff
Array 128-bit UniqueID from chip: 26210000-D9A4000A-0013200C-48284E45
String 128-bit UniqueID from chip: 26210000-d9a4000a-0013200c-48284e45
Array 128-bit UUID RFC4122: 0013200C-4828-404E-8045-04E9E5FFFFFF
String 128-bit UUID RFC4122: 0013200c-4828-404e-8045-04e9e5ffffff

As you can see, the third MAC number is different, but still FF FF FF for the rest of MAC number. And why both have the same USB Serial Number?

Here is the results when using "normal" Teensy 3.2:

Code:
===============================
TEENSYMAC
===============================

Serial: 6560050
MAC: 0x04E9E50A0285
MAC as array: 04:E9:E5:0A:02:85

===============================
TEENSYID
===============================

USB Serialnumber: 6560050 
Array Serialnumber: 00-0A-02-85 
String Serialnumber: 00-0a-02-85
Array MAC Address: 04:E9:E5:0A:02:85 
String MAC Address: 04:e9:e5:0a:02:85
Array 128-bit UniqueID from chip: 48610000-D7430015-00290014-47844E45
String 128-bit UniqueID from chip: 48610000-d7430015-00290014-47844e45
Array 128-bit UUID RFC4122: 00290014-4784-404E-8045-04E9E50A0285
String 128-bit UUID RFC4122: 00290014-4784-404e-8045-04e9e50a0285

Did I just received counterfeit Teensy 3.2? Or there`s something I should do to rectify the problem? Sorry for my bad english, thank you for your reply.
 
That seems like a @Paul question. If they are PJRC devices they somehow didn't get a serial number burned in a blank flash - that is all F's for both of them. More likely they are counterfeit.

When first unpacked did they have a standard blink? Did they come with a standard Teensy product card?

Can you post decent photos - do they compare with photos on the CARD or PJRC.COM website as shown for T_3.2?
 
Status
Not open for further replies.
Back
Top