Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 5 FirstFirst 1 2 3 4 5 LastLast
Results 51 to 75 of 114

Thread: teensy 3 MAC address

  1. #51
    Senior Member Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    4,241
    Hm, ok, does this work with disabled usb and/or lower fcpu or teensy 3.2?

  2. #52
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,986
    The change I did was to add a call to the code that reads in the serial number, if it finds that it is going to go into HSRUN mode. I also added code into that call that made it only do stuff once. So in all other cases the current code path to call the function is still done.

  3. #53
    Senior Member defragster's Avatar
    Join Date
    Feb 2015
    Posts
    4,808
    Quote Originally Posted by KurtE View Post
    The change I did was to add a call to the code that reads in the serial number, if it finds that it is going to go into HSRUN mode. I also added code into that call that made it only do stuff once. So in all other cases the current code path to call the function is still done.
    For affected MCU's (K66 only? Unless K64 has similar issue if it OC's over 120 MHz with similar limitation?) I envisioned this as something done on 'boot' before HSRUN is active so a static copy (like you suggest 'only once') was always present? In any case with a uniform TEENSY_Ser#() the same code could be used on boot with USB, or by any 'user'.

    Wondering if PJRC planning mini_beta of K64 units? Since I have K66 & Ethernet Beta boards I opted for T_3.6 SIX pack , so I won't have any K64's until they go retail.

    I was AWOL 3 weeks - now back home and should be online in coming days, once I unpack.

    With a uniform function() to Drop/Restore HSRUN - the end user could do this and also batch EEPROM I/O so such things can be usable. It would compromise clock specific items during that time - but better than losing functionality, or having end user hacks. With 'plenty' of RAM - some/all of the EEPROM could be cached for R/W access and quickly sync'd with :: eeprom_read_block() and eeprom_write_block() [ or _dword() ?]

  4. #54
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,986
    Quote Originally Posted by defragster View Post
    For affected MCU's (K66 only? Unless K64 has similar issue if it OC's over 120 MHz with similar limitation?) I envisioned this as something done on 'boot' before HSRUN is active so a static copy (like you suggest 'only once') was always present? In any case with a uniform TEENSY_Ser#() the same code could be used on boot with USB, or by any 'user'.

    Wondering if PJRC planning mini_beta of K64 units? Since I have K66 & Ethernet Beta boards I opted for T_3.6 SIX pack , so I won't have any K64's until they go retail.

    I was AWOL 3 weeks - now back home and should be online in coming days, once I unpack.

    With a uniform function() to Drop/Restore HSRUN - the end user could do this and also batch EEPROM I/O so such things can be usable. It would compromise clock specific items during that time - but better than losing functionality, or having end user hacks. With 'plenty' of RAM - some/all of the EEPROM could be cached for R/W access and quickly sync'd with :: eeprom_read_block() and eeprom_write_block() [ or _dword() ?]
    Welcome back,

    I think you are right that maybe there should be some caching scheme for EEPROM. In my case often I only read from the EEPROM at startup. Maybe things like Servo offsets and the like. I may then have a special mode I go into that allows me to update these settings, but again this is in an isolated portion of the code.

    I have not heard anything either about T3.5 beta, but thought these might be interesting as a drop in upgrade, that still gives me 5v tolerance. Obviously one issue will be the size of the board not fitting where the T3.2 would fit. Will talk more about this on another thread. So I ordered the 2+2 Kickstarter.

  5. #55
    Senior Member MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,441
    Quote Originally Posted by KurtE View Post
    I have not heard anything either about T3.5 beta, but thought these might be interesting as a drop in upgrade, that still gives me 5v tolerance. Obviously one issue will be the size of the board not fitting where the T3.2 would fit. Will talk more about this on another thread. So I ordered the 2+2 Kickstarter.
    I suspect KurtE already knows, but others thinking about the 3.5 as a drop in replacement, the touchRead function does not work on the 3.5. It should work on the 3.6. Also, the back row of pins (Vbattery, 3.3v, ground, program, DAC) have been relocated.

  6. #56
    Senior Member defragster's Avatar
    Join Date
    Feb 2015
    Posts
    4,808
    Quote Originally Posted by KurtE View Post
    Welcome back,

    I think you are right that maybe there should be some caching scheme for EEPROM. In my case often I only read from the EEPROM at startup. Maybe things like Servo offsets and the like. I may then have a special mode I go into that allows me to update these settings, but again this is in an isolated portion of the code.

    I have not heard anything either about T3.5 beta, but thought these might be interesting as a drop in upgrade, that still gives me 5v tolerance. Obviously one issue will be the size of the board not fitting where the T3.2 would fit. Will talk more about this on another thread. So I ordered the 2+2 Kickstarter.
    Thanks Kurt!

    Awesome to see that Paul is doing a mini_beta for T_3.5, that will pave the way for the KS shipping in good shape out of the box.

    Glad you see value: Indeed EEPROM usage varies - but some supported/generalized way to use it seems important - having no HSRUN access to it could be a real loss. Reading/Caching in setup() could cover most use cases without risking destabilizing anything. Having a way to write back without reprogramming to lower speed sketch (and back) would extend the functionality especially if the data changes during run time - even if it was followed by a restart to come up stable. But if the device can sleep() and return it should be able to recover without that?

    Built in SD card could supplant the EEPROM - only problem would be getting that data to new cards consistently as they come and go, or go bad.

    @MM - I put overt "lack of TOUCH in the KS specs" on the 'nit' thread. I think that should be called out. Both MM and Kurt RTFM in posts 1110 & 1111 confirmed it was not just a typo where T_3.6 has TOUCH and T_3.5 does not when I posted about that.

  7. #57
    Senior Member Wozzy's Avatar
    Join Date
    Jan 2013
    Location
    Philadelphia, Pennsylvania USA
    Posts
    307
    Quote Originally Posted by Frank B View Post
    Hm, ok, does this work with disabled usb and/or lower fcpu or teensy 3.2?
    Frank,
    I tried your code on my T3.6-r3 and get the following results:

    Code:
    CPU SPEED: 240MHz , COM3
    MAC: 0x000000000000
    Serial: 0
    
    CPU SPEED: 180MHz , COM3
    MAC: 0x000000000000
    Serial: 0
    
    CPU SPEED: 120MHz, COM6
    MAC: 0x04E9E5032345
    Serial: 205637
    
    CPU SPEED: 96MHz, COM6
    MAC: 0x04E9E5032345
    Serial: 205637
    
    CPU SPEED: 48MHz, No USB Emulated Serial
    MAC: 0x04E9E5032345
    Serial: 205637
    
    Cmason Code / THT T3_mac.zip
    CPU SPEED: 120MHz, COM6
    Chip MAC ID == 04: E9: E5: 04: E9: E5
    Teensy Serial# 3220210
    Reading 128-bit UniqueID from Teensy 0017FFFF FFFFFFFF 4E453506 1001001E
    Last edited by Wozzy; 08-29-2016 at 11:53 AM.

  8. #58
    Senior Member defragster's Avatar
    Join Date
    Feb 2015
    Posts
    4,808
    Quote Originally Posted by Wozzy View Post
    Frank,
    I tried your code on my T3.6-r3 and get the following results:
    If that is your ser# I think that is as expected as it doesn't alter speed - just does the 64 bit math operations - do you have TYQT installed - It gets the ser# from Paul's boot code you could compare.

    If you merged KurtE's PULL code changes I think you can emulate the timing of Paul's code before HSRUN goes active?

    You might run Frank's code here in parallel at this change? : usb_init_serialnumber();

    Then compare the results?

    I want to try this myself - but I'm not that far unpacked yet.

  9. #59
    Senior Member Wozzy's Avatar
    Join Date
    Jan 2013
    Location
    Philadelphia, Pennsylvania USA
    Posts
    307
    Defragster,

    TyQT V07.6 64-bit reports this serial number: 2056370
    Identity: 2056370-Teensy

    I tried KurtE's Core modifications, but did not see any changes, but I was looking for COM port changes, not Serial numbers.

  10. #60
    Senior Member defragster's Avatar
    Join Date
    Feb 2015
    Posts
    4,808
    Looks like it is working.

    AFAIK - Windows meshes the serial into recognized USB DEVICE, when that returns 0, it is a different device. Kurt's location precedes the hsrun loss of access right?

    <edit> phone edit - wrong words.
    Last edited by defragster; 08-29-2016 at 02:12 AM.

  11. #61
    Senior Member defragster's Avatar
    Join Date
    Feb 2015
    Posts
    4,808
    I hacked what I suggested - put FrankB's code into location suggested by KurtE's PULL - and I made subtle code change below as it is called once before HSRUN and then again twice after for my TYQT identified "2056390-Teensy":

    Code:
    uint64_t readMAC() {
      static uint64_t mac = 0;
    
      if ( 0 == mac ) {
    MAC: 0x04E9E5032347
    Serial: 205639

    CPU is T_3.6 F_CPU =120000000
    MAC: 0x04E9E5032347
    Serial: 205639

    CPU is T_3.6 F_CPU =240000000
    MAC: 0x04E9E5032347
    Serial: 205639

    CPU is T_3.6 F_CPU =180000000

  12. #62
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    453
    Perhaps the best solution would be to read the area in the startup code, before everything else.

  13. #63
    Senior Member MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,441
    Quote Originally Posted by xxxajk View Post
    Perhaps the best solution would be to read the area in the startup code, before everything else.
    Yep, it is not like the value is going to change.

  14. #64
    Senior Member defragster's Avatar
    Join Date
    Feb 2015
    Posts
    4,808
    Quote Originally Posted by xxxajk View Post
    Perhaps the best solution would be to read the area in the startup code, before everything else.
    Indeed that is what KurtE's code does (see post #58). But is does it for the specific purpose of setting the USB strings up just before HSRUN - so when it is needed later it is pre-saved in that storage area.

    But it doesn't save it in the # only format used by FrankB's code (which won't work once HSRUN is enabled) as user code to get MAC id and serial #.

    Kurt - I'm wondering it might be good save the 'num' in place of :: usb_init_serialnumber_called = 1. If that were made a public variable by PJRC - nobody would ever have to manually call code for MAC and ser#?

    Code:
    static uint32_t usb_init_serialnumber_called = 0;
    void usb_init_serialnumber(void)
    {
    	char buf[11];
    	uint32_t i, num;
    	if (usb_init_serialnumber_called)
    		return;
    
    //  'num' collect code here
    
            usb_init_serialnumber_called = num;  // NOTE - this is 32 bit and is *10 in some cases
    }
    NOTE: DIY boards will have 0xF's in that flash until set. And Paul said Zero was set as serial # in the K66 Proto boards, though I read this now:
    MAC: 0xFFFFFFFFFFFF
    Serial: 16777215

  15. #65
    Senior Member defragster's Avatar
    Join Date
    Feb 2015
    Posts
    4,808
    Discovered an anomaly? For the above I did KurtE's pre HSRUN addition. I also put FrankB's code local in the same mkdx128.c file for the above. The results in post #64 are misleading it seems

    Doing NEITHER in the mkdx128.c file results in 0 being read once in HSRUN mode - as expected - and the assigned USB's COM# port changes (according to TYQT) based on the serial# and hardware USB port (once the device is removed and forgotten by TYQT).

    However if EITHER is done in advance of HSRUN then BOTH work after HSRUN. So it 'seems' that HSRUN causes a 0 to be returned after reset if neither was called. If either was called - or both - before HSRUN that last returned value is returned again when HRUN mode stops it from getting 'current' data.

    I followed this up additionally by removing this from KurtE's code :: // usb_init_serialnumber_called = 1;
    The result is the same. Once the following is executed - repeat reads of FTFL_FCCOB# after HSRUN is set return the prior value:
    Code:
        FTFL_FSTAT = FTFL_FSTAT_CCIF;
        while (!(FTFL_FSTAT & FTFL_FSTAT_CCIF)) {}
    Wondering if there are other such values that HSRUN affects with regard to actual versus value 'cached' or not - that is 'stale' data is being used?

    I found this when I wondered if HSRUN alone caused the 'read' to fail - or if it was the subsequent clock setting. Finding the above I can confirm that after HSRUN is set - even if the clock speeds are not yet boosted over 120 MHz that the MAC/Ser# read fails. And I assume that without HSRUN {which I understand to boost the voltage, which must make EEPROM areas unsafe to touch?} putting the clock over 120MHz may cause instability without HSRUN - so to take the MCU out of HSRUN the clock would have to be set to a safe speed (120 MHz or less) to read the 4 KB of EEPROM for instance - then back to HSRUN and the clock setting restored. Though I also note that HSRUN is ALWAYS set ( SMC_PMCTRL = SMC_PMCTRL_RUNM(3); // enter HSRUN mode ) without regard to the clock speed final setting afterwards in mkdx128.c. But as expected: when the clock doesn't exceed 120 MHz it still works, but 144 MHz or above the MAC/Ser# read gets a zero - so I assume some other clock settings precede this code that change the effect of HSRUN?

    AFAIK this is accurate - hopefully it is complete as far as I went, and makes sense and adds some value for this thread and any possible 'on the fly' speed changes for EEPROM or other.

  16. #66
    Senior Member defragster's Avatar
    Join Date
    Feb 2015
    Posts
    4,808
    Following up on my prior post the following code change results in a valid serial at 120, 180 and 240 MHz. Both using FrankB's prior posted code and in TYQT reading the serial number on connecting to the device.

    From the empirical results above it seems making this call results in this value being made 'static/local/cached' to the processor before HSRUN goes active.
    > Is this a safe assumption and a sufficient solution?
    > I did not "__disable_irq(); & __enable_irq();" across this call - I do not know if the interrupts are active at this time?

    On my Win10 desktop - fresh install of IDE 1.6.11 and TeensyDuino 1.30b3 and programming to my T_3.6 I made the following change at line #842 of :: arduino_16_11\hardware\teensy\avr\cores\teensy3\mk 20dx128.c"


    Code:
    	// if we need faster than the crystal, turn on the PLL
       #if defined(__MK66FX1M0__)
        #if F_CPU > 120000000
    	FTFL_FCCOB0 = 0x41;
    	FTFL_FCCOB1 = 0x07;
    	FTFL_FSTAT = FTFL_FSTAT_CCIF;
    	while (!(FTFL_FSTAT & FTFL_FSTAT_CCIF)) {}
    	SMC_PMCTRL = SMC_PMCTRL_RUNM(3); // enter HSRUN mode
    	while (SMC_PMSTAT != SMC_PMSTAT_HSRUN) ; // wait for HSRUN
        #endif
    MAC: 0x04E9E5032347
    Serial: 205639

    CPU is T_3.6
    F_CPU =240000000
    <edit> I used FrankB's code - I see the PJRC code uses this line that may be more consistent::
    *(uint32_t *)&FTFL_FCCOB3 = 0x41070000;
    Last edited by defragster; 08-31-2016 at 04:11 AM.

  17. #67
    Senior Member Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    4,241
    I've created a library that helps to retrieve the Serial and MAC from within your sketch:

    https://github.com/FrankBoesing/TeensyMAC

    Works with Teensy LC, Teensy 3.0 .. 3.6 and in HS_RUN-Mode.

    usage: see "readme"
    Last edited by Frank B; 09-03-2016 at 12:52 PM.

  18. #68
    Senior Member Wozzy's Avatar
    Join Date
    Jan 2013
    Location
    Philadelphia, Pennsylvania USA
    Posts
    307
    Quote Originally Posted by Frank B View Post
    I've created a library that helps to retrieve the Serial and MAC from within your sketch:
    ...
    Works with Teensy LC, Teensy 3.0 .. 3.6 and in HS_RUN-Mode.
    Frank,
    It's working on my T3.6-R3, tested at 24, 48, 96, 120, 180 and 240MHz.
    Also TyQT and Arduino report a constant Com Port # at all speeds after running TeensyMAC

    I get the following output:

    Serial: 2056370
    MAC: 0x04E9E5032345

    Thanks

  19. #69
    Senior Member Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    4,241
    Thank you for testing, Wozzy

  20. #70
    I was using T3Mac.h on the Teensy 3.2 and it worked without defining:
    Code:
    uint8_t mac[] = {0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF};
    How does this one work?
    I wonder that:
    Code:
    Serial.printf("MAC: 0x%012llX\n", teensyMAC());
    only shows 14 digits?
    What does "0x%012llX\n" do?

  21. #71
    Senior Member Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    4,241
    Quote Originally Posted by MrGlasspoole View Post
    I was using T3Mac.h on the Teensy 3.2 and it worked without defining:
    Code:
    uint8_t mac[] = {0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF};
    How does this one work?
    I wonder that:
    Code:
    Serial.printf("MAC: 0x%012llX\n", teensyMAC());
    only shows 14 digits?
    Nope, it shows 12 digits.
    Whats makes you think a MAC has more digits ?

    https://en.wikipedia.org/wiki/MAC_address

    Output (one of T3.2 - just tested again) :
    Code:
    Serial: 1679610
    MAC: 0x04E9E5029019
    Please post your output, if it is different.

    Quote Originally Posted by MrGlasspoole View Post
    What does "0x%012llX\n" do?
    It's a format string...
    http://www.cplusplus.com/reference/cstdio/printf/

  22. #72
    Yes a MAC has 12 but the one you put in by hand has more.
    So i wonder how to use this now in:
    Code:
    uint8_t mac[] =
    Ethernet.begin(mac, ip, dnsServer, gateway, subnet);
    From your posting in the W5500 tread it sound the Teensy has a MAC?
    I thought this one reads the serial and uses this as MAC.

    On Arduinos i always used a Dallas DS18B20 as MAC:
    Code:
    // Set MAC via DS18B20
    void setupEthernet(){
      byte i;
      byte dsAddress[8];
      Serial.println( "Searching for DS18B20..." );
      oneWire.reset_search(); // Start the search with the first device
      if (!oneWire.search(dsAddress)) {
        Serial.println( "None found. Using default MAC address." );
      } else {
        Serial.println( "Success! Setting MAC address:" );
        Serial.print( " DS18B20 ROM  =" );
        for( i = 0; i < 8; i++) {
          Serial.write(' ');
          Serial.print( dsAddress[i], HEX );
        }
        Serial.println();
        // Offset array to skip DS18B20 family code, and skip mac[0]
        mac[1] = dsAddress[3];
        mac[2] = dsAddress[4];
        mac[3] = dsAddress[5];
        mac[4] = dsAddress[6];
        mac[5] = dsAddress[7];
      }
    
      Serial.print( " Ethernet MAC =" );
      for( i = 0; i < 6; i++ )
      {
        Serial.write( ' ' );
        Serial.print( mac[i], HEX );
      }
      Serial.println();
      startEthernet();
    }

  23. #73
    Senior Member Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    4,241
    Yup,, the serial is part of the mac.

    Perhaps try something like this ?
    Code:
    uint64_t mac64;
    uint8_t mac[6];
    
    mac64 = teensyMAC();
    mac[0] = mac64 >> 40;
    mac[1] = mac64 >> 32;
    mac[2] = mac64 >> 24;
    mac[3] = mac64 >> 16;
    mac[4] = mac64 >> 8;
    mac[5] = mac64;
    
    Ethernet.begin( mac, ..

  24. #74
    Ok after 2 hours of trying i can't figure out how to formate that thing to something like:
    Code:
    D0 50 99 2A 3D F6
    or
    D0:50:99:2A:3D:F6
    Code:
    uint64_t mac64;
    uint8_t mac[6];
    
    // Set MAC via Teensy serial
    void setupEthernet() {
      byte i;
      Serial.println("Reading MAC from hardware..." ); 
      mac64 = teensyMAC();
      mac[0] = mac64 >> 40;
      mac[1] = mac64 >> 32;
      mac[2] = mac64 >> 24;
      mac[3] = mac64 >> 16;
      mac[4] = mac64 >> 8;
      mac[5] = mac64;
      Serial.println("Success! Setting MAC address:");
      Serial.print("  Ethernet MAC =");
      for( i = 0; i < 6; i++ ) {
        Serial.write(' ');
        Serial.print("0x");
        Serial.print(mac[i], HEX);
      }
    
      Serial.println();
      Serial.printf("  Test 1 = 0x%012llX\n", mac[i], HEX);
      Serial.printf("  Test 2 = 0x%012llX\n", mac[i]);
      Serial.printf("  Test 3 = 0x%012llX\n", mac64);
      Serial.printf("  Test 4 = 0x%012llX\n", teensyMAC());
      Serial.println();
    
      startEthernet();
    }
    Output:
    Code:
    Reading MAC from hardware...
    Success! Setting MAC address:
      Ethernet MAC = 0x4 0xE9 0xE5 0x3 0xA7 0xAE
      Test 1 = 0x001000000000
      Test 2 = 0x001B00000000
      Test 3 = 0x04E9E503A7AE
      Test 4 = 0x04E9E503A7AE
    Last edited by MrGlasspoole; 01-22-2017 at 01:01 AM.

  25. #75
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,441
    Give this a try:

    Code:
      for( i = 0; i < 6; i++ ) {
        Serial.write(' ');
        Serial.printf("%02X", mac[i]);
      }

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •