Teensy 4.0 First Beta Test

Status
Not open for further replies.
My current stuff is up on github: https://github.com/KurtE/USBHost_t36/tree/WIP2-Bluetooth

I have tried it with one of the dongles and the screwy keyboard: https://www.amazon.com/gp/product/B00JO80LVW

Took a bit of time, and experimenting, but I had it talking for awhile :D

I turned on the Pairing code, then run it... Then turned on keyboard, hit BT button, then typed 0000<enter>
As that was the key that was part of the code..

Then it paired and I am able to type in a few things...

Here is complete debug: output with verbose output turned on.
….

As you can see at the end there are keyboard data... There is also data returned for pad area, not sure I am processing any of it...

But at least some of it looks like it is limping along
Since I didn't have a BT keyboard I tried it with your merged version except using a PS4 controller that I know works wired or with USB Host Shield 2.0. I get as far as it identifying the hub and the adapter and "claiming" both the Joystick and the Bluetooth. But no data. Need to ask - to go into verbose mode just have to have the 2 defines uncommented?
Code:
USB Host Testing
960
USB2 PLL running
 reset waited 5
USBHS_ASYNCLISTADDR = 0
USBHS_PERIODICLISTBASE = 20006000
periodictable = 20006000
port change: 10001803
    connect
  begin reset
port change: 18001205
  port enabled
  end recovery
new_Device: 480 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
Device Descriptor:
  12 01 00 02 09 00 01 40 E3 05 08 06 02 07 00 01 00 01 
    VendorID = 05E3, ProductID = 0608, Version = 0702
    Class/Subclass/Protocol = 9(Hub) / 0 / 1(Single-TT)
    Number of Configurations = 1
enumeration:
enumeration:
Product: USB2.0 Hub
enumeration:
Config data length = 25
enumeration:
Configuration Descriptor:
  09 02 19 00 01 01 00 E0 32 
    NumInterfaces = 1
    ConfigurationValue = 1
  09 04 00 00 01 09 00 00 00 
    Interface = 0
    Number of endpoints = 1
    Class/Subclass/Protocol = 9(Hub) / 0 / 0
  07 05 81 03 01 00 0C 
    Endpoint = 1 IN
    Type = Interrupt
    Max Size = 1
    Polling Interval = 12
enumeration:
USBHub memory usage = 960
USBHub claim_device this=20002A00
found possible interface, altsetting=0
number of interfaces found = 1
*** Device Hub1 5e3:608 - connected ***
  product: USB2.0 Hub
USBHub control callback
09 29 04 E0 00 32 64 00 FF 00 00 00 00 00 00 00 
Hub ports = 4
USBHub control callback
USBHub control callback
USBHub control callback
USBHub control callback
power turned on to all ports
device addr = 1
new_Pipe
allocate_interrupt_pipe_bandwidth
  ep interval = 12
  interval = 256
 best_bandwidth = 2, at offset = 0
pipe cap1 = F0012101
HUB Callback (member)
status = 10
getstatus, port = 4
USBHub control callback
01 01 01 00 
New Port Status
  status=10101  port=4
  state=0
  Device is present: 
  Has Power
USBHub control callback
Port Status Cleared, port=4
timer event (19999 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 10
getstatus, port = 4
USBHub control callback
01 01 00 00 
New Port Status
  status=101  port=4
  state=2
  Device is present: 
  Has Power
timer event (20000 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 10
getstatus, port = 4
USBHub control callback
01 01 00 00 
New Port Status
  status=101  port=4
  state=3
  Device is present: 
  Has Power
timer event (19999 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 10
getstatus, port = 4
USBHub control callback
01 01 00 00 
New Port Status
  status=101  port=4
  state=4
  Device is present: 
  Has Power
timer event (22031 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 10
getstatus, port = 4
USBHub control callback
01 01 00 00 
New Port Status
  status=101  port=4
  state=5
  Device is present: 
  Has Power
timer event (31619 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 10
getstatus, port = 4
USBHub control callback
01 01 00 00 
New Port Status
  status=101  port=4
  state=6
  Device is present: 
  Has Power
sending reset
send_setreset
timer event (33684 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 0
USBHub control callback
unhandled setup, message = 40323
HUB Callback (member)
status = 10
getstatus, port = 4
USBHub control callback
03 01 10 00 
New Port Status
  status=100103  port=4
  state=7
  Device is present: 
  Enabled, speed = 12 Mbit/sec
  Has Power
HUB Callback (member)
status = 10
deferred getstatus, port = 4
USBHub control callback
unhandled setup, message = 140123
getstatus, port = 4
USBHub control callback
03 01 00 00 
New Port Status
  status=103  port=4
  state=8
  Device is present: 
  Enabled, speed = 12 Mbit/sec
  Has Power
timer event (51658 us): Hello, I'm resettimer, this = 20002A00, timer = 20002D34
port_doing_reset = 4
PORT_RECOVERY
new_Device: 12 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
Device Descriptor:
  12 01 00 02 FF 01 01 40 5C 0A E8 21 12 01 01 02 03 01 
    VendorID = 0A5C, ProductID = 21E8, Version = 0112
    Class/Subclass/Protocol = 255 / 1 / 1
    Number of Configurations = 1
enumeration:
enumeration:
Manufacturer: Broadcom Corp
enumeration:
Product: BCM20702A0
enumeration:
Serial Number: 5CF3707A1CC9
enumeration:
Config data length = 218
enumeration:
Configuration Descriptor:
  09 02 DA 00 04 01 00 E0 00 
    NumInterfaces = 4
    ConfigurationValue = 1
  09 04 00 00 03 FF 01 01 00 
    Interface = 0
    Number of endpoints = 3
    Class/Subclass/Protocol = 255 / 1 / 1
  07 05 81 03 10 00 01 
    Endpoint = 1 IN
    Type = Interrupt
    Max Size = 16
    Polling Interval = 1
  07 05 82 02 40 00 01 
    Endpoint = 2 IN
    Type = Bulk
    Max Size = 64
    Polling Interval = 1
  07 05 02 02 40 00 01 
    Endpoint = 2 OUT
    Type = Bulk
    Max Size = 64
    Polling Interval = 1
  09 04 01 00 02 FF 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 255 / 1 / 1
  07 05 83 01 00 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 0
    Polling Interval = 1
  07 05 03 01 00 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 0
    Polling Interval = 1
  09 04 01 01 02 FF 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 255 / 1 / 1
  07 05 83 01 09 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 9
    Polling Interval = 1
  07 05 03 01 09 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 9
    Polling Interval = 1
  09 04 01 02 02 FF 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 255 / 1 / 1
  07 05 83 01 11 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 17
    Polling Interval = 1
  07 05 03 01 11 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 17
    Polling Interval = 1
  09 04 01 03 02 FF 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 255 / 1 / 1
  07 05 83 01 19 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 25
    Polling Interval = 1
  07 05 03 01 19 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 25
    Polling Interval = 1
  09 04 01 04 02 FF 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 255 / 1 / 1
  07 05 83 01 21 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 33
    Polling Interval = 1
  07 05 03 01 21 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 33
    Polling Interval = 1
  09 04 01 05 02 FF 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 255 / 1 / 1
  07 05 83 01 31 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 49
    Polling Interval = 1
  07 05 03 01 31 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 49
    Polling Interval = 1
  09 04 02 00 02 FF FF FF 00 
    Interface = 2
    Number of endpoints = 2
    Class/Subclass/Protocol = 255 / 255 / 255
  07 05 84 02 20 00 01 
    Endpoint = 4 IN
    Type = Bulk
    Max Size = 32
    Polling Interval = 1
  07 05 04 02 20 00 01 
    Endpoint = 4 OUT
    Type = Bulk
    Max Size = 32
    Polling Interval = 1
  09 04 03 00 00 FE 01 01 00 
    Interface = 3
    Number of endpoints = 0
    Class/Subclass/Protocol = 254 / 1 / 1
  09 21 05 88 13 40 00 10 01 
    HID, 64 report descriptors
enumeration:
USBHub memory usage = 960
USBHub claim_device this=20002DC0
HIDParser claim this=200031A0
HIDParser claim this=200036A0
HIDParser claim this=20003BA0
HIDParser claim this=200040A0
HIDParser claim this=200045A0
JoystickController claim this=20005280
BluetoothController claim this=20004AA0
Descriptor 4 = INTERFACE
HIDParser claim this=200031A0
HIDParser claim this=200036A0
HIDParser claim this=20003BA0
HIDParser claim this=200040A0
HIDParser claim this=200045A0
JoystickController claim this=20005280
09 04 00 00 03 FF 01 01 00 07 05 81 03 10 00 01 07 05 82 02 40 00 01 07 05 02 02 40 00 01 09 04 01 00 02 FF 01 01 00 07 05 83 01 00 00 01 07 05 03 01 00 00 01 09 04 01 01 02 FF 01 01 00 07 05 83 01 09 00 01 07 05 03 01 09 00 01 09 04 01 02 02 FF 01 01 00 07 05 83 01 11 00 01 07 05 03 01 11 00 01 09 04 01 03 02 FF 01 01 00 07 05 83 01 19 00 01 07 05 03 01 19 00 01 09 04 01 04 02 FF 01 01 00 07 05 83 01 21 00 01 07 05 03 01 21 00 01 09 04 01 05 02 FF 01 01 00 07 05 83 01 31 00 01 07 05 03 01 31 00 01 09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
Jtype=0
BluetoothController claim this=20004AA0
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
HIDParser claim this=200031A0
HIDParser claim this=200036A0
HIDParser claim this=20003BA0
HIDParser claim this=200040A0
HIDParser claim this=200045A0
JoystickController claim this=20005280
09 04 01 00 02 FF 01 01 00 07 05 83 01 00 00 01 07 05 03 01 00 00 01 09 04 01 01 02 FF 01 01 00 07 05 83 01 09 00 01 07 05 03 01 09 00 01 09 04 01 02 02 FF 01 01 00 07 05 83 01 11 00 01 07 05 03 01 11 00 01 09 04 01 03 02 FF 01 01 00 07 05 83 01 19 00 01 07 05 03 01 19 00 01 09 04 01 04 02 FF 01 01 00 07 05 83 01 21 00 01 07 05 03 01 21 00 01 09 04 01 05 02 FF 01 01 00 07 05 83 01 31 00 01 07 05 03 01 31 00 01 09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
Jtype=0
BluetoothController claim this=20004AA0
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
HIDParser claim this=200031A0
HIDParser claim this=200036A0
HIDParser claim this=20003BA0
HIDParser claim this=200040A0
HIDParser claim this=200045A0
JoystickController claim this=20005280
09 04 01 01 02 FF 01 01 00 07 05 83 01 09 00 01 07 05 03 01 09 00 01 09 04 01 02 02 FF 01 01 00 07 05 83 01 11 00 01 07 05 03 01 11 00 01 09 04 01 03 02 FF 01 01 00 07 05 83 01 19 00 01 07 05 03 01 19 00 01 09 04 01 04 02 FF 01 01 00 07 05 83 01 21 00 01 07 05 03 01 21 00 01 09 04 01 05 02 FF 01 01 00 07 05 83 01 31 00 01 07 05 03 01 31 00 01 09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
Jtype=0
BluetoothController claim this=20004AA0
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
HIDParser claim this=200031A0
HIDParser claim this=200036A0
HIDParser claim this=20003BA0
HIDParser claim this=200040A0
HIDParser claim this=200045A0
JoystickController claim this=20005280
09 04 01 02 02 FF 01 01 00 07 05 83 01 11 00 01 07 05 03 01 11 00 01 09 04 01 03 02 FF 01 01 00 07 05 83 01 19 00 01 07 05 03 01 19 00 01 09 04 01 04 02 FF 01 01 00 07 05 83 01 21 00 01 07 05 03 01 21 00 01 09 04 01 05 02 FF 01 01 00 07 05 83 01 31 00 01 07 05 03 01 31 00 01 09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
Jtype=0
BluetoothController claim this=20004AA0
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
HIDParser claim this=200031A0
HIDParser claim this=200036A0
HIDParser claim this=20003BA0
HIDParser claim this=200040A0
HIDParser claim this=200045A0
JoystickController claim this=20005280
09 04 01 03 02 FF 01 01 00 07 05 83 01 19 00 01 07 05 03 01 19 00 01 09 04 01 04 02 FF 01 01 00 07 05 83 01 21 00 01 07 05 03 01 21 00 01 09 04 01 05 02 FF 01 01 00 07 05 83 01 31 00 01 07 05 03 01 31 00 01 09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
Jtype=0
BluetoothController claim this=20004AA0
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
HIDParser claim this=200031A0
HIDParser claim this=200036A0
HIDParser claim this=20003BA0
HIDParser claim this=200040A0
HIDParser claim this=200045A0
JoystickController claim this=20005280
09 04 01 04 02 FF 01 01 00 07 05 83 01 21 00 01 07 05 03 01 21 00 01 09 04 01 05 02 FF 01 01 00 07 05 83 01 31 00 01 07 05 03 01 31 00 01 09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
Jtype=0
BluetoothController claim this=20004AA0
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
HIDParser claim this=200031A0
HIDParser claim this=200036A0
HIDParser claim this=20003BA0
HIDParser claim this=200040A0
HIDParser claim this=200045A0
JoystickController claim this=20005280
09 04 01 05 02 FF 01 01 00 07 05 83 01 31 00 01 07 05 03 01 31 00 01 09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
Jtype=0
BluetoothController claim this=20004AA0
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
HIDParser claim this=200031A0
HIDParser claim this=200036A0
HIDParser claim this=20003BA0
HIDParser claim this=200040A0
HIDParser claim this=200045A0
JoystickController claim this=20005280
09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
Jtype=0
BluetoothController claim this=20004AA0
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
HIDParser claim this=200031A0
HIDParser claim this=200036A0
HIDParser claim this=20003BA0
HIDParser claim this=200040A0
HIDParser claim this=200045A0
JoystickController claim this=20005280
09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
Jtype=0
BluetoothController claim this=20004AA0
Descriptor 33 = HID
EDIT: I do have 2 other dongles coming tomorrow to try out - it may the BT dongle I am using that is causing problems.
 
Added a pull-request for MQS.
My fork has all new changes: https://github.com/FrankBoesing/Audio

You can directly add small speakers (8 OHM) with a capacitor in series (I used 100uF) - It is not very loud, but in a quite environment it is ok.
Maybe one of you electronic-specialists could post a simple amplifier? a one - transistor thing? :)


I'm not sure if I have the frequencies right - at least I have one more output working now.
 
Added a pull-request for MQS.
My fork has all new changes: https://github.com/FrankBoesing/Audio

You can directly add small speakers (8 OHM) with a capacitor in series (I used 100uF) - It is not very loud, but in a quite environment it is ok.
Maybe one of you electronic-specialists could post a simple amplifier? a one - transistor thing? :)


I'm not sure if I have the frequencies right - at least I have one more output working now.

I've used these mono amps with 8 ohm speaker
https://www.adafruit.com/product/2130
https://www.sparkfun.com/products/11044
 
@KurtE
I turned on the Pairing code, then run it... Then turned on keyboard, hit BT button, then typed 0000<enter>
As that was the key that was part of the code.. Then it paired and I am able to type in a few things...

The dongle I was using doesn't seem to want to be recognized as a BT device your Bluetooth code is never called. Spent a couple of hours finding another very old one that does appear to work and I get through the BT function. Looking at the verbose response it follows what you posted but never connects.

[Deleted] Never mind answered my own question, got it working with the keyboard, https://www.amazon.com/gp/product/B00EZL1IQA/ref=oh_aui_search_asin_title?ie=UTF8&psc=1, kind of small for my fat fingers but it works.

Example:
Code:
=====================
BT rx2_data(18): 0 20 e 0 a 0 71 0 a1 1 0 0 16 0 0 0 0 0 
HID HDR Data: len: 10, Type: 1
KeyboardController::process_bluetooth_HID_data
  KB Data: 01 00 00 16 00 00 00 00 00 
  press, key=22
  unicode = 115
key 's'  115 MOD: 
=====================
BT rx2_data(18): 0 20 e 0 a 0 71 0 a1 1 0 0 0 0 0 0 0 0 
HID HDR Data: len: 10, Type: 1
KeyboardController::process_bluetooth_HID_data
  KB Data: 01 00 00 00 00 00 00 00 00 
  release, key=22

Have three different dongles coming, 2 tomorrow and 1 on Sunday to test. Seems this is going to be BT dongle sensitive.

EDIT: If I turn off all debugging:
Code:
USB Host Testing
960
*** Device Hub1 5e3:608 - connected ***
  product: USB2.0 Hub
*** Device Bluet a12:1 - connected ***
BluetoothController::find_driver  driver 20002898
Keyboard Controller::claim_bluetooth - Class 2540
KeyboardController::claim_bluetooth TRUE
    *** Claimed ***
KeyboardController::process_bluetooth_HID_data
KeyboardController::process_bluetooth_HID_data
KeyboardController::process_bluetooth_HID_data
key '0'  48 MOD: KeyboardController::process_bluetooth_HID_data
KeyboardController::process_bluetooth_HID_data 
key '0'  48 MOD: KeyboardController::process_bluetooth_HID_data
Guess there are a couple Serial prints that have to get commented out.

EDIT2: QUESTION: How would you do the pairing with a PS4? Usually I can do it just by holding the buttons down.
 
Last edited:
@KurtE

Ok Figured out what is causing the USB to drop and the sketches hang at times. In Bluetooth.cpp you have you debug defines. If you keep them uncommented it will hang the sketch and drop USB serial connection to the PC. While this didn't happen for the Keyboard it does happen if you try it with just using the Joystick.

EDIT:
PS4 JOYSTICK WORKING-Sort of
Got it working but nothing prints direct from the sketch - the only way you see the joystick data is if you have debug uncommented in usbhost_t36.h. Second, may have to reset a after loading the sketch to get it work correctly (is that what force_reboot does?), opening and closing sermon and then reopening it causes the sketch to stop and you have to restart the T4.

sample output when its working:
Code:
USB Host Testing
960
USB2 PLL running
 reset waited 5
USBHS_ASYNCLISTADDR = 0
USBHS_PERIODICLISTBASE = 20006000
periodictable = 20006000
port change: 10001803
    connect
  begin reset
port change: 18001205
  port enabled
  end recovery
new_Device: 480 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
Device Descriptor:
  12 01 00 02 09 00 01 40 E3 05 08 06 02 07 00 01 00 01 
    VendorID = 05E3, ProductID = 0608, Version = 0702
    Class/Subclass/Protocol = 9(Hub) / 0 / 1(Single-TT)
    Number of Configurations = 1
enumeration:
enumeration:
Product: USB2.0 Hub
enumeration:
Config data length = 25
enumeration:
Configuration Descriptor:
  09 02 19 00 01 01 00 E0 32 
    NumInterfaces = 1
    ConfigurationValue = 1
  09 04 00 00 01 09 00 00 00 
    Interface = 0
    Number of endpoints = 1
    Class/Subclass/Protocol = 9(Hub) / 0 / 0
  07 05 81 03 01 00 0C 
    Endpoint = 1 IN
    Type = Interrupt
    Max Size = 1
    Polling Interval = 12
enumeration:
USBHub memory usage = 960
USBHub claim_device this=20002A00
found possible interface, altsetting=0
number of interfaces found = 1
*** Device Hub1 5e3:608 - connected ***
  product: USB2.0 Hub
USBHub control callback
09 29 04 E0 00 32 64 00 FF 00 00 00 00 00 00 00 
Hub ports = 4
USBHub control callback
USBHub control callback
USBHub control callback
USBHub control callback
power turned on to all ports
device addr = 1
new_Pipe
allocate_interrupt_pipe_bandwidth
  ep interval = 12
  interval = 256
 best_bandwidth = 2, at offset = 0
pipe cap1 = F0012101
HUB Callback (member)
status = 10
getstatus, port = 4
USBHub control callback
01 01 01 00 
New Port Status
  status=10101  port=4
  state=0
  Device is present: 
  Has Power
HUB Callback (member)
status = 10
deferred getstatus, port = 4
USBHub control callback
Port Status Cleared, port=4
getstatus, port = 4
USBHub control callback
01 01 00 00 
New Port Status
  status=101  port=4
  state=2
  Device is present: 
  Has Power
timer event (40777 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 10
getstatus, port = 4
USBHub control callback
01 01 00 00 
New Port Status
  status=101  port=4
  state=3
  Device is present: 
  Has Power
timer event (19999 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 10
getstatus, port = 4
USBHub control callback
01 01 00 00 
New Port Status
  status=101  port=4
  state=4
  Device is present: 
  Has Power
timer event (20000 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 10
getstatus, port = 4
USBHub control callback
01 01 00 00 
New Port Status
  status=101  port=4
  state=5
  Device is present: 
  Has Power
timer event (37129 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 10
getstatus, port = 4
USBHub control callback
01 01 00 00 
New Port Status
  status=101  port=4
  state=6
  Device is present: 
  Has Power
sending reset
send_setreset
timer event (50189 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 0
USBHub control callback
unhandled setup, message = 40323
HUB Callback (member)
status = 10
getstatus, port = 4
USBHub control callback
03 01 10 00 
New Port Status
  status=100103  port=4
  state=7
  Device is present: 
  Enabled, speed = 12 Mbit/sec
  Has Power
HUB Callback (member)
status = 10
deferred getstatus, port = 4
USBHub control callback
unhandled setup, message = 140123
getstatus, port = 4
USBHub control callback
03 01 00 00 
New Port Status
  status=103  port=4
  state=8
  Device is present: 
  Enabled, speed = 12 Mbit/sec
  Has Power
timer event (26489 us): Hello, I'm resettimer, this = 20002A00, timer = 20002D34
port_doing_reset = 4
PORT_RECOVERY
new_Device: 12 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
Device Descriptor:
  12 01 00 02 E0 01 01 40 12 0A 01 00 15 19 00 00 00 01 
    VendorID = 0A12, ProductID = 0001, Version = 1915
    Class/Subclass/Protocol = 224 / 1 / 1
    Number of Configurations = 1
enumeration:
Config data length = 177
enumeration:
Configuration Descriptor:
  09 02 B1 00 02 01 00 C0 00 
    NumInterfaces = 2
    ConfigurationValue = 1
  09 04 00 00 03 E0 01 01 00 
    Interface = 0
    Number of endpoints = 3
    Class/Subclass/Protocol = 224 / 1 / 1
  07 05 81 03 10 00 01 
    Endpoint = 1 IN
    Type = Interrupt
    Max Size = 16
    Polling Interval = 1
  07 05 82 02 40 00 00 
    Endpoint = 2 IN
    Type = Bulk
    Max Size = 64
    Polling Interval = 0
  07 05 02 02 40 00 00 
    Endpoint = 2 OUT
    Type = Bulk
    Max Size = 64
    Polling Interval = 0
  09 04 01 00 02 E0 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 224 / 1 / 1
  07 05 83 01 20 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 32
    Polling Interval = 1
  07 05 03 01 20 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 32
    Polling Interval = 1
  09 04 01 01 02 E0 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 224 / 1 / 1
  07 05 83 01 09 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 9
    Polling Interval = 1
  07 05 03 01 09 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 9
    Polling Interval = 1
  09 04 01 02 02 E0 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 224 / 1 / 1
  07 05 83 01 11 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 17
    Polling Interval = 1
  07 05 03 01 11 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 17
    Polling Interval = 1
  09 04 01 03 02 E0 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 224 / 1 / 1
  07 05 83 01 19 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 25
    Polling Interval = 1
  07 05 03 01 19 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 25
    Polling Interval = 1
  09 04 01 04 02 E0 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 224 / 1 / 1
  07 05 83 01 21 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 33
    Polling Interval = 1
  07 05 03 01 21 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 33
    Polling Interval = 1
  09 04 01 05 02 E0 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 224 / 1 / 1
  07 05 83 01 31 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 49
    Polling Interval = 1
  07 05 03 01 31 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 49
    Polling Interval = 1
enumeration:
USBHub memory usage = 960
USBHub claim_device this=20002DC0
HIDParser claim this=200031A0
HIDParser claim this=200036A0
HIDParser claim this=20003BA0
HIDParser claim this=200040A0
HIDParser claim this=200045A0
JoystickController claim this=20005280
BluetoothController claim this=20004AA0
BluetoothController, rxep=1(16), txep=2(64)
new_Pipe
allocate_interrupt_pipe_bandwidth
 best_bandwidth = 3, at offset = 0, shift= 1
new_Pipe
allocate_interrupt_pipe_bandwidth
 best_bandwidth = 6, at offset = 0, shift= 2
new_Pipe
    control callback (bluetooth) 1
*** Device Bluet a12:1 - connected ***
0E 04 01 03 0C 00 
    control callback (bluetooth) 3
0E 04 01 24 0C 00 
    control callback (bluetooth) 4
0E 0A 01 09 10 00 54 76 98 22 11 00 
    control callback (bluetooth) 4
0E 0C 01 01 10 00 03 50 00 03 10 00 03 00 
    control callback (bluetooth) 0
0E 04 01 1A 0C 00 
04 0A EA 94 9B E2 1F 00 08 25 00 01 
BluetoothController::find_driver  driver 20005298
JoystickController::claim_bluetooth TRUE
    *** Claimed ***
    control callback (bluetooth) 0
0F 04 00 00 19 04 
07 FF 00 EA 94 9B E2 1F 00 57 69 72 65 6C 65 73 
73 20 43 6F 6E 74 72 6F 6C 6C 65 72 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 
    control callback (bluetooth) 0
0F 04 00 01 00 00 
0F 04 00 01 09 04 
03 0B 00 00 00 EA 94 9B E2 1F 00 01 00 
1B 03 00 00 05 
    tx_data(bluetooth) 0
13 05 01 00 00 01 00 
    tx_data(bluetooth) 0
13 05 01 00 00 01 00 
    tx_data(bluetooth) 0
13 05 01 00 00 01 00 
    tx_data(bluetooth) 0
    tx_data(bluetooth) 0
ERROR Followup
    remain on followup list


USB Host Testing
960
USB2 PLL running
 reset waited 5
USBHS_ASYNCLISTADDR = 0
USBHS_PERIODICLISTBASE = 20006000
periodictable = 20006000
port change: 10001803
    connect
  begin reset
port change: 18001205
  port enabled
  end recovery
new_Device: 480 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
Device Descriptor:
  12 01 00 02 09 00 01 40 E3 05 08 06 02 07 00 01 00 01 
    VendorID = 05E3, ProductID = 0608, Version = 0702
    Class/Subclass/Protocol = 9(Hub) / 0 / 1(Single-TT)
    Number of Configurations = 1
enumeration:
enumeration:
Product: USB2.0 Hub
enumeration:
Config data length = 25
enumeration:
Configuration Descriptor:
  09 02 19 00 01 01 00 E0 32 
    NumInterfaces = 1
    ConfigurationValue = 1
  09 04 00 00 01 09 00 00 00 
    Interface = 0
    Number of endpoints = 1
    Class/Subclass/Protocol = 9(Hub) / 0 / 0
  07 05 81 03 01 00 0C 
    Endpoint = 1 IN
    Type = Interrupt
    Max Size = 1
    Polling Interval = 12
enumeration:
USBHub memory usage = 960
USBHub claim_device this=20002A00
found possible interface, altsetting=0
number of interfaces found = 1
*** Device Hub1 5e3:608 - connected ***
USBHub control callback
09 29 04 E0 00 32 64 00 FF 00 00 00 00 00 00 00 
Hub ports = 4
USBHub control callback
USBHub control callback
USBHub control callback
USBHub control callback
power turned on to all ports
device addr = 1
new_Pipe
allocate_interrupt_pipe_bandwidth
  ep interval = 12
  interval = 256
 best_bandwidth = 2, at offset = 0
pipe cap1 = F0012101
  product: USB2.0 Hub
HUB Callback (member)
status = 10
getstatus, port = 4
USBHub control callback
01 01 01 00 
New Port Status
  status=10101  port=4
  state=0
  Device is present: 
  Has Power
USBHub control callback
Port Status Cleared, port=4
timer event (19999 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 10
getstatus, port = 4
USBHub control callback
01 01 00 00 
New Port Status
  status=101  port=4
  state=2
  Device is present: 
  Has Power
timer event (19999 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 10
getstatus, port = 4
USBHub control callback
01 01 00 00 
New Port Status
  status=101  port=4
  state=3
  Device is present: 
  Has Power
timer event (20000 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 10
getstatus, port = 4
USBHub control callback
01 01 00 00 
New Port Status
  status=101  port=4
  state=4
  Device is present: 
  Has Power
timer event (26669 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 10
getstatus, port = 4
USBHub control callback
01 01 00 00 
New Port Status
  status=101  port=4
  state=5
  Device is present: 
  Has Power
timer event (19999 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 10
getstatus, port = 4
USBHub control callback
01 01 00 00 
New Port Status
  status=101  port=4
  state=6
  Device is present: 
  Has Power
sending reset
send_setreset
timer event (25986 us): Debounce Timer, this = 20002A00, timer = 20002D18
ports in use bitmask = 0
USBHub control callback
unhandled setup, message = 40323
HUB Callback (member)
status = 10
getstatus, port = 4
USBHub control callback
03 01 10 00 
New Port Status
  status=100103  port=4
  state=7
  Device is present: 
  Enabled, speed = 12 Mbit/sec
  Has Power
USBHub control callback
unhandled setup, message = 140123
timer event (25000 us): Hello, I'm resettimer, this = 20002A00, timer = 20002D34
port_doing_reset = 4
PORT_RECOVERY
new_Device: 12 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
Device Descriptor:
  12 01 00 02 E0 01 01 40 12 0A 01 00 15 19 00 00 00 01 
    VendorID = 0A12, ProductID = 0001, Version = 1915
    Class/Subclass/Protocol = 224 / 1 / 1
    Number of Configurations = 1
enumeration:
Config data length = 177
enumeration:
Configuration Descriptor:
  09 02 B1 00 02 01 00 C0 00 
    NumInterfaces = 2
    ConfigurationValue = 1
  09 04 00 00 03 E0 01 01 00 
    Interface = 0
    Number of endpoints = 3
    Class/Subclass/Protocol = 224 / 1 / 1
  07 05 81 03 10 00 01 
    Endpoint = 1 IN
    Type = Interrupt
    Max Size = 16
    Polling Interval = 1
  07 05 82 02 40 00 00 
    Endpoint = 2 IN
    Type = Bulk
    Max Size = 64
    Polling Interval = 0
  07 05 02 02 40 00 00 
    Endpoint = 2 OUT
    Type = Bulk
    Max Size = 64
    Polling Interval = 0
  09 04 01 00 02 E0 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 224 / 1 / 1
  07 05 83 01 20 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 32
    Polling Interval = 1
  07 05 03 01 20 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 32
    Polling Interval = 1
  09 04 01 01 02 E0 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 224 / 1 / 1
  07 05 83 01 09 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 9
    Polling Interval = 1
  07 05 03 01 09 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 9
    Polling Interval = 1
  09 04 01 02 02 E0 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 224 / 1 / 1
  07 05 83 01 11 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 17
    Polling Interval = 1
  07 05 03 01 11 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 17
    Polling Interval = 1
  09 04 01 03 02 E0 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 224 / 1 / 1
  07 05 83 01 19 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 25
    Polling Interval = 1
  07 05 03 01 19 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 25
    Polling Interval = 1
  09 04 01 04 02 E0 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 224 / 1 / 1
  07 05 83 01 21 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 33
    Polling Interval = 1
  07 05 03 01 21 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 33
    Polling Interval = 1
  09 04 01 05 02 E0 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 224 / 1 / 1
  07 05 83 01 31 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 49
    Polling Interval = 1
  07 05 03 01 31 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 49
    Polling Interval = 1
enumeration:
USBHub memory usage = 960
USBHub claim_device this=20002DC0
HIDParser claim this=200031A0
HIDParser claim this=200036A0
HIDParser claim this=20003BA0
HIDParser claim this=200040A0
HIDParser claim this=200045A0
JoystickController claim this=20005280
BluetoothController claim this=20004AA0
BluetoothController, rxep=1(16), txep=2(64)
new_Pipe
allocate_interrupt_pipe_bandwidth
 best_bandwidth = 3, at offset = 0, shift= 1
new_Pipe
allocate_interrupt_pipe_bandwidth
 best_bandwidth = 6, at offset = 0, shift= 2
new_Pipe
*** Device Bluet a12:1 - connected ***
    control callback (bluetooth) 1
0E 04 01 03 0C 00 
    control callback (bluetooth) 3
0E 04 01 24 0C 00 
    control callback (bluetooth) 4
0E 0A 01 09 10 00 54 76 98 22 11 00 
    control callback (bluetooth) 4
0E 0C 01 01 10 00 03 50 00 03 10 00 03 00 
    control callback (bluetooth) 0
0E 04 01 1A 0C 00 
04 0A EA 94 9B E2 1F 00 08 25 00 01 
BluetoothController::find_driver  driver 20005298
JoystickController::claim_bluetooth TRUE
    *** Claimed ***
    control callback (bluetooth) 0
0F 04 00 00 19 04 
07 FF 00 EA 94 9B E2 1F 00 57 69 72 65 6C 65 73 
73 20 43 6F 6E 74 72 6F 6C 6C 65 72 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 
    control callback (bluetooth) 0
0F 04 00 01 00 00 
0F 04 00 01 09 04 
03 0B 00 00 00 EA 94 9B E2 1F 00 01 00 
1B 03 00 00 05 
    tx_data(bluetooth) 0
13 05 01 00 00 01 00 
    tx_data(bluetooth) 0
13 05 01 00 00 01 00 
    tx_data(bluetooth) 0
13 05 01 00 00 01 00 
    tx_data(bluetooth) 0
    tx_data(bluetooth) 0
    tx_data(bluetooth) 0
13 05 01 00 00 01 00 
13 05 01 00 00 01 00 
13 05 01 00 00 01 00 
    tx_data(bluetooth) 0
13 05 01 00 00 01 00 
    control callback (bluetooth) 0
0E 04 01 1A 0C 00 
    tx_data(bluetooth) 0
13 05 01 00 00 01 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 79 7E 7E 08 00 00 00 00 
  Joystick Data: 01 83 79 7e 7e 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 78 7E 7E 08 00 00 00 00 
  Joystick Data: 01 83 78 7e 7e 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 79 7E 7E 08 00 00 00 00 
  Joystick Data: 01 83 79 7e 7e 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 78 7E 7E 08 00 00 00 00 
  Joystick Data: 01 83 78 7e 7e 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 79 7E 7E 08 00 00 00 00 
  Joystick Data: 01 83 79 7e 7e 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 79 7E 7F 08 00 00 00 00 
  Joystick Data: 01 83 79 7e 7f 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 79 7E 7E 08 00 00 00 00 
  Joystick Data: 01 83 79 7e 7e 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 79 7E 7F 08 00 00 00 00 
  Joystick Data: 01 83 79 7e 7f 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 78 7E 7F 08 00 00 00 00 
  Joystick Data: 01 83 78 7e 7f 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 79 7E 7F 08 00 00 00 00 
  Joystick Data: 01 83 79 7e 7f 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 78 7E 7F 08 00 00 00 00 
  Joystick Data: 01 83 78 7e 7f 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 79 7E 7F 08 00 00 00 00 
  Joystick Data: 01 83 79 7e 7f 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 78 7E 7F 08 00 00 00 00 
  Joystick Data: 01 83 78 7e 7f 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 79 7E 7E 08 00 00 00 00 
  Joystick Data: 01 83 79 7e 7e 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 78 7E 7E 08 00 00 00 00 
  Joystick Data: 01 83 78 7e 7e 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 79 7E 7E 08 00 00 00 00 
  Joystick Data: 01 83 79 7e 7e 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 7A 7E 7E 08 00 00 00 00 
  Joystick Data: 01 83 7a 7e 7e 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 7B 7E 7E 08 00 00 00 00 
  Joystick Data: 01 83 7b 7e 7e 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 7C 7E 7E 08 00 00 00 00 
  Joystick Data: 01 83 7c 7e 7e 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 7F 7E 7E 08 00 00 00 00 
  Joystick Data: 01 83 7f 7e 7e 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 7E 7E 7E 08 00 00 00 00 
  Joystick Data: 01 83 7e 7e 7e 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 7F 7E 80 08 00 00 00 00 
  Joystick Data: 01 83 7f 7e 80 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 7E 7E 80 08 00 00 00 00 
  Joystick Data: 01 83 7e 7e 80 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 7E 7E 84 08 00 00 00 00 
  Joystick Data: 01 83 7e 7e 84 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 7F 7E 84 08 00 00 00 00 
  Joystick Data: 01 83 7f 7e 84 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 7F 7E 85 08 00 00 00 00 
  Joystick Data: 01 83 7f 7e 85 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 7E 7E 85 08 00 00 00 00 
  Joystick Data: 01 83 7e 7e 85 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 7F 7F 85 08 00 00 00 00 
  Joystick Data: 01 83 7f 7f 85 08 00 00 00 00 
17 06 EA 94 9B E2 1F 00 
    control callback (bluetooth) 78
0F 04 00 01 00 00 
0E 0A 01 0C 04 00 EA 94 9B E2 1F 00 
16 06 EA 94 9B E2 1F 00 
    control callback (bluetooth) 82
0E 0A 01 0D 04 00 EA 94 9B E2 1F 00 
18 17 EA 94 9B E2 1F 00 F8 9A 5E 4C AC 9C 84 F8 
5A 0F 28 8C 47 F4 48 35 00 
06 03 00 00 00 
    tx_data(bluetooth) 82
0F 04 00 01 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 7E 7F 85 08 00 00 00 00 
  Joystick Data: 01 83 7e 7f 85 08 00 00 00 00 
08 04 00 00 00 01 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 7F 7F 85 08 00 00 00 00 
  Joystick Data: 01 83 7f 7f 85 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 78 7F 80 08 00 00 00 00 
  Joystick Data: 01 83 78 7f 80 08 00 00 00 00 
    tx_data(bluetooth) 82
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 77 7F 80 08 00 00 00 00 
  Joystick Data: 01 83 77 7f 80 08 00 00 00 00 
13 05 01 00 00 01 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 83 78 7F 80 08 00 00 00 00 
  Joystick Data: 01 83 78 7f 80 08 00 00 00 00 
13 05 01 00 00 01 00 
    tx_data(bluetooth) 82
    tx_data(bluetooth) 82

Looks like hooks need to be put into to get it to print to the proper functions. Tomorrow is another day.
 
Last edited:
@KurtE

Ok Figured out what is causing the USB to drop and the sketches hang at times. In Bluetooth.cpp you have you debug defines. If you keep them uncommented it will hang the sketch and drop USB serial connection to the PC. While this didn't happen for the Keyboard it does happen if you try it with just using the Joystick.

Good find Mike … the problems of debugging with prints? I dropped an EEPROM_func() in USB startup when I looked at having alternate Serial Types enact during boot for that Forum question - was amazing it was entering IIRC some dozens of times iterating while setting up.
 
In terms of PROGMEM setup (), I looked at the compiler source (varasm.c), and the logic is GCC will not permit you to put variables and functions in the same named section, because the sections have different flags set (i.e. the executable bit). While, I looked at a GCC 9 development source, the section that does the complaining was added in 2013 and the ChangeLog comment indicates it was just tidying up the error in one case.

We have the following definitions:
Code:
// In ./hardware/teensy/avr/cores/teensy3/avr/pgmspace.h:
#define PROGMEM

// In ./hardware/teensy/avr/cores/teensy4/avr/pgmspace.h:
#define PROGMEM __attribute__((section(".progmem")))

Because of this restriction in the compiler, you cannot use PROGMEM on functions (at least in the same module where PROGMEM variables are defined).

In terms of solutions:
  • Add a separate PROGMEM for Teensy functions that uses a different section name;
  • Don't use PROGMEM on functions; (or)
  • Go back to re-defining PROGMEM to be nothing.
 
Last edited:
In terms of PROGMEM setup (), I looked at the compiler source (varasm.c), and the logic is GCC will not permit you to put variables and functions in the same named section, because the sections have different flags set (i.e. the executable bit). While, I looked at a GCC 9 development source, the section that does the complaining was added in 2013 and the ChangeLog comment indicates it was just tidying up the error in one case.

We have the following definitions:
Code:
// In ./hardware/teensy/avr/cores/teensy3/avr/pgmspace.h:
#define PROGMEM

// In ./hardware/teensy/avr/cores/teensy4/avr/pgmspace.h:
#define PROGMEM __attribute__((section(".progmem")))

Because of this restriction in the compiler, you cannot use PROGMEM on functions (at least in the same module where PROGMEM variables are defined).

In terms of solutions:
  • Add a separate PROGMEM for Teensy functions that uses a different section name;
  • Don't use PROGMEM on functions; (or)
  • Go back to re-defining PROGMEM to be nothing.

Thanks Michael, I was hoping there was a switch to suppress the error.
Looks like we have to add an additional section.
 
Added a pull-request for MQS.
My fork has all new changes: https://github.com/FrankBoesing/Audio

You can directly add small speakers (8 OHM) with a capacitor in series (I used 100uF) - It is not very loud, but in a quite environment it is ok.
Maybe one of you electronic-specialists could post a simple amplifier? a one - transistor thing? :)


I'm not sure if I have the frequencies right - at least I have one more output working now.

Added output_PT8211 on SAI1
PT8211 for SAI2 tonight.. I'm going to take a nap now ;)
 
Thanks Michael, I was hoping there was a switch to suppress the error.
Looks like we have to add an additional section.

Note, if you add another section, there may be an unintended consequence. The Arduino builds use -ffunction-sections and -fdata-sections on the compiler and -Wl,--gc-sections,--relax on the linker. This puts each function and global data item into a separate ELF section, and if there are no references to a given section, the linker will discard that section. If you put all 'PROGMEM'-type functions into a common section, the linker will not discard that section if there are any references to any of the functions within the section.
 
@KurtE
Found the offending Debug code that cause USB to drop.
Code:
void BluetoothController::handle_hci_command_status() 
{
	// <event type><param count><status><num packets allowed to be sent><CMD><CMD>
#ifdef DEBUG_BT1
	uint16_t hci_command = rxbuf_[4] + (rxbuf_[5] << 8);
	if (rxbuf_[2]) {
		DBGPrintf("    Command %x Status %x - ", hci_command, rxbuf_[2]);
		switch (rxbuf_[2]) {
			case 0x01: DBGPrintf("Unknown HCI Command\n"); break;
			case 0x02: DBGPrintf("Unknown Connection Identifier\n"); break;
Its something with all those case statement prints. If you just put a dummy define it will compile and run fine.

I also updated joystick.cpp to include the bt for the manufacture, S/N, etc. Once I did that then I was able see a bunch of other info and the connecting got better. One thing I noticed is that PS4 is identified as a "Gamepad". Don't know about other controllers as the PS4 is the only one I have. The only thing that I can't figure out is how to identify the controller by name yet. Still looking though, wanted to try and put hooks in to getaxis etc. May have to something different for BT.

I update my current version on the WIP page.

Mike
 
@KurtE

Ok Figured out what is causing the USB to drop and the sketches hang at times. In Bluetooth.cpp you have you debug defines. If you keep them uncommented it will hang the sketch and drop USB serial connection to the PC. While this didn't happen for the Keyboard it does happen if you try it with just using the Joystick.

EDIT:
PS4 JOYSTICK WORKING-Sort of
Got it working but nothing prints direct from the sketch - the only way you see the joystick data is if you have debug uncommented in usbhost_t36.h. Second, may have to reset a after loading the sketch to get it work correctly (is that what force_reboot does?), opening and closing sermon and then reopening it causes the sketch to stop and you have to restart the T4.

sample output when its working:


Looks like hooks need to be put into to get it to print to the proper functions. Tomorrow is another day.

Looks like you are making some progress! My problem is that my PS4 controllers battery died again. I replaced it a year or so ago when it was dead then and would not charge... So trying to decide if to order a new battery again or order another PS4 controller... Took me awhile to locate one of my PS3 controllers. It needed to have it's battery charged so it was charging for several hours yesterday...

I think I tried this over a year ago as well, but I did not write anything in the notes I put up on the thread: https://forum.pjrc.com/threads/49358-T3-6-USB-Host-Bluetooth

The thing about PS3 controllers, at least on things like RPI, you normally could not pair them with BT objects over BT, but instead would have to plug it in and then use some command line program (sixpair?) to program both the BT dongle and the PS3... So not sure what to do here? And I used to find the PS3s on Linux to be very temperamental... First attempt back to look at this is maybe try to pair a dongle with PS3 on Linux board and then try to move the dongle back to T4...

There was also a question raised within the last couple of days about should we just port over code like that is in the USB Host shield 2 code. It was my impression that Paul wanted to go in a slightly different direction with this library. At least when I last looked at it, with the shield2 code you don't just say I want a joystick, you say that I want a PS3 or a PS4 or a XBox or a... And you have different drivers/objects for each of these for how they are connected. Example you have a USB PS4 driver versus a Bluetooth PS4 driver. They do share some same code, but your program has to specify specifically which one you expect to use. I have not experimented a lot with the host shield 2 program that can have multiple of these objects (USB PS3, USB PS4, BT PS3, USB PS3) and at run time figure this out... I only tried running their code on AVR board... Never got one to work with Teensy... Maybe should try again some day...
 
There was also a question raised within the last couple of days about should we just port over code like that is in the USB Host shield 2 code. It was my impression that Paul wanted to go in a slightly different direction with this library. At least when I last looked at it, with the shield2 code you don't just say I want a joystick, you say that I want a PS3 or a PS4 or a XBox or a... And you have different drivers/objects for each of these for how they are connected. Example you have a USB PS4 driver versus a Bluetooth PS4 driver. They do share some same code, but your program has to specify specifically which one you expect to use. I have not experimented a lot with the host shield 2 program that can have multiple of these objects (USB PS3, USB PS4, BT PS3, USB PS3) and at run time figure this out... I only tried running their code on AVR board... Never got one to work with Teensy... Maybe should try again some day...

@KurtE
A couple of things. I have used the mini-shield with a t3.5 with no problem and I updated it to work with T4. All that required was updating the pins. I think I did a pull request for Paul to update it in his fork. So, yes it does work with the Teensies.

Yes, you are right - you have to select the controller you want to use, then you run that example.

On another, I caused the fault again to happen with the usb with the joystick as a test and when I went back to the working version, its causing me all kinds of issues. I am beginning to think there is some kind of memory or address issue going on with the Joystick. Once I get it working it stays working consistently but.... to sensitive.

EDIT: Heres a sample on startup of what happens, but now it eventually dies - this morning it was fine until I caused the fault. FYI-keyboard works fine
Code:
04 0A EA 94 9B E2 1F 00 08 25 00 01 
BluetoothController::find_driver  driver 20005298
JoystickController::claim_bluetooth TRUE
    *** Claimed ***
    control callback (bluetooth) 0
0F 04 00 00 19 04 
07 FF 00 EA 94 9B E2 1F 00 57 69 72 65 6C 65 73 
73 20 43 6F 6E 74 72 6F 6C 6C 65 72 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 
    control callback (bluetooth) 0
0F 04 00 01 00 00 
0F 04 00 01 09 04 
12 08 00 EA 94 9B E2 1F 00 00 
03 0B 00 00 00 EA 94 9B E2 1F 00 01 00 
1B 03 00 00 05 
    tx_data(bluetooth) 0
    tx_data(bluetooth) 0
    tx_data(bluetooth) 0
13 05 01 00 00 01 00 
13 05 01 00 00 01 00 
13 05 01 00 00 01 00 
    tx_data(bluetooth) 0
    tx_data(bluetooth) 0
    tx_data(bluetooth) 0
13 05 01 00 00 01 00 
13 05 01 00 00 01 00 
13 05 01 00 00 01 00 
    tx_data(bluetooth) 0
13 05 01 00 00 01 00 
    control callback (bluetooth) 0
0E 04 01 1A 0C 00 
    tx_data(bluetooth) 0
13 05 01 00 00 01 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 84 7F 7F 82 08 00 00 00 00 
  Joystick Data: 01 84 7f 7f 82 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 84 80 7F 82 08 00 00 00 00 
  Joystick Data: 01 84 80 7f 82 08 00 00 00 00 
JoystickController::process_bluetooth_HID_data
  Joystick Data: 01 84 7F 7F 82 08 00 00 00 00 
  Joystick Data: 01 84 7f 7f 82 08 00 00 00 00 
17 06 EA 94 9B E2 1F 00 
ERROR Followup
    remain on followup list
    remove from followup list
    remove from followup list
    stray halted 20005140
  qtd: 20005140, token=80008180, next=20004D40
  dummy halt: 20004D40
    control callback (bluetooth) 78
0F 04 00 01 00 00 
05 04 00 00 00 08
 
Last edited:
@defragster

Ok Tim. Think I need to play with your debug_tt to figure out whats really going on with the joystick
Not knowing the code in my usual way - I'd use my unpublished debug_tt code and put a trace on each function and decision point - then when it faulted it would be clear what led to that with some key values at those traced points.

Any plans on publishing it with instructions?

Mike
 
@mjs513 - Wonder if it would make sense for me to make my branch use something like Serial4 instead of USB Serial for the debug code? I did this for some other code parts recently and made it a lot easier to debug as you also can get input back ...
 
@defragster
Ok Tim. Think I need to play with your debug_tt to figure out whats really going on with the joystick
Any plans on publishing it with instructions?

I run T4, with a pair of Teensys using their Serial1, sitting on both Serial1 and Serial4, and have upped the baud rate to 1843200 baud on both using this EchoBoth
>> That sketch has two notes for cores changes: have to edit PJRC baud rate on Serial4 and for the code to run as it exists in FAULT condition replace the .flush()

I'm building and uploading with TyComm and have three instances of TyComm SerMon: T4 USB Serial, Teensy A on T4 Serial4, Teensy B on Serial1. Running Examples below prints the T4 port ID for each Serial# at start.

Included are two updated Examples for seeing usage - that I was using to test added code. The first DebugMin_tt.ino as uploaded will hit:
>>>> debug_fault >>>> debug_fault >>>> TYPE:T_4
Debug Info:
lastL_tt:67 lastF_tt:setup
2 => 371728 0x5AC10 [L#67_C#1 _<< last func::setup

>>>> debug_fault >>>> TYPE:T_4

This prints after the register dump which shows: 'debug_tt:: Fault irq 3' because there is a FAULT in the code. The above shows the LastL_tt where a "_tt" command ran was #67, so look at line #68.
From there you can 'd' to dump the Trace up to that point, it shows it ran into foo(), which just gives examples of using:
#define debTrace_tt( a, b, c ) { debTrace_ttf( (uint32_t) a, (uint32_t) b, (const char *) c, __LINE__, __func__); lastF_tt=(char*)__func__; lastL_tt=__LINE__; }
>> i.e.:: debTrace_tt( (uint32_t) a, (uint32_t) b, (const char *) c ) :: and it appends Line# and Func_Name to each by default
NOTE: the 'd' calls "void Debug_Dump(void)" in your local sketch - you can edit that so show ANY data relevant at the time.
>> IF FAULTED the 'SERIAL_tt.flush();' shown are needed to force out the Serial characters!
It shows use of // MAX is max # to print. -1 stops Trace recording, -2 enables, -3 says print all, 0 says to clear the Trace data
void debTraceShow_tt( int Max, const char *aa, const char *bb, const char *cc)
>> The last three 'const char *' are printf format strings to display the stored values a,b,c above.

You can then enter 'b' to take the Teensy to Bootloader for the next code upload in lieu of pushing the button.
You can press 'y' and continue, but that won't work out well with the MCU Faulted - as it burrows into debug_tt's userDebugDumptt() called by HardFault_HandlerC()
Comment that fault and you die at line #69 assert where the same stuff applies for display but 'y' works to continue. It demonstrates some more - and sits in a while(1) where I was testing tracing last.

The other example derived from that is : T:\tCode\libraries\debug_tt\examples\Trace_tt\Trace_tt.ino
It is similar in most ways it seems. - and looks less up to date

In setup(): debBegin_tt( &SERIAL1, LED_BUILTIN, 12); // pass 255 to disable wither pin#
Tells it to do debug output on Serial1, use pin13 for flash when "broken" for debug, and pin12 if you put a button on that will break into debug with a CHANGE interrupt to you can do the above at any time.
There are some other notes in 'ReadMe.txt' - the perhaps up to date part is at the end :: FUNCTIONS in keywords.txt


As in the examples: To put in sketch do : #include "debug_tt.h" and that will change the fault handler, without calling debBegin_tt() with a port it will send ouput to USB Serial, but current USB Serial is write only from T4.

[Hopefully I left it working] And putting #include "debug_ttc.h" in your target file will bring in a valid set of the needed prototypes usable in CORE files. That file needs to be placed as "hardware\teensy\avr\cores\teensy4\debug_ttc.h" for the build to find it.

I'll be offline a couple of hours - hopefully that gives a usable starting point. If you need to hack anything to make it work or see trouble - let me know in PM or other - I'll PM you my email address.
 
Last edited:
There is a single compile warning in 1.46-beta9 when setting to All, may be could be removed in next beta ?

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3\Stream.cpp: In member function 'bool Stream::findUntil(const char*, const char*)':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3\Stream.cpp:93:10: warning: unused variable 'tlen' [-Wunused-variable]

size_t tlen = (terminator==nullptr)?0:strlen(terminator);
 
Note, if you add another section, there may be an unintended consequence. The Arduino builds use -ffunction-sections and -fdata-sections on the compiler and -Wl,--gc-sections,--relax on the linker. This puts each function and global data item into a separate ELF section, and if there are no references to a given section, the linker will discard that section. If you put all 'PROGMEM'-type functions into a common section, the linker will not discard that section if there are any references to any of the functions within the section.

Michael,
Deviating slightly, let me turn the problem around.
If I wanted, as it is with T3, all program code and constants in Flash and only non-constant data in RAM, how should I instruct compiler and linker?
Reason: Contrary to suggested RAM based execution, I would like to use RAM for data buffer.
 
@mjs513 - Wonder if it would make sense for me to make my branch use something like Serial4 instead of USB Serial for the debug code? I did this for some other code parts recently and made it a lot easier to debug as you also can get input back ...

You that does give me an idea though. If I put all the verbose debug stuff on Serial4 and it compiles and runs then that would imply to me that there may be an issue between USB_HOST_BT and USB. If it does the same thing, then that is another story.

After that going to work with Tim's debugger. :)

EDIT: Well so much for that idea. Just changing to Serial4 for the Debug didn't work. Same thing happened. So...

I decided just to comment the defines for Debug_BT and Debug_BT_Verbose, as well as the ifdef, just to see what would happen. Well, guess what it worked...….

Also traced this:
Code:
ERROR Followup
    remain on followup list
    remove from followup list
    remove from followup list
    stray halted 20006480
  qtd: 20006480, token=80008180, next=20004CC0
  dummy halt: 20004CC0
    control callback (bluetooth) 4
to the ehci.cpp code... not sure what all that means.
 
Last edited:
Good luck Mike. I just made some minor edits to post above.
I noted before - and in EchoBoth above that Serial4.begin( 1843200 ); is (16 times) better with edit to: T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\debugprintf.c :: void printf_debug_init(void)
LPUART3_BAUD = LPUART_BAUD_OSR(12) | LPUART_BAUD_SBR(1); // 1843200 baud

I found that if I ever use SerMon to send any char to USB it halts it seems? I don't suppose that is being done while watching USB Serial debug output, but there could be some other timing issue? Not sure if both USB's are at same interrupt priority? One may be messing with the timing of the other when used for debug output. Using the debTrace_tt( ARM_DWT_CYCCNT, __LINE__, "You are here" ); or deb_tt( 2, micros() ); to record info to print later after the _isr() would prevent that.
>> debTraceShow_tt( 30, "CycCnt %u", "\tline %u", "\tfunc %s\n" ); // show the last 30 Trace events
>> deb_tt( 401, __LINE__ ); // will show the 10 stored debug events [0-9] logged with :: deb_tt( 2, micros() ); // where param 1 [0-9] update that log info each call.

In theory I didn't break usage for T_3.x's - but have not confirmed that. The LOG [0-9] could be larger - I was thinking small at the start - but the Trace info takes over 5K as it currently records 1023 calls.

Mike: The Serial4 Teensy shows it gets out of Serial Sync at times and just shows an odd ascii char - so I just punch TyComm GUI 'reset' on that and it comes back.
 
Last edited:
I wrote a little tool (imxrt-size) that displays more useful info than Arduino.

For example:
Code:
ITCM : 16544 B  (16.16 KB)
DTCM : 17088 B  (16.69 KB)
OCRAM: 3904 B   (3.81 KB)
Flash: 27360 B  (26.72 KB)

If there is any interest I'l upload it to github. It is super-simple plain C and should run on any OS. I hope I can add it to platform.txt somehow.
Currently, I start it this way:
Code:
C:\Arduino\hardware\tools\arm\bin\arm-none-eabi-gcc-nm C:\temp\arduino_build_394690\t4_audiotest.ino.elf -n | imxrt-size

Windows binary:
Edit: executable and sourcecode removed, see later posts.
 
Last edited:
Good luck Mike. I just made some minor edits to post above.
I noted before - and in EchoBoth above that Serial4.begin( 1843200 ); is (16 times) better with edit to: T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\debugprintf.c :: void printf_debug_init(void)
LPUART3_BAUD = LPUART_BAUD_OSR(12) | LPUART_BAUD_SBR(1); // 1843200 baud

I found that if I ever use SerMon to send any char to USB it halts it seems? I don't suppose that is being done while watching USB Serial debug output, but there could be some other timing issue? Not sure if both USB's are at same interrupt priority? One may be messing with the timing of the other when used for debug output. Using the debTrace_tt( ARM_DWT_CYCCNT, __LINE__, "You are here" ); or deb_tt( 2, micros() ); to record info to print later after the _isr() would prevent that.
>> debTraceShow_tt( 30, "CycCnt %u", "\tline %u", "\tfunc %s\n" ); // show the last 30 Trace events
>> deb_tt( 401, __LINE__ ); // will show the 10 stored debug events [0-9] logged with :: deb_tt( 2, micros() ); // where param 1 [0-9] update that log info each call.

In theory I didn't break usage for T_3.x's - but have not confirmed that. The LOG [0-9] could be larger - I was thinking small at the start - but the Trace info takes over 5K as it currently records 1023 calls.

Mike: The Serial4 Teensy shows it gets out of Serial Sync at times and just shows an odd ascii char - so I just punch TyComm GUI 'reset' on that and it comes back.

Thanks Tim. I have been just tinkering with a couple new dongles I got. Just in case - see same behavior :) so that aint it... Now to take a nap read your instructions and get to work trying to figure it out. Like you said may be a timing issue, but it was working then I caused a fault, put it back and now its not working. Fustrating these types of problems

@KurtE - if you are going to go down the route of porting over uhs2 controllers, let me know and I will stop working on this.
 
Status
Not open for further replies.
Back
Top