Forum Rule: Always post complete source code & details to reproduce any issue!
Page 116 of 134 FirstFirst ... 16 66 106 114 115 116 117 118 126 ... LastLast
Results 2,876 to 2,900 of 3334

Thread: Teensy 4.0 First Beta Test

  1. #2876
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549

    Teensy 4 Beta2 Mod tolerates powered UARTS on startup

    ALL GOOD - First indications show T4B2mod able to power up and run without issue when 2 T_3.x UARTs powered and connected::
    > USB power on connect
    > Off/ON breakout button
    > 15s Restore Button press

    Just in from mail box, removed T4B2 from Breakout, installed T4B2mod onto Breakout - existing UART Tx&Rx Serial #2 and #4 connects in place to T_3.5 and T_3.1.

    added Notes - T_3.x UARTS power in all cases [except 2(b)/(c)] - no vBat power applied:
    1: The UART power glows the Breakout Green LED when breakout Power Button used to OFF, then cutting T4's USB power with switch the LED goes from GLOW to near half bright or Dim - don't recall that Glow/Dim difference - so assume the brownout change is diverting power to GND differently.
    2(a): When breakout Power Button used to OFF - and power removed ( 5V from USB cut or Cable pulled ) - and then power is restored it maintains the OFF state until breakout Power Button used to ON - UART power maintains the state.
    2(b): When breakout Power Button used to OFF - and power removed ( 5V from USB cut or Cable pulled ) - and T_3.x UARTS powered off - and then power is restored it returns in ON state.
    2(c):: UART 3.3V [RE 2(a)] is keeping the part of the MCU alive that is recording ON/OFF power button state. The same when vBat is powered and UART and other power removed.
    3: As expected the Teensy Button has no effect in either of the above cases
    4: Power button on breakout works normally as expected
    Last edited by defragster; 05-17-2019 at 09:22 PM. Reason: Added Notes ...

  2. #2877
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    @Paul - regarding post #2876:'Notes #2' will leave to your consideration the perhaps unexpected state of the pin power keeping some part of the 'RTC' section alive when power otherwise removed.
    It might allow a user to get stuck in this 'unexpected state' - it puzzled me more than a second when I hit the OFF button, then removed power , restored power - and the T4B2m didn't start as I thought it might looking for brownout repro - because the UART power kept the MCU alive to know it was 'OFF'
    And > I'm not sure if this indicates anything about UART power [any power on pins] backfeeding to the RTC segment in a bad way or powering anything else that should be 'off'?

    Other than that - I've not found a way to cause the prior 'Brown Out' failure to start on the T4B2m

    With DVM I see about 0.92 volts on VBat when running and powered - and VBat otherwise unconnected.
    Pulling USB cable with UART power on pins I see 2.21 on the end 3.3V pin and 0.82 volts on vBat that drops to 0.66V - but on plugging the USB the code below shows USB was maintained after leaving off some short time where DVM showed it drop to the 0.66 point where it seemed to hold.

    UPDATE on GLOW/DIM Breakout Green LED:
    > With no UART power the OFF T4's 3.3V end pin reads 0v.
    > Adding UART power on breakout Serial# the OFF 3.3V end pin shows 1.9 volts.
    > When the USB cable is pulled with UARTS powered to breakout I see 2.14 volts on the 3.3V pin as noted above

    Also just noticed (again?) that using Breakout button to OFF does not remove the T4 from Win PC USB - until the cable is pulled with UART power on T4 pins. But as expected after USB cable Win PC USB only connects when the breakout Power button takes it back ON.


    I confirmed this with this simplified sketch that starts RTC and checks when it had a prior valid time seen in setup().
    Code:
    uint32_t SFirst = 0;
    uint32_t SFound = 0;
    uint32_t ii = 0;
    elapsedMillis noDelay;
    void setup() {
      SFirst = millis();
      pinMode(LED_BUILTIN, OUTPUT);
      digitalWrite( LED_BUILTIN, HIGH );
      while ( !Serial );
      SFound = millis();
      Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
      Serial.printf("Setup Entry: %d\n", SFirst);
      delayMicroseconds( 100 ); // Check that the CPU Cycle Counter is Running
      Serial.printf("Serial Online: %d\n", SFound);
    
      //---------------------------------------------
      // Start RTC
      rtc_init();
      if ( 1558129316 > rtc_secs() )
        rtc_set_time();   //LPSRTC will start at 0 otherwise
      else
        Serial.print( " RTC kept time!" );
      Serial.printf( "\n millis: %d", millis());
      noDelay = 0;
    }
    
    bool flip = true;
    uint32_t lcc;
    uint32_t jj = 0;
    void loop() {
      if ( noDelay > 1000 ) {
        jj++;
        noDelay -= 1000;
        digitalWrite( LED_BUILTIN, flip );
        flip = !flip;
      }
    }
    
    void rtc_init() {
      CCM_CCGR2 |= CCM_CCGR2_IOMUXC_SNVS(CCM_CCGR_ON);
      SNVS_LPGPR = SNVS_DEFAULT_PGD_VALUE;
      SNVS_LPSR = SNVS_LPSR_PGD_MASK;
      if (!(SNVS_LPCR & 1)) {
        SNVS_LPCR |= 1;             // start RTC
        while (!(SNVS_LPCR & 1));
        Serial.print( "=====\tRTC Started!" );
      }
      else
      {
        Serial.print( "=====\tRTC already Running!" );
      }
    }
    
    void rtc_set_time() {
      uint32_t secs = 1558129316;
      SNVS_LPCR &= ~1;   // stop RTC
      while (SNVS_LPCR & 1);
      SNVS_LPSRTCMR = (uint32_t)(secs >> 17U);
      SNVS_LPSRTCLR = (uint32_t)(secs << 15U);
      SNVS_LPCR |= 1;             // start RTC
      while (!(SNVS_LPCR & 1));
    }
    
    uint32_t rtc_secs() {
      uint32_t seconds = 0;
      uint32_t tmp = 0;
      /* Do consecutive reads until value is correct */
      do
      {
        seconds = tmp;
        tmp = (SNVS_LPSRTCMR << 17U) | (SNVS_LPSRTCLR >> 15U);
      } while (tmp != seconds);
      return seconds;
    }
    <EDIT>: Just noticed the sketch above hits setup() at 300 ms and online when no UART power about 400 ms. When UART power from debug T_3.x is present the USB online time is typically 340 ms or lower from power on or Button upload. So the powered pins are affecting the USB 'readyness'
    Last edited by defragster; 05-18-2019 at 07:48 AM. Reason: Update Glow/Dim

  3. #2878
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    @Paul - forgot to mention/ask - did you get the 15sRestore image write corrected/changed on the T4B2m you sent to me? USB View doesn't show it as right but:
    > I did 5 15s Restores and Windows did not complain about the loaded Blink sketch with a pop up note - though the recorded info is confused. See below for details.

    BTW: updated Msg #6 for this issue >> Paul PCB Mod post Beta2 Post #2876/2877 T4B2mod corrects failed start/brownout

    After doing this below it occurred to me I had the UART power on - but it does not seem to have direct affect {powered USB having stale info} - though with UARTS OFF - repeat resulted in repeat of FIRST copy of USBView data with valid Ser#, not the NXP version I saw once.

    Did you make some note once about the Bootloader chip having the Serial# - or was that RTC setup or other?

    TyCommander on this T4B2m shows Serial Number as : 5847860
    >> One USBView block below after 15s Restore shows Serial #2114150 ???
    >> IDE 'Board Info' does not work with 'TeensyPorts'
    >> IDE board info does not get Serial # from upload when on 'Serial Ports'?
    BN: Teensy
    VID: 0x16C0
    PID: 0x0483
    SN: Upload any sketch to obtain it
    TeensyLoader confirms that Serial# - all is well after first Button Upload after 15s Restore:
    Code:
    00:02:00.532 (loader):  gauge old value = 16
    00:02:00.548 (loader): sending reboot
    00:02:00.548 (loader): begin wait_until_offline
    00:02:00.562 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
    00:02:00.562 (ports 2): remove: loc=usb:0/140000/0/8/6
    00:02:00.562 (ports 2): usb_remove: usb:0/140000/0/8/6
    00:02:00.562 (ports 2): nothing new, skipping HID & Ports enum
    00:02:00.610 (loader): offline, waited 1
    00:02:00.610 (loader): end operation, total time = 0.316 seconds
    00:02:00.610 (loader): set background IMG_REBOOT_OK
    00:02:00.610 (loader): redraw timer set, image 14 to show for 1200 ms
    00:02:00.619 (loader): HID/win32:  vid:046D pid:C534 ver:2901
    00:02:00.619 (loader): HID/win32:  vid:1B80 pid:B406 ver:0100
    00:02:00.619 (loader): HID/win32:  vid:046D pid:C534 ver:2901
    00:02:00.619 (loader): HID/win32:  vid:1B80 pid:B406 ver:0100
    00:02:00.619 (loader): HID/win32:  vid:0764 pid:0501 ver:0001
    00:02:00.619 (loader): HID/win32:  vid:1B80 pid:B406 ver:0100
    00:02:00.619 (loader): HID/win32:  vid:046D pid:C534 ver:2901
    00:02:00.619 (loader): HID/win32:  vid:1B80 pid:B406 ver:0100
    00:02:00.619 (loader): HID/win32:  vid:046D pid:C534 ver:2901
    00:02:00.619 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    00:02:00.620 (ports 2): nothing new, skipping HID & Ports enum
    00:02:00.877 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
    00:02:00.879 (ports 2): found_usb_device, id=\\?\usb#vid_16c0&pid_0483#5847860#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
    00:02:00.879 (ports 2): found_usb_device, loc=usb:0/140000/0/8/6    Port_#0006.Hub_#0005
    00:02:00.879 (ports 2): found_usb_device, hwid=USB\VID_16C0&PID_0483&REV_0279
    00:02:00.879 (ports 2): found_usb_device, devinst=00000006
    00:02:00.879 (ports 2): add: loc=usb:0/140000/0/8/6, class=Ports, vid=16C0, pid=0483, ver=0279, serial=5847860, dev=\\?\usb#vid_16c0&pid_0483#5847860#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
    00:02:00.879 (ports 2):   comport_from_devinst_list attempt
    00:02:00.879 (ports 2):   found Ports in classguid_list at index=0
    00:02:00.879 (ports 2):   port COM29 found from devnode
    00:02:00.879 (ports 2): found_usb_device complete
    00:02:00.880 (ports 2): usb_add: usb:0/140000/0/8/6  COM29 (Teensy 4-Beta2) Serial
    00:02:00.902 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
    00:02:00.903 (ports 2): nothing new, skipping HID & Ports enum
    00:02:00.921 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    00:02:00.922 (ports 2): nothing new, skipping HID & Ports enum
    USBView on Windows showed this after 15s Restore - with valid Serial#:
    Code:
    [Port6]  :  USB Composite Device
    
    
    Is Port User Connectable:         yes
    Is Port Debug Capable:            no
    Companion Port Number:            0
    Companion Hub Symbolic Link Name: 
    Protocols Supported:
     USB 1.1:                         yes
     USB 2.0:                         yes
     USB 3.0:                         no
    
    Device Power State:               PowerDeviceD3
    
           ---===>Device Information<===---
    English product name: "Teens?????????????"
    
    ConnectionStatus:                  
    Current Config Value:              0x01  -> Device Bus Speed: High (is not SuperSpeed or higher capable)
    Device Address:                    0x0F
    Open Pipes:                           4
    
              ===>Device Descriptor<===
    bLength:                           0x12
    bDescriptorType:                   0x01
    bcdUSB:                          0x0110
    bDeviceClass:                      0x00  -> This is an Interface Class Defined Device
    bDeviceSubClass:                   0x00
    bDeviceProtocol:                   0x00
    bMaxPacketSize0:                   0x40 = (64) Bytes
    idVendor:                        0x16C0 = Van Ooijen Technische Informatica
    idProduct:                       0x0486
    bcdDevice:                       0x0279
    iManufacturer:                     0x01
    String Descriptor for index 1 not available while device is in low power state.
    iProduct:                          0x02
         English (United States)  "Teens?????????????"
    iSerialNumber:                     0x03
         English (United States)  "5847860"
    bNumConfigurations:                0x01
    
              ---===>Open Pipes<===---
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x83  -> Direction: IN - EndpointID: 3
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x04  -> Direction: OUT - EndpointID: 4
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x02  -> Direction: OUT - EndpointID: 2
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0020 = 1 transactions per microframe, 0x20 max bytes
    bInterval:                         0x02
    
           ---===>Full Configuration Descriptor<===---
    
              ===>Configuration Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x02
    wTotalLength:                    0x0049  -> Validated
    bNumInterfaces:                    0x02
    bConfigurationValue:               0x01
    iConfiguration:                    0x00
    bmAttributes:                      0xC0  -> Self Powered
    MaxPower:                          0x32 = 100 mA
    
              ===>Interface Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x04
    bInterfaceNumber:                  0x00
    bAlternateSetting:                 0x00
    bNumEndpoints:                     0x02
    bInterfaceClass:                   0x03  -> HID Interface Class
    bInterfaceSubClass:                0x00
    bInterfaceProtocol:                0x00
    iInterface:                        0x00
    
              ===>HID Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x21
    bcdHID:                          0x0111
    bCountryCode:                      0x00
    bNumDescriptors:                   0x01
    bDescriptorType:                   0x22 (Report Descriptor)
    wDescriptorLength:               0x001C
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x83  -> Direction: IN - EndpointID: 3
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x04  -> Direction: OUT - EndpointID: 4
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Interface Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x04
    bInterfaceNumber:                  0x01
    bAlternateSetting:                 0x00
    bNumEndpoints:                     0x02
    bInterfaceClass:                   0x03  -> HID Interface Class
    bInterfaceSubClass:                0x00
    bInterfaceProtocol:                0x00
    iInterface:                        0x00
    
              ===>HID Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x21
    bcdHID:                          0x0111
    bCountryCode:                      0x00
    bNumDescriptors:                   0x01
    bDescriptorType:                   0x22 (Report Descriptor)
    wDescriptorLength:               0x0021
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x02  -> Direction: OUT - EndpointID: 2
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0020 = 1 transactions per microframe, 0x20 max bytes
    bInterval:                         0x02
    Then I hit bootloader to go to HID mode to make sure I was on the right device, then repowered the T4b2m and now it shows this again NXP_SE Blank RT Family?
    Code:
    [Port6]  :  USB Input Device
    
    
    Is Port User Connectable:         yes
    Is Port Debug Capable:            no
    Companion Port Number:            0
    Companion Hub Symbolic Link Name: 
    Protocols Supported:
     USB 1.1:                         yes
     USB 2.0:                         yes
     USB 3.0:                         no
    
    Device Power State:               PowerDeviceD0
    
           ---===>Device Information<===---
    English product name: "SE Blank RT Family "
    
    ConnectionStatus:                  
    Current Config Value:              0x01  -> Device Bus Speed: High (is not SuperSpeed or higher capable)
    Device Address:                    0x40
    Open Pipes:                           1
    
              ===>Device Descriptor<===
    bLength:                           0x12
    bDescriptorType:                   0x01
    bcdUSB:                          0x0200
    bDeviceClass:                      0x00  -> This is an Interface Class Defined Device
    bDeviceSubClass:                   0x00
    bDeviceProtocol:                   0x00
    bMaxPacketSize0:                   0x40 = (64) Bytes
    idVendor:                        0x1FC9 = NXP Semiconductors
    idProduct:                       0x0135
    bcdDevice:                       0x0101
    iManufacturer:                     0x01
         English (United States)  "NXP      SemiConductors Inc "
    iProduct:                          0x02
         English (United States)  "SE Blank RT Family "
    iSerialNumber:                     0x00
    bNumConfigurations:                0x01
    
              ---===>Open Pipes<===---
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x04
    
           ---===>Full Configuration Descriptor<===---
    
              ===>Configuration Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x02
    wTotalLength:                    0x0022  -> Validated
    bNumInterfaces:                    0x01
    bConfigurationValue:               0x01
    iConfiguration:                    0x00
    bmAttributes:                      0xC0  -> Self Powered
    MaxPower:                          0x32 = 100 mA
    
              ===>Interface Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x04
    bInterfaceNumber:                  0x00
    bAlternateSetting:                 0x00
    bNumEndpoints:                     0x01
    bInterfaceClass:                   0x03  -> HID Interface Class
    bInterfaceSubClass:                0x00
    bInterfaceProtocol:                0x00
    iInterface:                        0x00
    
              ===>HID Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x21
    bcdHID:                          0x0100
    bCountryCode:                      0x00
    bNumDescriptors:                   0x01
    bDescriptorType:                   0x22 (Report Descriptor)
    wDescriptorLength:               0x004C
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x04
    REALLY ODD - I repeated the above 15s Restore - then power off and ON - and it is now TEENSYDUINO with WRONG Serial#, Not NXP_SE BLANK
    Code:
    [Port3]  :  USB Serial Device
    
    
    Is Port User Connectable:         yes
    Is Port Debug Capable:            no
    Companion Port Number:            0
    Companion Hub Symbolic Link Name: 
    Protocols Supported:
     USB 1.1:                         yes
     USB 2.0:                         yes
     USB 3.0:                         no
    
    Device Power State:               PowerDeviceD0
    
           ---===>Device Information<===---
    English product name: "USB Serial"
    
    ConnectionStatus:                  
    Current Config Value:              0x01  -> Device Bus Speed: Full (is not SuperSpeed or higher capable)
    Device Address:                    0x34
    Open Pipes:                           3
    
              ===>Device Descriptor<===
    bLength:                           0x12
    bDescriptorType:                   0x01
    bcdUSB:                          0x0110
    bDeviceClass:                      0x02  -> This is a Communication Device
    bDeviceSubClass:                   0x00
    bDeviceProtocol:                   0x00
    bMaxPacketSize0:                   0x40 = (64) Bytes
    idVendor:                        0x16C0 = Van Ooijen Technische Informatica
    idProduct:                       0x0483
    bcdDevice:                       0x0276
    iManufacturer:                     0x01
         English (United States)  "Teensyduino"
    iProduct:                          0x02
         English (United States)  "USB Serial"
    iSerialNumber:                     0x03
         English (United States)  "2114150"
    bNumConfigurations:                0x01
    
              ---===>Open Pipes<===---
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x82  -> Direction: IN - EndpointID: 2
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0010 = 0x10 bytes
    bInterval:                         0x40
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x03  -> Direction: OUT - EndpointID: 3
    bmAttributes:                      0x02  -> Bulk Transfer Type
    wMaxPacketSize:                  0x0040 = 0x40 bytes
    bInterval:                         0x00
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x84  -> Direction: IN - EndpointID: 4
    bmAttributes:                      0x02  -> Bulk Transfer Type
    wMaxPacketSize:                  0x0040 = 0x40 bytes
    bInterval:                         0x00
    
           ---===>Full Configuration Descriptor<===---
    
              ===>Configuration Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x02
    wTotalLength:                    0x0043  -> Validated
    bNumInterfaces:                    0x02
    bConfigurationValue:               0x01
    iConfiguration:                    0x00
    bmAttributes:                      0xC0  -> Self Powered
    MaxPower:                          0x32 = 100 mA
    
              ===>Interface Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x04
    bInterfaceNumber:                  0x00
    bAlternateSetting:                 0x00
    bNumEndpoints:                     0x01
    bInterfaceClass:                   0x02  -> This is Communications (CDC Control) USB Device Interface Class
    bInterfaceSubClass:                0x02
    bInterfaceProtocol:                0x01
    iInterface:                        0x00
      -> This is a Communications (CDC Control) USB Device Interface Class
    
              ===>Descriptor Hex Dump<===
    bLength:                           0x05
    bDescriptorType:                   0x24
    05 24 00 10 01 
      -> This is a Communications (CDC Control) USB Device Interface Class
    
              ===>Descriptor Hex Dump<===
    bLength:                           0x05
    bDescriptorType:                   0x24
    05 24 01 01 01 
      -> This is a Communications (CDC Control) USB Device Interface Class
    
              ===>Descriptor Hex Dump<===
    bLength:                           0x04
    bDescriptorType:                   0x24
    04 24 02 06 
      -> This is a Communications (CDC Control) USB Device Interface Class
    
              ===>Descriptor Hex Dump<===
    bLength:                           0x05
    bDescriptorType:                   0x24
    05 24 06 00 01 
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x82  -> Direction: IN - EndpointID: 2
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0010 = 0x10 bytes
    bInterval:                         0x40
    
              ===>Interface Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x04
    bInterfaceNumber:                  0x01
    bAlternateSetting:                 0x00
    bNumEndpoints:                     0x02
    bInterfaceClass:                   0x0A  -> This is a CDC Data USB Device Interface Class
    bInterfaceSubClass:                0x00
    bInterfaceProtocol:                0x00
    iInterface:                        0x00
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x03  -> Direction: OUT - EndpointID: 3
    bmAttributes:                      0x02  -> Bulk Transfer Type
    wMaxPacketSize:                  0x0040 = 0x40 bytes
    bInterval:                         0x00
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x84  -> Direction: IN - EndpointID: 4
    bmAttributes:                      0x02  -> Bulk Transfer Type
    wMaxPacketSize:                  0x0040 = 0x40 bytes
    bInterval:                         0x00
    Last edited by defragster; 05-18-2019 at 07:26 AM.

  4. #2879
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,057
    did you get the 15sRestore image write corrected/changed on the T4B2m you sent to me?
    Nope, the 15 sec restore is exactly the same (likely to be unreliable) as the first beta #2 and beta #1 boards.

    In other news, yesterday the (hopefully final) bare PCB protos with the brown-out restart mod arrived. Electrically, the mod is identical to the wire I soldered onto your board. These PCBs came in too late to deliver to the contract manufacturer. Robin is going to take them over early Monday morning. Once they've soldered the BGA+diodes, I'll hand solder the rest of the parts and run some tests. If those boards work, and no more issues turn up, we're going to finalize T4 using that PCB rev and start the 3 week lead time to get the first batch of production boards.

    Now is the time to focus on the hardware side. If there's anything wrong or not-so-great with the PCB design, in a matter of days it'll soon be forever set in stone. Or at least FR4 fiberglass.

    After the PCBs are ordered, I'll work on a bootloader update to fix the 15 sec restore and some minor bugs I've seen here. Turns out the first beta #2 boards will not update, so they are forever set with the bootloader they currently have. The 2nd round of 1062 boards with the white wire on the bottom can do the bootloader update.

    There will never be any more bootloader updates for the beta #1 boards (with 1052 chip). PJRC will send a 1062 board to everyone who currently has only 1052.

    Between now and final T4 release, we should get about 25 more beta boards. Those are a result of a practice run the contract manufacturer did last week. They will all need the white wire (brown-out restart mod) added to make them the same as the final T4 design. I also have 20 more of the breakout boards coming. If anyone reading this and on the list of approved beta testers has been considering joining in near the end when the hardware design is finalized, we're about 1 week away from that point. Because soldering those white wires takes time, as always we're going to ask anyone who's too busy to just hold off until the final release. But the next couple weeks will be the last chance to get it with the breakout board. Later I'll publish the files for the breakout boards, but those 20 are probably going to be the very last ones made.

  5. #2880
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    523
    @PaulStoffregen I'll take one!
    Going to be able to have a bit more time to play, been working on LPC voice synth and my own "dev board" (different ARM chip).
    Email robin again?

  6. #2881
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    Morning after looks good here for the " soldering those white wires takes time " board. Assuming no special testing focus where the white wire might affect any other chip function?

    Did repeat of p#2876 and another dozen button push uploads with and without UART power - yesterday discovered that Frank_B's Compile.cmd can work with TeensyLoader not just TyCommander - just requires Button Push to drop TyComm SerMon and wake TeensyLoader for upload.

    As long as the 20% faster Turbo Boot USB start [when UART power on pins] doesn't indicate other issue of concern. I never looked this close at T_3.6 - not sure if it holds RTC when pins have power, but the T4 holds RTC - as well as the OFF state.

  7. #2882
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    Paul - looking at parts to build out the breakout board.
    On the prior shipped B2 board there are a pair of 10K SMD resistors placed end to end between CANH and CANL on the bottom - is that 20K resistance needed there? If so would a single resistor of 15K or 22K be okay?

    @tonton81 / mjs513 : for CANFD - is there a link to current code that would run on a pair of B2_1062's - where I put 120 Ohm on each board?

  8. #2883
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,330
    @defragster - @tonton81

    The CANFD portion of the library of is still a work in progress but with the library in it current state you can send CAN 2.0 messages over CAN3 between the two boards.

    I just got the breakout board this afternoon with a T4B2m. I'll work on soldering that up tomorrow morning. Learned soldering at night is not a good thing for me At that point I will probably test CANFD between the 2 boards with the SDK examples and see if it works. If it does I will post it so you can take it for a spin.

    As for @tonton81's lib I can problem post a sample of that as well unless Tony beats me to it

  9. #2884
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    @mjs513 - sounds good. I likely won't get breakout built until Sunday afternoon either. Do you have an answer on the twin 10K resistors between CANH and CANL on the bottom side? Paul did other with SMD - but those on prior look sandwiched in after the terminal block and I don't see them in my goody bag - easy to replace as/if needed …

    Oh - what was the answer on the 'S' pin for transmit? Does that need to be changed for Receive?

    Just wondering if the 'intermittent faults' you (and I) were seeing as some point were by any chance a side effect from not having this latest B2mod made? Maybe you were having 'light'-brown out failures - where it started … but shouldn't have in that state?

  10. #2885
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,330
    @defragster
    Do you have an answer on the twin 10K resistors between CANH and CANL on the bottom side? Paul did other with SMD - but those on prior look sandwiched in after the terminal block and I don't see them in my goody bag - easy to replace as/if needed …
    Unfortunately no. I added the resistor anyway - to be honest I didn't notice the resistors between the pins until after I soldered the resistor when I running some jumper wires from the underside pogo pins.

    Oh - what was the answer on the 'S' pin for transmit? Does that need to be changed for Receive?
    No difference -- you have to do a digitalWrite(6,LOW) to enable the chip. Just remember on the breakout boards they are labeled wrong - CANH is really CANL and CANL is CANH on the board. That was the cause of my problems all along.

    Just wondering if the 'intermittent faults' you (and I) were seeing as some point were by any chance a side effect from not having this latest B2mod made? Maybe you were having 'light'-brown out failures - where it started … but shouldn't have in that state?
    It could very well be, will have to run some of the same sketches I had problem with on the T4b2m and see if it occurs again.

  11. #2886
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    Just looked … I found some 60# 10K SMD's that should work and some tinier 40# ones that would probably not work after soldering

    What POGO jumper wires did you do? I only got 6 POGO's so USB, CAN and POWER are 5 of them. Not sure if #6 was for extra for loss - not enough to grab any more Serial#'s ...

    I remembered the CAN H/L swap - I figured since both are mislabeled that two wrongs will make it right? As long as I swap if using the CAN2 boards.

    I should go back to my base debug_tt - having assert and some added stuff would be a good start.

  12. #2887
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,057
    Quote Originally Posted by defragster View Post
    On the prior shipped B2 board there are a pair of 10K SMD resistors placed end to end between CANH and CANL on the bottom - is that 20K resistance needed there? If so would a single resistor of 15K or 22K be okay?
    You can just omit that resistor. It's not needed.

    I had planned to use it for testing without having the 120 ohm resistor or any connection to a CAN network. But I ran out of time and sent all the breakouts without doing that testing.

    So that resistor does nothing and is not needed. Just ignore it.

  13. #2888
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    Quote Originally Posted by PaulStoffregen View Post
    You can just omit that resistor. It's not needed.
    ...
    That sounds easy enough.

  14. #2889
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    The DYI breakout seems to be working … of course 120 ohm isn't a default resistor either - hopefully twin 220's for 110 Ohms is close enough for short wires? … where the wires will be CAT5/6? I may go to a meter long to get it off my desk?

    For the T4B2 going on the DYI breakout I pulled the solder blob off VIN<>VUSB and feeding it 5V & GND from a spare Teensy plugged into wall wart.

    Basic operations seem right - 15s Restore and uploads - USBHost to HDD runs 11 MB/sec writes - so the USB POGO's work, CANFD … soon.

    BTW: The finicky Power Button pin FOLLOWED the T4B2 to the DYI breakout, the T4B2m works no problem on the B2_pjrc_breakout - where the T2B4 required something added to fill the hole. On the DYI breakout and T4B2 I filled the Power hole with solder and it works now. Not sure of the Power POGO was to be fatter headed? When I did the DYI all POGO's the same and the head pushed all the way into the Power pin hole.


    Paul: Something Odd with a USB write sketch. T4B2 - no external UARTS - 5V external Power.
    Sketch is busy work finding 6542 primes up to 65535 and printing them with two delay(300)'s in loop, works fine. IDE TeensyPorts or TyComm both just FLASH data - no attempt to scroll 655 lines of prime numbers!
    Using TyComm - with constant powere/USB connect - I can click GUI 'Serial Off' then On and there is no problem. Doing this same test on T4B2m also no problem.

    Odd Thing: T4B2 external powered running Primes print sketch ( with or without VBat ) doing Prints with Blink:
    1 >> UnPlug USB to PC - leaving the T4running on ext 5V showing Blink :: PC Device removal sounds; repeat for 2a or 2b below.
    2a >> Plug USB back in - PC USB Attached sounds, but TyComm SerMon does not pick up printing. GUI button Toggle does nothing.
    2b >> Plug USB back in - PC USB Attached sounds, but IDE SerMon TeenyPorts does not pick up printing - it leaves a BLANK screen. Close and reopen SerMon does not resume printing - Blink continues
    3a >> Repower w/5V ext, POWER Off/On button, or reprogram T4B2 required to resume USB connection to printed output


    * Note 1: It is fine if T4B2 restarts with no Serial connect - then connection is made it runs normally - either by TyComm GUI Serial button, or unplug USB, restart T4, then plug USB.
    * Note 2: I can have SerMon as TyComm, disable Serial, go to IDE T_ports Sermon and it picks up, close T_ports Sermon, resume TyComm as Sermon - no problem.
    * Note 3: The above were not meant to be smileys - but time for levity and sleep so I'm leaving them parsed.


    Conclusion: Problem is externally powered T4 doing USB output when USB is disconnected, T4 continues running - but USB stays 'offline' when cable plugged in.

    Sketch - DiskPrimes.ino - nothing special except for Overflow of Serial.print. Works the same with this in place below - just requires longer time unplugged, or multiple repeats :: uint32_t m = 2, n = 65,
    Code:
    uint32_t SFirst = 0;
    uint32_t SFound = 0;
    void setup() {
    	SFirst = millis();
    	pinMode(LED_BUILTIN, OUTPUT);
    	digitalWrite( LED_BUILTIN, HIGH );
    	Serial.begin(115200);
    	while (!Serial && millis() < 4000 );
    	SFound = millis();
    	Serial.printf("Setup Entry: %d\n", SFirst);
    	delayMicroseconds( 100 ); // Check that the CPU Cycle Counter is Running
    	Serial.printf("Serial Online: %d\n", SFound);
    	Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
    }
    
    uint32_t small_primes_between(uint32_t &m, uint32_t &n);
    bool is_prime(uint32_t x);
    bool is_prime_small(uint32_t x);
    uint16_t smallPrimes[6550];
    void loop() {
    	uint32_t m = 2, n = 65535, pp, ii = 0, ps = 0, dt, dt1;
    	dt = micros();
    	do {
    		pp = small_primes_between( m, n );
    		ii++;  // count number to store and verify
    		smallPrimes[ii] = pp; // index 0 holds count
    	} while ( pp );
    	dt = micros() - dt;
    	smallPrimes[0] = ii - 1;
    	dt1 = micros();
    	for ( ii = 1; ii <= smallPrimes[0]; ii++) {
    		Serial.print(smallPrimes[ii]);
    		ps += smallPrimes[ii]; // capture sum to verify
    		if ( !(ii % 10) ) Serial.println(); else Serial.print("   ");
    	}
    	dt1 = micros() - dt1;
    	Serial.print("\n# primes 6542==");
    	Serial.println(smallPrimes[0]);
    	Serial.print("Sum primes 202288087==");
    	Serial.print(ps);
    	Serial.print("\t\tmicroseconds now=");
    	Serial.println(micros());
    	delay(600);
    	digitalWriteFast( LED_BUILTIN, !digitalReadFast( LED_BUILTIN ) );
    }
    
    bool is_prime_small(uint32_t x)
    {
    	if (x <= 2) return (x == 2);
    	if (x % 2 == 0) return false;
    	const int limit = sqrt(x);
    	for (int i = 3; i <= limit; i += 2) {
    		if (x % i == 0) return false;
    	}
    	return true;
    }
    
    uint32_t small_primes_between(uint32_t &m, uint32_t &n)
    {
    	for (uint32_t i = m; i < n; ++i) {
    		m++;
    		if (is_prime_small(i)) return i;
    	}
    	return 0;
    }
    NOTE: Three things for Post #6
    > THIS post 2889 ext power USB disconnect Test
    > IDE 'Board Info' not showing T4 serial # with IDE Serial
    > IDE 'Board Info' not showing T4 at all with Teensy_ports Serial

  15. #2890
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,330
    @defragster and others
    Finished soldering up the breakout board for the T4B2m and did a couple of quick tests before the day starts and other distractions:
    1. Ran the logger_readwrite_fs sketch with a USB thumb drive which gave me the same results as on the T4B2.
    2. Gave the power button a couple pushes to test on/off which seemed to work with no apparent problem.
    3. Hooked up CAN3-CAN3 and ran both boards in legacy CAN 2.0B legacy mode which worked with the test sketch that I @tonton81 gave me to play with. This worked without a problem once I got the pogo pins aligned properly.

    Will test out CANFD - CANFD between both boards later today - family coming over so most of the day will be distracted. Also, will clean up the sketches for CAN and post them later.

    UPDATE: Just verified that the CANFD SDK example does work using CAN3. Again CANFD works going from T4 to T4
    Last edited by mjs513; 05-19-2019 at 03:21 PM.

  16. #2891
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,330
    CANFD Example Sketches

    Attached is a zip of two sketches using the SDK examples. Node A sketch with send a message to Node B. Node B should be started first. Node A will wait for you enter a "A" or "a" to start sending.

    An interesting thing is I can't use two 2 T4s with the TyCommander - one seems to always hang it - if this occurs use the Arduino ser mon which seems to work no problems.
    Attached Files Attached Files

  17. #2892
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    Quote Originally Posted by mjs513 View Post
    CANFD Example Sketches

    Attached is a zip of two sketches using the SDK examples. Node A sketch with send a message to Node B. Node B should be started first. Node A will wait for you enter a "A" or "a" to start sending.

    An interesting thing is I can't use two 2 T4s with the TyCommander - one seems to always hang it - if this occurs use the Arduino ser mon which seems to work no problems.
    Will give that a try soon. I'm currently using SublimeText w/compile.cmd and TeensyLoader with button push upload - and TyComm for serial monitors --- will see if that works here.

  18. #2893
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    @mjs513 - two units T4B2m as nodeA and T4B2 as nodeB - running sketch as extracted from ZIP with no changes or other dependent files? Connected GND to GND and CANL to CANL and CANH to CANH - each with a foot of Cat5 28 ga wire. On each Breakout I have two parallel 220 Ohms resistors - for a next 110 Ohms on the pins labeled 120.

    Indeed when TyComm on "A" sent "A" it would go offline? So restarted … B first then A with TyComm no Serial and used IDE SerMon for A.

    Now send an 'a' or 'A' and nothing seems to happen? No text displayed and no LED flash?

    Note - I POGO soldered pins 30 and 31 - but didn't do anything to confirm they are making good contact … On T4B2_B w/DYI breakout and after putting T4B2m_A on PJRC breakout - I didn't do anything to confirm that they are lined up to contact.

  19. #2894
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,330
    @defragster

    You should see the startup messages for both nodes on each serial monitor.
    Note - I POGO soldered pins 30 and 31 - but didn't do anything to confirm they are making good contact … On T4B2_B w/DYI breakout and after putting T4B2m_A on PJRC breakout - I didn't do anything to confirm that they are lined up to contact.
    I had a devil of a time getting them lined up properly. I used Kurt's BlinkAnyPin sketch, hooked a wire from SCK and touch pin 30 and 31 (can use the undersided contracts). If they don't blink of stay on they are not aligned correctly.

    EDIT: Just for ref I soldered a 120ohm resistor to both boards. Also I am just using a couple of simple breadboard jumper wires to connect the two boards.

    One other debug that you can try is after you start Node A and nothing shows up try uplugging and replugging in node B. For some reason it sometimes get stuck. But I usually see a message come through on Node A.

    Here is the test sketch, it comes in handy to check pins:
    Code:
    int current_pin = 13;
    int next_pin_number = 0;
    #define DBGSerial Serial
    void setup() {
        // Blink any pin.  Note: I put pin 13 as input to see if we can
      // jumper to it to see if we can find the pin...
      while (!Serial && millis() < 5000);
      DBGSerial.begin(115200);
      delay (250);
      DBGSerial.println("Find Pin by blinking");
      DBGSerial.println("Enter pin number to blink"); 
      pinMode(13, OUTPUT);
    }
    
    void loop() {
      // put your main code here, to run repeatedly:
      if (DBGSerial.available()) {
        int ch;
        while ((ch = DBGSerial.read()) != -1) {
          if ((ch >='0') && (ch <= '9')) {
            next_pin_number = next_pin_number * 10 + (ch-'0');
          } else {
            if (next_pin_number != 0) {
              digitalWrite(current_pin, LOW); // turn the previous pin to low...
              current_pin = next_pin_number;
              pinMode(current_pin, OUTPUT);
              if (current_pin != 13)
                pinMode(13, INPUT);
              digitalWrite(current_pin, HIGH);
              next_pin_number = 0;  // setup to enter next pin
              DBGSerial.printf("Now Blinking pin %d\n\r", current_pin);
            }
          }
        }
      } else {
        digitalWrite(current_pin, !digitalRead(current_pin));
        delay(250);
      }  
    }
    Going to work on a couple of simpler sketches but have to figure out how FD Fifo works. This is the example from the sdk just to verify that FD was working.
    Last edited by mjs513; 05-20-2019 at 01:04 AM. Reason: added info

  20. #2895
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,330
    @defragster

    There is one other thing that I noticed on the T4B2m. I have been using it for Node B testing and notice when I first plug it in I don't get anything on the Sermonitor. When I unplug it I then see the out of the Serial prints. The second time I plug it in it works.

  21. #2896
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,009
    this happens usually when error frame bits are not reset or theres no other nodes on the network to ack the message when they get out of sync, once the counters overflow the bus disables itself, resetting the controller will ressolve this, if the bus was populated this wouldnt be an issue, provided the controller attempts recovery, to attempt bus recovery there has to be valid activity on the bus, or no acks will occur, and will sit there doin nothing

  22. #2897
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    tonton81 - if you have any good test or working code.

    Will do a pin check - was going to do that next ... but just got a hard drive to recover dropped on me ...

    Swapped A to T4B2 and B to T4B2m. I get the startup text below - then nothing after.

    opps - took posting the startup text for granted .

    - "A" T4B2m gives:
    Code:
    CCM_CSCMR2: 13192E0E
    CCM_CCGR7: FFFFFFFF
    0
    ********* FLEXCAN Interrupt EXAMPLE *********
        Message format: Standard (11 bit id)
        Message buffer 10 used for Rx.
        Message buffer 9 used for Tx.
        Interrupt Mode: Enabled
        Operation Mode: TX and RX --> Normal
    *********************************************
    
    This is node A - start B first
    
    Then press A or a key
    And from T4B2:
    Code:
    CCM_CSCMR2: 13192E0E
    CCM_CCGR7: FFFFFFFF
    0
    ********* FLEXCAN Interrupt EXAMPLE *********
        Message format: Standard (11 bit id)
        Message buffer 10 used for Rx.
        Message buffer 9 used for Tx.
        Interrupt Mode: Enabled
        Operation Mode: TX and RX --> Normal
    *********************************************

  23. #2898
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,330
    @defragster
    Ok - after you hit "a" and send you should see something even if its only one message. If not then the odds are the pins are aligned right - I hope. As a check after you send "a" or "A" you can try resetting Node B but check the pins. Only other thing I can think of.

  24. #2899
    Any Ideas When this will be brought to market. Estimates? Yet this Year?

    Thanks for everyone doing all the work to make this happen!

  25. #2900
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,549
    Quote Originally Posted by bigboosted View Post
    Any Ideas When this will be brought to market. Estimates? Yet this Year?

    Thanks for everyone doing all the work to make this happen!
    Recent post this thread by Paul has PJRC status statement … IIRC Ideally before August … but TBD ...

Posting Permissions

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