Teensy 4.0 First Beta Test

Status
Not open for further replies.
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:
@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:
@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, [COLOR="#FF0000"]serial=5847860[/COLOR], 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<===---
[COLOR="#FF0000"]English product name: "Teens?????????????"[/COLOR]

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)  "[COLOR="#FF0000"]Teens?????????????[/COLOR]"
iSerialNumber:                     0x03
     English (United States)  "[COLOR="#FF0000"]5847860[/COLOR]"
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
[COLOR="#FF0000"]idVendor:                        0x1FC9 = NXP Semiconductors[/COLOR]
idProduct:                       0x0135
bcdDevice:                       0x0101
iManufacturer:                     0x01
     English (United States)  "NXP      SemiConductors Inc "
iProduct:                          0x02
     [COLOR="#FF0000"]English (United States)  "SE Blank RT Family "[/COLOR]
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)  "[COLOR="#FF0000"]Teensyduino[/COLOR]"
iProduct:                          0x02
     English (United States)  "USB Serial"
iSerialNumber:                     0x03
     English (United States)  "[COLOR="#FF0000"]2114150[/COLOR]"
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:
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.
 
@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?
 
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.
 
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?
 
@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 :)
 
@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?
 
@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.
 
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.
 
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.
 
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
 
@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:
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.
 

Attachments

  • Flexcan_t4.zip
    76.7 KB · Views: 74
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.
 
@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.
 
@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:
@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.
 
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 :)
 
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
*********************************************
 
@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.
 
Any Ideas When this will be brought to market. Estimates? Yet this Year?

Thanks for everyone doing all the work to make this happen!
 
Status
Not open for further replies.
Back
Top