Teensy 4.0 First Beta Test

Status
Not open for further replies.
FLEXCAN on Pins0/1

Doing some regression testing on the Flexcan sdk example I had working previously on CAN2 (this is not CAN-FD). This was running back in March timeframe. Now on the 1052 it seems to be hanging and on the 1062 nothing until I disconnect from the USB and then I see a message on the receiving T3.6:
Code:
*HEARTBEAT* 364471
MB 8  LEN: 8 EXT: 0 REMOTE: 0 TS: 27263 ID: 801 Buffer: 0 1 2 3 4 1 2 3 
*** MB 8  LEN: 8 EXT: 0 REMOTE: 0 TS: 27263 ID: 801 Buffer: 0 1 2 3 4 1 2 3 
*HEARTBEAT* 368494
*HEARTBEAT* 372834
*HEARTBEAT* 377174
*HEARTBEAT* 381514
*HEARTBEAT* 385854
*HEARTBEAT* 390079
MB 8  LEN: 8 EXT: 0 REMOTE: 0 TS: 50848 ID: 801 Buffer: 0 1 2 3 4 1 2 3 
*** MB 8  LEN: 8 EXT: 0 REMOTE: 0 TS: 50848 ID: 801 Buffer: 0 1 2 3 4 1 2 3
which is what I am suppose to see. But the funny thing is the CAN library that @tonton81 is developing works on both the 1052 and the 1062 without a problem. Going to do a little debugging to see what the issue is since it is probably the same issue affecting the CANFD sdk example. So if anyone has any ideas let me know.

EDIT: OK Found the problem - got the example sdk working minor problem - me being a dummy
 
Last edited:
Does anyone want to suggest alternates? Total PCB footprint width needs to be under 13 mm.
@Paul - this is a long shot, but maybe something like what we use for the other Surface mount pins? Except maybe the .05" version?
Maybe the single row version?

Something like: https://www.digikey.com/product-det...solutions/GRPB081VWTC-RC/S9011E-08-ND/1786403
It fits the 13mm, but probably take to much room in the other direction...

Also if went this type of route, question would be do you still need the voltage/gnd pins here or not?...

But probably the best answer is - Stay with what you have and SHIP IT!
 
I've committed the first code to implement Serial.available() and Serial.read().

https://github.com/PaulStoffregen/cores/commit/7e959d4a14ccfdaae13a7e5fa0d8cec244d44b22

This is still a work-in-progress. It's not efficient. Some functions like Serial.peek() and Serial.readBytes(buffer, len) are still not implemented. But at least basic reception on Serial should be working now.

Downloaded cores and copied over. Indeed this works:
Code:
  while ( Serial.available() ) {
    HW_SERIAL.print( (char)Serial.read() );
  }

Serial prints not guarded like this:
Code:
    [B]if ( Serial ) {[/B]
      Serial.print( " Loop Hz " );
      Serial.println( ii );
    }

Cause loop() to stall - but debug Serial4 continues to spew "status = 00090080" in that state so the processor is running.

So testing "if ( Serial )" works.

And Serial.print when !Serial stalls loop(), but continues when Serial returns.
 
@Paul - this is a long shot, but maybe something like what we use for the other Surface mount pins? Except maybe the .05" version?
Maybe the single row version?

Something like: https://www.digikey.com/product-det...solutions/GRPB081VWTC-RC/S9011E-08-ND/1786403
It fits the 13mm, but probably take to much room in the other direction...

Also if went this type of route, question would be do you still need the voltage/gnd pins here or not?...

But probably the best answer is - Stay with what you have and SHIP IT!

Expect SHIP IT is the best answer - unless perhaps another PCB REV is required.
But something like that - combined with the pads on the other end would allow bringing all those bottom side pads up over SMD components to a daughter board for use - without resorting to POGO or other things since mating a castellated board is out. And indeed seems it would be possible to drop GND and 3V3 pads from the array and have it work in that case bringing them from 'elsewhere'.
 
@Paul, I have a very big application - TeensyConvolutionSDR which needs more ITCM and more DTCM - any chance that you can inrease both? 256K for both would be fine, as a start..
 
I switched to TyComm for SerMon as it has a Serial 'On/Off' button without closing a window.

It is showing very good startup connect times of Serial:
T:\tCode\T4\BlinkMinNewUSB\BlinkMinNewUSB.ino Apr 28 2019 13:10:38
Setup First millis=305 // entered SETUP()
Serial First millis=392 // Serial online for use in 379 to 414 ms in a few trials.

This was just some old sketch modified :: T:\tCode\T4\BlinkMinNewUSB\BlinkMinNewUSB.ino

what this is printing is the number of passes through loop:
Loop Hz 11874357
>> NO SERIAL Loop Hz 11923986

That shows 11,874,357 when Serial is present
and taking Serial offline and skiping those prints to USB and only Serial4 gives 11,923,986

That is a LOT of passes through loop() !!!!!

Giving a void yield(){} ups the counts a bit:
Loop Hz 12446534
>> NO SERIAL Loop Hz 12498453

Adding this in that loop:
Code:
  digitalWriteFast( 13,1 );
  digitalWriteFast( 13,0 );

results in this while still sending the print strings:
Loop Hz 11639261
>> NO SERIAL Loop Hz 11686858

And change to digitalWrite() with a variable pin# drops to:
Loop Hz 7113010
>> NO SERIAL Loop Hz 7142074

For Comparison a T_3.6 at 240 MHz {need to unlock 256} gives there digitalWriteFast() with a constant in the above code including startup time from above:
Setup First millis=300
Serial First millis=365
Loop Hz 3478245
and digitalWrite() with var pin# is:
Setup First millis=300
Serial First millis=386
Loop Hz 1951228

And T_3.6 without the digitalWrite()'s :: Loop Hz 4000044 @240 Mhz
 
Cause loop() to stall - but debug Serial4 continues to spew "status = 00090080" in that state so the processor is running.

I am intentionally leaving this behavior until after I've worked out all the cases in the schedule_transfer() function (which was formerly named usb_transmit).

I know it's inconvenient. Please know I am aware, and the decision to leave this in for now it a very intentional choice on my part. The solution for working around when the PC side isn't listening tends to mask other issues, so fixing this behavior is pretty much the very last thing I intend to do on the USB code.
 
I am intentionally leaving this behavior until after I've worked out all the cases in the schedule_transfer() function (which was formerly named usb_transmit).

I know it's inconvenient. Please know I am aware, and the decision to leave this in for now it a very intentional choice on my part. The solution for working around when the PC side isn't listening tends to mask other issues, so fixing this behavior is pretty much the very last thing I intend to do on the USB code.

Understood, makes great sense - and excellent to know as it will be worthwhile incorporating into Beta sketches.

The best thing is "if(!Serial)" working and is an option to prevent the stalling.

Also thought showing the 'status' value presented might confirm something for you to be as expected.
 
11923986

Giving a void yield(){} ups the counts a bit:Loop Hz 12446534

that's not "a bit"

it's equivalent to 27MHz. How many UNOs are that? Assuming 8MHz/Uno, > 3 UNOs lost... Or do they use 16MHz? Dunno...

Edit: yield has to become faster. way faster. and without disabling interrupts 11923986/second.
Edit: We need to add a flag that tells us if there is any "event" pending and return immediately if not. 99.9999% of software would benefit. everything that does not use events.
Code:
void yield () {
if (!EventPending) return;
....
}
 
Last edited:
@Paul: are there any 'status =' values that worry you that we shouldn't ignore? When we are running debug out they get in the way so I keep doing the below to kill that line. And they intermix with Serial4 usage since it is connected.

@FrankB >> And has debug :: // if (count > 10) printf("status = %x\n", status);

8 bit Uno is 16 Mhz

Without the debug 'status' print and adding yield() back with :: digitalWriteFast( 13, !digitalReadFast( 13 ) );
I am seeing this many passes through loop() where it alternates between two with Serial on then stabilizes with !Serial::
Loop Hz 9019501
Loop Hz 9156013
>> NO SERIAL Loop Hz 9021564
>> NO SERIAL Loop Hz 9021562
>> NO SERIAL Loop Hz 9021564

@mjs513 - I got my 5 pack of encoders like yours - do you have a sample sketch you could put on github.com/mjs513/WIP ?
 
serialEvent() also not being called

Update link to here in Msg #6:
Not present is recurring call to delay() and normal Arduino loop() cycling::
Code:
// Normal T_3.x 
main() {
  setup();
  while(1){
    loop();
    delay();
  }
}
 
Last edited:
@Paul: are there any 'status =' values that worry you that we shouldn't ignore? When we are running debug out they get in the way so I keep doing the below to kill that line. And they intermix with Serial4 usage since it is connected.

@FrankB >> And has debug :: // if (count > 10) printf("status = %x\n", status);

8 bit Uno is 16 Mhz

Without the debug 'status' print and adding yield() back with :: digitalWriteFast( 13, !digitalReadFast( 13 ) );
I am seeing this many passes through loop() where it alternates between two with Serial on then stabilizes with !Serial::


@mjs513 - I got my 5 pack of encoders like yours - do you have a sample sketch you could put on github.com/mjs513/WIP ?

There were two sketches I used. The first is the basic encoder sketch from the Encoder library. + can go to 3.3v and the DT&Clk are your signals. The middle pin is actually a switch you can use. The sketch I tested with was the encoder sdk sketch which is already on GitHub. Here is one just for the fun of it:
Code:
/* Arduino New Rotary Encoder Pin states
Created by Yvan / https://Brainy-Bits.com
This code is in the public domain...
You can: copy it, use it, modify it, share it or just plain ignore it!
Thx!
*/

volatile boolean TurnDetected;  // need volatile for Interrupts

// Rotary Encoder Module connections
const int PinCLK=0;   // Generating interrupts using CLK signal
const int PinDT=1;    // Reading DT signal

// Interrupt routine runs if CLK pin changes state
void rotarydetect ()  {
  TurnDetected = true;  // set variable to true
}

void setup ()  {
  Serial.begin(2000000);  // high rate to assure good capture
  attachInterrupt (PinDT,rotarydetect,CHANGE); // interrupt 0 always connected to pin 2 on Arduino UNO
}

void loop ()  {
  if (TurnDetected)  { // rotary has been moved
      TurnDetected = false;  // do NOT repeat IF loop until new rotation detected 
      Serial.print("CLK Pin: ");
      Serial.println(digitalRead(PinCLK));
      Serial.print("DT Pin: ");
      Serial.println(digitalRead(PinDT));
      Serial.println();
      //delay(5);
  }
}
 
Left this running while out for lunch - Under 2 hours since last post - came back and computer USB CHIMES device OUT?? I wasn't doing anything ...
Code:
// https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=193998&viewfull=1#post193998
// https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=194174&viewfull=1#post194174

#define HW_SERIAL Serial4 // pin 17 debug Tx only

void yield() {}

uint32_t SFirstIn = 0;
uint32_t SFirst = 0;
uint32_t ii = 0;
elapsedMillis noDelay;
void setup() {
  SFirstIn = millis();
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite( LED_BUILTIN, HIGH );
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  HW_SERIAL.begin( 115200 );
  //Serial4.begin( 1843200 );
  HW_SERIAL.print( "   millis=" );
  HW_SERIAL.println( millis() );
  Serial.print( "   millis=" );
  Serial.println( millis() );
  while ( !Serial ) {
    Serial.println( millis() );
    ii++;
  }
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  Serial.println( millis() );
  SFirst = millis();
  Serial.print( "   Setup First millis=" );
  Serial.println( SFirstIn );
  Serial.print( "   Serial First millis=" );
  Serial.println( SFirst );
  Serial.print( "   while Count ii=" );
  Serial.println( ii );
  delayMicroseconds( 100 );
  ii = 0;
  noDelay = 0;
}

int x13 = 13;
bool flip = true;
bool unGuarded = false;
void loop() {
  ii++;
  //digitalWriteFast( x13,flip );
  //  digitalWriteFast( x13,1 );
  //  digitalWriteFast( x13,0 );
  //digitalWriteFast( 13, !digitalReadFast( 13 ) );
  if ( noDelay > 1000 ) {
    noDelay -= 1000;
    //digitalWrite( LED_BUILTIN, flip );
    flip = !flip;
    HW_SERIAL.print( " Loop Hz " );
    HW_SERIAL.println( ii );
    if ( Serial || unGuarded ) {
      Serial.print( " Loop Hz " );
      Serial.println( ii );
    }
    else {
      HW_SERIAL.print( " >> NO SERIAL " );
    }
    ii = 0;
  }
  if ( Serial.available() ) {
    unGuarded = !unGuarded;
    if ( unGuarded )
      HW_SERIAL.print( "\n\n UNGarded SERIAL " );
    else
      HW_SERIAL.print( "\n\n Garded SERIAL " );
    while ( Serial.available() ) {
      HW_SERIAL.print( (char)Serial.read() );
    }
  }
}

T42 not blinking ** - no data write on connected USB ... or the Serial4 as I was sharing it above.
<edit> ** - just noticed this code did not have and LED blink effect.

Debug Serial4 showed::
// ...
Loop Hz 12494027
Loop Hz 12494029
Loop Hz 12493965
Loop Hz 12496162
Loop Hz 12493834
usb_cdc_line_coding, baud=0
usb_cdc_line_coding, baud=115200
usb_cdc_line_coding, baud=115200
usb_cdc_line_coding, baud=115200

From USB I entered "66666" with TyComm and Serial4 showed this - I think the 115200 lines came along:
usb_cdc_line_coding, baud=115200
usb_cdc_line_coding, baud=115200
run_callbacks
rx event, len=6, i=0

Which shows USB got the five 6's and NewLine. Entering more text in TyComm gave: "[send@5794870-Teensy] I/O error while writing to '\\.\COM25'"

Code did not respond - no blink and no I/O USB or Serial4. And nothing since on Serial4/DEBUG.

I opened TLoader Verbose and here is the tail of that when I heard USB Chime and saw it was nto running:
Code:
15:57:33.359 (ports 5): callback C115
15:57:35.398 (ports 5): callback C115
15:57:36.561 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
15:57:36.562 (ports 5): nothing new, skipping HID & Ports enum
15:57:37.414 (ports 5): callback C115
15:57:39.392 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
15:57:39.393 (ports 5): nothing new, skipping HID & Ports enum
15:57:39.422 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
15:57:39.423 (ports 5): nothing new, skipping HID & Ports enum
15:57:39.437 (ports 5): callback C115
15:57:41.467 (ports 5): callback C115
15:57:43.487 (ports 5): callback C115

16:12:32.870 (ports 5): callback C115
16:12:34.889 (ports 5): callback C115
16:12:36.909 (ports 5): callback C115
16:12:38.929 (ports 5): callback C115
16:12:39.751 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
16:12:39.752 (ports 5): nothing new, skipping HID & Ports enum
16:12:40.022 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
16:12:40.023 (ports 5): nothing new, skipping HID & Ports enum
16:12:40.038 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
16:12:40.039 (ports 5): nothing new, skipping HID & Ports enum
16:12:40.058 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
16:12:40.059 (ports 5): nothing new, skipping HID & Ports enum
16:12:40.944 (ports 5): callback C115
16:12:42.559 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
16:12:42.560 (ports 5): nothing new, skipping HID & Ports enum
16:12:42.577 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
16:12:42.578 (ports 5): nothing new, skipping HID & Ports enum
16:12:42.967 (ports 5): callback C115
16:12:44.992 (ports 5): callback C115
16:12:47.013 (ports 5): callback C115

16:27:37.930 (ports 5): callback C115
16:27:39.955 (ports 5): callback C115
16:27:41.981 (ports 5): callback C115
16:27:42.856 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
16:27:42.857 (ports 5): nothing new, skipping HID & Ports enum
16:27:44.011 (ports 5): callback C115
16:27:44.415 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
16:27:44.415 (ports 5): nothing new, skipping HID & Ports enum
16:27:44.430 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
16:27:44.431 (ports 5): nothing new, skipping HID & Ports enum
16:27:46.027 (ports 5): callback C115
16:27:48.045 (ports 5): callback C115

16:42:41.940 (ports 5): callback C115
16:42:43.968 (ports 5): callback C115
16:42:45.960 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
16:42:45.961 (ports 5): nothing new, skipping HID & Ports enum
16:42:46.000 (ports 5): callback C115
16:42:48.029 (ports 5): callback C115
16:42:48.302 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
16:42:48.303 (ports 5): nothing new, skipping HID & Ports enum
16:42:48.318 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
16:42:48.319 (ports 5): nothing new, skipping HID & Ports enum
16:42:50.055 (ports 5): callback C115
16:42:52.079 (ports 5): callback C115
16:57:43.375 (ports 5): callback C115
16:57:45.395 (ports 5): callback C115
16:57:46.119 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
16:57:46.120 (ports 5): nothing new, skipping HID & Ports enum
16:57:47.416 (ports 5): callback C115
16:57:47.468 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
16:57:47.469 (ports 5): nothing new, skipping HID & Ports enum
16:57:47.482 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
16:57:47.483 (ports 5): nothing new, skipping HID & Ports enum
16:57:49.457 (ports 5): callback C115
16:57:51.467 (ports 5): callback C115
16:57:53.494 (ports 5): callback C115
17:01:39.686 (ports 5): callback C115
17:01:41.705 (ports 5): callback C115
17:01:43.536 (ports 5): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
17:01:43.537 (ports 5): remove: loc=usb:0/140000/0/8/7
17:01:43.537 (ports 5): usb_remove: usb:0/140000/0/8/7
17:01:43.537 (ports 5): remove: loc=usb:0/140000/0/8/1
17:01:43.537 (ports 5): usb_remove: usb:0/140000/0/8/1
17:01:43.537 (ports 5): nothing new, skipping HID & Ports enum
17:01:43.537 (ports 5): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
17:01:43.538 (ports 5): nothing new, skipping HID & Ports enum
17:01:43.547 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
17:01:43.548 (ports 5): nothing new, skipping HID & Ports enum
17:01:43.554 (ports 5): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
17:01:43.554 (ports 5): nothing new, skipping HID & Ports enum
17:01:43.745 (ports 5): callback C115
17:01:43.745 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
17:01:43.745 (ports 5): nothing new, skipping HID & Ports enum
17:01:43.968 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
17:01:43.968 (ports 5): nothing new, skipping HID & Ports enum
17:01:44.172 (ports 5): WM_DEVICECHANGE DBT_DEVICEARRIVAL
17:01:44.174 (ports 5): found_usb_device, id=\\?\usb#vid_16c0&pid_0483#863660#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
17:01:44.174 (ports 5): found_usb_device, loc=usb:0/140000/0/8/1    Port_#0001.Hub_#0009
17:01:44.174 (ports 5): found_usb_device, hwid=USB\VID_16C0&PID_0483&REV_0275
17:01:44.174 (ports 5): found_usb_device, devinst=00000005
17:01:44.174 (ports 5): add: loc=usb:0/140000/0/8/1, class=Ports, vid=16C0, pid=0483, ver=0275, serial=863660, dev=\\?\usb#vid_16c0&pid_0483#863660#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
17:01:44.174 (ports 5):   comport_from_devinst_list attempt
17:01:44.174 (ports 5):   found Ports in classguid_list at index=0
17:01:44.174 (ports 5):   port COM19 found from devnode
17:01:44.174 (ports 5): found_usb_device complete
17:01:44.175 (ports 5): usb_add: usb:0/140000/0/8/1  COM19 (Teensy 3.2) Serial
17:01:44.181 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
17:01:44.181 (ports 5): nothing new, skipping HID & Ports enum
17:01:44.187 (ports 5): WM_DEVICECHANGE DBT_DEVICEARRIVAL
17:01:44.188 (ports 5): nothing new, skipping HID & Ports enum
17:01:44.214 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
17:01:44.215 (ports 5): nothing new, skipping HID & Ports enum
17:01:44.238 (ports 5): WM_DEVICECHANGE DBT_DEVICEARRIVAL
17:01:44.239 (ports 5): found_usb_device, id=\\?\usb#vid_16c0&pid_0483#5794870#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
17:01:44.239 (ports 5): found_usb_device, loc=usb:0/140000/0/8/7    Port_#0007.Hub_#0009
17:01:44.239 (ports 5): found_usb_device, hwid=USB\VID_16C0&PID_0483&REV_0279
17:01:44.239 (ports 5): found_usb_device, devinst=00000022
17:01:44.239 (ports 5): add: loc=usb:0/140000/0/8/7, class=Ports, vid=16C0, pid=0483, ver=0279, serial=5794870, dev=\\?\usb#vid_16c0&pid_0483#5794870#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
17:01:44.239 (ports 5):   comport_from_devinst_list attempt
17:01:44.239 (ports 5):   found Ports in classguid_list at index=0
17:01:44.239 (ports 5):   port COM25 found from devnode
17:01:44.239 (ports 5): found_usb_device complete
17:01:44.241 (ports 5): usb_add: usb:0/140000/0/8/7  COM25 (Teensy 4-Beta2) Serial
17:01:44.271 (ports 5): WM_DEVICECHANGE DBT_DEVICEARRIVAL
17:01:44.272 (ports 5): nothing new, skipping HID & Ports enum
17:01:44.463 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
17:01:44.464 (ports 5): nothing new, skipping HID & Ports enum
17:01:45.771 (ports 5): callback C115


These '17:01:45.771 (ports 5): callback C115' in verbose really clutter and make TLoader Verbose hard to use.

For the above here is TyComm's untime stamped notes on USB Event:
Code:
Examining device node 'USB\VID_16C0&PID_0483\5794870'
Found port number of 'USB\VID_16C0&PID_0483\5794870': 7
Found port number of 'USB\VID_1A40&PID_0201\5&38BA1A52&0&8': 8
Found controller ID for 'USB\ROOT_HUB30\4&362721B3&0&0': 1
Add serial device 'USB\VID_16C0&PID_0483\5794870' on iface 0
  - USB VID/PID = 16c0:0483, USB location = usb-1-8-7
  - USB manufacturer = Teensyduino, product = USB Serial, S/N = 5794870
Unknown Teensy model with bcdDevice value 0x279
Received arrival notification for device 'USB\VID_16C0&PID_0483\5794870'
Examining device node 'USB\VID_16C0&PID_0483\5794870'
Found port number of 'USB\VID_16C0&PID_0483\5794870': 7
Found port number of 'USB\VID_1A40&PID_0201\5&38BA1A52&0&8': 8
Found controller ID for 'USB\ROOT_HUB30\4&362721B3&0&0': 1
Received removal notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Received removal notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Received removal notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Received arrival notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Examining device node 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Unknown device type for 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Received arrival notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Examining device node 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Unknown device type for 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Received arrival notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Examining device node 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Unknown device type for 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
[send@5794870-Teensy] I/O error while writing to '\\.\COM25'
Received removal notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Received removal notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Received removal notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Received arrival notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Examining device node 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Unknown device type for 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Received arrival notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Examining device node 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Unknown device type for 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Received arrival notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Examining device node 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
Unknown device type for 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'

Pushed Button and code reloaded and TyComm picked up running like this - no "status ="
Code:
usb_cdc_line_coding, baud=115200
run_callbacks
rx event, len=6, i=0

***********IMXRT Startup**********
test 1 -1234567 3
CCM_ANALOG_PLL_USB1=80003000
  enable USB clocks
CCM_ANALOG_PLL_USB1=80003040
Increasing voltage to 1250 mV
need to switch to alternate clock during reconfigure of ARM PLL
USB PLL is running, so we can use 120 MHz
Freq: 12 MHz * 100 / 2 / 1
ARM PLL=80002042
ARM PLL needs reconfigure
ARM PLL=80002064
New Frequency: ARM=600000000, IPG=150000000
USB reset took 3 loops
analogInit
usb_serial_reset
usb_serial_configure
usb_cdc_line_coding, baud=0
before C++ constructors
after C++ constructors
before setup
   millis=340
usb_cdc_line_coding, baud=0
usb_cdc_line_coding, baud=115200
usb_cdc_line_coding, baud=115200
after setup
 Loop Hz 12491217
 
Last edited:
@Paul: are there any 'status =' values that worry you that we shouldn't ignore?

Good question. I really don't have a conclusive answer at this time. But I can tell you I'm working on the USB stuff now.

One thing is absolutely clear: there just aren't clear answers yet. NXP's documentation had the wrong definition for USBCMD ATDTW until the latest rev (and appears to have been wrong for ~5 years on prior chips), and version 2.5.0 of their SDK has it defined according to the wrong docs. I also have some serious doubts about the "case 2" process on page 2468 of the latest manual and seems to be followed by NXP's code, documenting how to use ATDTW. The semaphore is only used to guard access to the ENDPTSTAT, not the earlier write to the transfer descriptor. What happens if the EHCI fetches the next TD between steps 1-3?

Another big unknown is whether polling the QH or TD structures can work at all. All the docs and examples are based on keeping a separate linked list, requiring one interrupt per TD to maintain linked lists separate from the EHCI structs. I'm hoping to avoid all that extra overhead for transmitting.

So how exactly the interpret those status bits is still not 100% clear to me. As you can see in the early code, I had to use some pretty kludgey delays.
 
Let me know - turning them off could miss something … I suppose I'll bring them back if they can help - and move user debug to Serial and Serial1 like before with another Teensy - and then just understand T4 won't cold start with them active.

Also if you see anything in the post #2563 that helps get to whatever halted …

I'll leave that code and add in encoders ...
 
Paul - you noted you are working on USB - anything specific to test that would help find or resolve concerns?

The TRIO stopped again once - my hand was near the breakout Serial wires ... nothing interesting on the Sermon(s). I've been hearing the Windows USB OUT chime at times when my computer has sound on - but never clear what changed. Serial4 on T_3.1 with status back on.

TyComm can do a Send File - I have a 900KB TLoader verbose.log from above. Works sending in and out T4 USB - through T_3.5 on Serial2 … so Serial2 @ 2Mbps working too.

> Can send that with USB out Serial1 debug @2Mbps T_3.5 to T4 Serial2 @2Mbps out USB with T4 - and it works with readBytes() - was lossy with read().
Code:
  if ( Serial2.available() ) {
    char rdBuff[1025];
    int ii;
    while ( ii = Serial2.available() ) {
      if ( ii > 1024 )ii = 1024;
      Serial2.readBytes( rdBuff, ii);
      rdBuff[ii] = 0;
      Serial.print( rdBuff );
    }
  }

> Can send that with USB out Serial2 debug @2Mbps T4 to T_3.5 that then send out USB from T_3.5 - and it works with read()
Code:
  if ( Serial.available() ) {
    while ( Serial.available() ) {
      HW_SERIAL.print( (char)Serial.read() );
    }
  }

Added Encoder code from @mjs513 - and put Bounce on the button and that works.
 
anything specific to test that would help find or resolve concerns?

Yeah, but hard to say exactly what to test or how.

Long ago, there was a thread about sending a huge amount of pseudo-random data in both directions and verifying a checksum after several megabytes. Any maybe measuring the speed along the way. Was going to try to recreate that. If anyone wants to give it a try, please jump in and write a little code on both sides. Otherwise, I'll probably do it in a day or two....
 
@KurtE did some good tests of data integrity for Serial#. Quick search didn't find note on pseudorandom.

I walked away and returned - I want to say I touched nothing - Win USB Chime away - TyCommander shows three Teeny Running Teensy : T4, T_3.1 on Serial4 debug @115Kb, T_3.5 on Serial2 @2Mb for sketch debug/output.

Send from TyComm Sermon to T4 ignored.

I hooked into the Encoder interrupt as presented by @mjs513 to toggle a pin tied to T_3.5 and rotating the knob still isr() still triggering and seen by the T_3.5, but all else stalled and appears frozen. Encoder and encoder button click report in loop() and they are silent link the 1 second LED toggle and loop() Hz.

Paul: Is there anything I could do in that interrupt to ping the USB system? I'll see if PJRC debug Serial4 output works from there.


T4 is spewing the last line - caught the buffer spot where that started - the 90080 is overwhelming the output as printing:
Code:
status = 00090080
status = 00090080
status = 00090080
status = 00090080
status =usb_cdc_line_coding, baud=0
 00090080
status = 00090080
status = 00090080
status = 00090080
status = 00090usb_cdc_line_coding, baud=115200
080
status = 00090080
status = 00090080
status = 00090080
status = 00090080
statuusb_cdc_line_coding, baud=115200
s = 00090080
status = 00090080
status = 00090080
status = 00090080
status = 00090080

<edit>Will this safely reduce the "status =" spew rate?
Code:
		if (count > 10) {
			printf("status = %x\n", status);
			count = 0;
		}

Here is a save of the TeensyLoader Verbose at that point 780KB then zipped::

Only new entries since the save is this unpromted:
00:44:09.213 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
00:44:09.214 (ports 5): nothing new, skipping HID & Ports enum
00:44:09.306 (ports 5): callback C115
00:44:09.650 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
00:44:09.651 (ports 5): nothing new, skipping HID & Ports enum
00:44:09.670 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
00:44:09.671 (ports 5): nothing new, skipping HID & Ports enum
00:44:11.325 (ports 5): callback C115
00:44:13.348 (ports 5): callback C115
00:44:15.379 (ports 5): callback C115
00:44:17.402 (ports 5): callback C115
 
I walked up the hall and back in my dry house - wearing a cashmere sweater, did not pet the cat - came to computer and waved my hand over the Teensy on my monitor stand and :: status = 001E0080

That is all that is printing - repeatedly - at an extreme rate. I repeated this twice more with no effect.

Other loop() activity stopped - encoder pin interrupt still working to toggle the bit to debug T_3.5, and now sending this out Serial4 to T_3.1 :: printf_debug( "\n~~\n" );

I am seeing spurious output from the encoder interrupt firing?

I did this to compress the "status =" messages:
Code:
	int count=0;
	static int ccnt = 0;
	//digitalWriteFast(13, HIGH);
	while (1) {
		uint32_t status = txtransfer.status;
		if (count > 10) {
			ccnt++;
			if ( 0x00070080 == status )
				printf("7*");
			else if ( 0x00090080 == status )
				printf("9*");
			else if ( 0x001E0080 == status )
				printf("1E*");
			else if ( 0x00010080 == status )
				printf("1*");
			else if ( 0 == status )
				printf("0*");
			else  {
				printf("\nstatus = %x\t", status);
				ccnt=0;
			}
			if (ccnt > 32) {
				printf("\nst=");
				ccnt=0;
			}
		}

Results look like this:
status = 00030080 0*0*after setup
7*7*0*7*0*7*7*0*7*7*0*7*7*0*7*7*0*7*7*0*7*7*0*0*7*7*0*7*7*0*7*
st=0*7*7*0*7*7*0*7*7*0*7*7*0*7*7*7*0*7*7*0*7*7*0*
status = 000F0080 0*
status = 00010080 0*0*
status = 000F0080 0*0*7*7*7*0*7*7*7*0*7*7*7*0*7*7*7*0*7*7*7*0*7*7*7*0*7*7*7*0*7*7*7*
st=0*7*7*7*7*0*7*7*7*7*0*7*7*0*7*7*0*7*7*7*7*0*7*7*7*7*0*7*7*7*0*7*7*
st=0*7*7*0*7*7*7*7*0*7*7*7*7*0*7*7*7*7*0*7*7*7*0*
status = 000F0080 0*
status = 000F0080 0*0*7*7*7*7*0*7*7*7*7*0*7*7*7*7*0*
~~ // Here is the untouched encoder indication - funny because it didn't have same associated status
9*9*9*0*9*9*0*7*7*0*7*7*0*7*7*7*

<edit> Adding this - no signs of errors or issues:
Sending encoder message 'on purpose' made a lot of noise too so I added 1*:
~~
1*1*0*1*0*1*1*
st=0*1*0*9*0*1*1*0*1*1*1*0*1*0*1*1*1*0*0*9*0*9*0*1*1*1*0*1*0*1*1*0*1*
st=0*0*9*0*1*1*0*1*0*9*0*1*1*1*0*0*1*1*1*0*1*0*9*9*0*1*0*1*1*1*0*1*0*
st=9*0*9*0*0*1*0*1*1*0*1*0*9*0*0*1*1*1*0*1*0*9*0*9*0*1*1*0*1*0*1*1*0*
st=1*1*0*0*1*1*0*1*0*9*0*9*0*1*1*0*1*0*1*1*0*1*0*1*1*1*0*0*0*9*0*1*1*
st=0*1*0*0*1*0*1*1*1*0*1*0*9*0*9*0*0*1*0*7*7*0*
~~
9*0*1*1*0*1*1*0*1*1*0*
st=1*0*1*0*1*1*0*0*0*9*0*9*9*0*9*9*0*0*1*0*1*0*1*0*1*0*0*1*0*0*1*1*1*
st=0*1*0*9*9*0*
 
T4 is spewing the last line - caught the buffer spot where that started - the 90080 is overwhelming the output as printing:

I'm working on the transfer descriptor status problems now. Turns out USBCMD ATDTW is looking like the proper answer. Those delays I put in the code don't always work, and even when they do they're a pretty terrible kludge.

NXP's rather scant documentation about ATDTW isn't very helpful. I'm pretty sure whoever wrote "41.5.6.6.3 Executing A Transfer Descriptor" on page 2468 (RT1060 ref manual, rev 1, 12/2018) had absolutely no idea how ATDTW really works, so they just documented what's in the SDK code. I have serious doubts that code is really correct, but probably works out due to the timing of how the USB controller generates interrupts and the ARM core responds.

On the next page, "41.5.6.6.4 Transfer Completion" makes absolutely no mention of ATDTW. It says "or alternately, the DCD can poll the endpoint complete register to find when the dTD had been executed". That's exactly what the code does now. Indeed we are getting wrong info in some cases. The "spew" also is correct behavior in other cases. USB is complicated....

In my dream world, I'd be able to connect a very high speed logic analyzer to the ATDTW signal deep inside the chip, and also watch the 600 MHz bus - or at least some signals about bus arbitration to get an idea when the USB controller is reading & writing the QH and TD structs. But sadly, the only way to learn is writing little functions that capture simple stats while working with the registers, and then print the info after the fact. This stuff all happens on very short time scales, only a few iterations of a loop which does a few register reads is able to run before it's all over. Pretty hard to see what's really going on.

My best guesswork on ATDTW is the USB controller forces it low during certain operations that access the TD and maybe also the QH struct. During that time, which appears to be only about 10 to 50 ns, you can't change it. Writes seem to be ignored, so it stays low for the duration of some internal operation. After the operation is over, ATDTW becomes writable again. So far, I've never observed a case where it was low and then when I was able to set it high, the TD still had its active bit set. Not sure if that means it's only low when the TD is written back? I've only been testing with small transfers which requires a single USB packet. Might try some longer tests later and see if I can craft code that observes the QH update, and see if ATDTW low correlates with those moments or only when the TD is written with the final result.

I took out the delays and rearranged stuff to make the TD status read problems *much* worse. I can usually get it to go very wrong only milliseconds after USB enumeration completes. I started using ATDTW to retry reading the TD status (not the ENDPTSTATUS register as documented on page 2468) and it does indeed seem to fix the problem. I've had that code which crashes within milliseconds after enumeration running successfully for a couple hours and still going. Going to commit that (and the process from page 2468 - though I'm deeply suspicious it's not fully correct) to github now.
 
Ok, I've committed the code. This is still very much a work in progress... and trying to reverse engineer how to really use ATDTW....

https://github.com/PaulStoffregen/cores/commit/57bc3456bac2809e1d1448a59f81959acf863f95

Just to be clear, you absolutely should expect to see "spew" like this on Serial4 in two cases.

status = 0###0080
status = 0###0080
status = 0###0080

Where "###" varies depending on how much data Teensy wants to send to your PC, but can't. There are 2 valid reasons why this could happen:

1: If you close (or never open) the Arduino Serial Monitor, then no driver on your PC is sending USB IN tokens which allow Teensy to transmit data. In that case, you should see this message print as rapidly as the Serial4 baud rate allows. There is currently no timeout built into usb_serial_write(), which means your Arduino sketch will hang forever in Serial.print() - or at least "forever" until your PC starts sending USB IN tokens.

2: If Teensy sends data faster than your PC can accept it, the driver on your PC will cause your motherboard's USB controller to stop sending IN tokens, until it has buffers available to accept Teensy's data. This is normal and correct flow control which is fundamentally built into the USB protocol. When you see this happen, each PC-not-ready event should have 1 or more "status = 0###0080" messages and 1 "status = 00000000", meaning your PC became ready for more data.

Something that should definitely *NOT* happen is Teensy failing to print to the serial monitor while it's still open, and a never-ending stream of "status = 0###0080" (or any other message) on Serial4 when data should be flowing.

Just remember, when your PC isn't listening or isn't able to handle the incoming speed, you *ARE* supposed to see those status messages "spew" to Serial4. That is absolutely normal and correct if your PC isn't ready to receive.

Eventually I will put a timeout into usb_serial_write(), as we have on all other Teensy models, so printing won't stall your program if the PC isn't listening. But that code tends to mask these sorts of problems, so I'm not putting the timeout into the code until I'm sure this status stuff really is working.
 
Downloading and will start it up on my busy sketch to run the next few hours. Then I'll come back and finish reading the above like it makes perfect sense.

I do expect spew - just trying to minimize the impact of stuff getting buried in screen after screen and putting filler between the events or hiding patterns.
 
My sketch up and running - way less debug spew :cool: - basically none unless as noted [#1] drop the Serial connect on Sermon {tycomm} and try to Serial.print. Turning the encoder knob gets an intermittent couple on occasion, but that is on isr() out debug serial while other code is doing its thing.
~~
~~
status = 00010080
status = 00000000
~~
status = 00010080
status = 00000000
~~
~~
status = 00010080
status = 00000000
status = 00010080
status = 00000000
~~
~~

I've got a feeling the only breaks I caught were from static charge or such proximity to my wire loops with 3 Teensy connected by Rx/Tx/Gnd and the 5 added encoder wires to breadboard. Very odd though 'only' loop seemed to be stopped.

Did a quick search of ATDTW so I'd at least know the words behind the TLA - found the Dec 2018 NXP.forum post where recent 5 years of manuals [and SDK's] declared it as bit 12 when it is and always has been - as prior manuals declared at bit 14 … not nice. I then saw you were using #14.

Yes 12Mbps or pushing to 400 doesn't happen slowly or leave much time for poking around … I hear sipping from a firehose is similarly problematic.

Using TyComm to send that 900kb file over USB to T4 works - in 10-11 seconds - though I only visually see it looking right. And pushing it to T_3.5 to send over Serial2 @2Mbps for resend out T4 USB also 'looks' decent - and causes no notes on writing and only a stream of these on reading:
run_callbacks
rx event, len=512, i=0
run_callbacks
rx event, len=512, i=0
 
Paul - I just did a 15s Restore on my T4-2 as I found I had Win SDK USBview.exe installed.

Hopefully this will show you some fixable difference. CodeCompare shows the names confused: usbViewNames.jpg

Highlighted some of the DIFFS...

After the Restore this is what it tells me about the T4-2:
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

[COLOR="#FF0000"]Device Power State:               PowerDeviceD3[/COLOR]

       ---===>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:                    0x32
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
[COLOR="#FF0000"]String Descriptor for index 1 not available while device is in low power state.
iProduct:                          0x02
     English (United States)  "Teens?????????????"[/COLOR]
iSerialNumber:                     0x03
     English (United States)  "5794870"
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

When TeensyLoader uploads the provided minimal.hex is then shows this:
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

[B]Device Power State:               PowerDeviceD0[/B]

       ---===>Device Information<===---
[B]English product name: "Teensyduino RawHID"[/B]

ConnectionStatus:                  
Current Config Value:              0x01  -> Device Bus Speed: High (is not SuperSpeed or higher capable)
Device Address:                    0x38
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
[B]     English (United States)  "Teensyduino"
iProduct:                          0x02
     English (United States)  "Teensyduino RawHID"[/B]
iSerialNumber:                     0x03
     English (United States)  "5794870"
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
 
Yes 12Mbps or pushing to 400 doesn't happen slowly or leave much time for poking around

I started doing some benchmarking. There's no optimization at all so far. The USB Serial.print() throughput is dismal, about 1/3rd the speed of Teensy 3.6. I tested several boards and was quite surprised how very slow Arduino's products are with native USB, especially Arduino Zero and MKR1000. Arduino Due is the only one with decent performance, just slightly faster than T4 is at this moment.

Going to start working on optimizations next...
 
Status
Not open for further replies.
Back
Top