T3.6 USB Host - Bluetooth

Kurt,
@defragster - Which bluetooth controller are you trying that does not work?
markings on my two Bt dongles are :: '"Bt Dual Mode PANBT400" They are old by some years. That fine print and FCC# are the same.

I have some chores to do now to start my day … will be back and see where it fails above 'tests for controller are' etc.

New Amazon hardware coming Tuesday is this:

Will do a quick check on my current PANBt400 to see where it is failing - then focus on making debug_tt useful/usable since I don't have Bt device hardware known to work until Tuesday it would be more of a distraction.
 
I have a couple more arriving in next few days:
https://smile.amazon.com/gp/product/B07J5WFPXX/
https://smile.amazon.com/gp/product/B0775YF36R

Will see what is happening, and use having good debug stuff would be great.

What I am wondering and may need to investigate with the PS4 controller is maybe there is some timing issue, Maybe one of the commands for reset or the like is returning a failure code saying it is not ready yet. Need to look again at how some of the things are begin handled and maybe add more checking of the return values.

Then I wonder if also maybe I am just hitting some stuff I have not learned enough yet to know that I am missing lots of needed stuff. Things like do these devices need some settings or not for BLE? ...

But will be good to be able to have a few people to bounce things back and forth with..

As for PS4, in end will be trying it again with RPI3 with new Hexapod Robot (Probably arriving Tuesday), where I will verify some of my older code will work with newer Robotis Servos... But that is a little off topic.
 
Looking at the first item is notes:
"NOT recommended for employer-provided computers "
Just read that there is a security risk/break in BtLowEnergy. That must be their subtle way of acknowledging that.

Hopefully the Bt devices I got are good to work with - went with budget PS3 - had only 9 reviews - but all 5 stars. Will be good to see stuff work - would have helped to jump on this for T_3.6 - and not leave you/Kurt hanging - but seems more critical given the T4 commonality and how much functionality it can add - and given the added T4 power and room - will help the T_3.6 too. Just hope the end device is easy to connect it up. Will require some good castellated boards of something to make use of the bottom pads.
 

@defragster - Which bluetooth controller are you trying that does not work?
It would be interesting to see what the data is that is currently the tests for controller are:
Code:
// Lets try to support the main USB Bluetooth class...
	// http://www.usb.org/developers/defined_class/#BaseClassE0h
	[COLOR="#FF0000"]if (dev->bDeviceClass != 0xe0) return false;[/COLOR]	// not base class wireless controller
	if ((dev->bDeviceSubClass != 1) || (dev->bDeviceProtocol != 1)) return false; // Bluetooth Programming Interface
	if (type != 0) return false;
...

markings on my two "Bluetooth dual-mode dongle" are :: '"FCC ID: PANBT400" They are old by some years. That fine print and FCC# 1177 are the same.

Made this edit to code just before the 3 tests can fail to show all the values:
Code:
bool BluetoothController::claim(Device_t *dev, int type, const uint8_t *descriptors, uint32_t len)
{
	// only claim at device level 
	println("BluetoothController claim this=", (uint32_t)this, HEX);

[B]#ifdef USBHOST_PRINT_DEBUG
	[COLOR="#FF0000"]println("\tBtCon != 0xe0? dev->bDeviceClass=", dev->bDeviceClass, HEX);[/COLOR]
	println("\tBtCon !=1? dev->bDeviceSubClass=", dev->bDeviceSubClass, HEX);
	println("\tBtCon !=0? type=", type, HEX);
#endif
//...
[/B]

You'll see the second two tests would pass but the first test for 0xe0 finds : BtCon != 0xe0? dev->bDeviceClass=FF

Here is what I see with that code printing - scroll down to see RED lines:
Code:
USB Host Testing
960
sizeof Device = 36
sizeof Pipe = 96
sizeof Transfer = 64
power up USBHS PHY
 reset waited 4
USBHS_ASYNCLISTADDR = 0
USBHS_PERIODICLISTBASE = 1FFF5000
periodictable = 1FFF5000
port change: 10001803
    connect
  begin reset
port change: 10001805
  port enabled
  end recovery
new_Device: 12 Mbit/sec
new_Pipe
enumeration:
enumeration:
[COLOR="#FF8C00"]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[/COLOR]
enumeration:
enumeration:
Manufacturer: Broadcom Corp
enumeration:
Product: BCM20702A0
enumeration:
Serial Number: 5CF37082D1E0
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=1FFF22A0
USBHub memory usage = 960
USBHub claim_device this=1FFF2660
KeyboardController claim this=1FFF2020
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
	[COLOR="#FF0000"]BtCon != 0xe0? dev->bDeviceClass=FF[/COLOR]
	BtCon !=1? dev->bDeviceSubClass=1
	BtCon !=0? type=0
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
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 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
	[COLOR="#FF0000"]BtCon != 0xe0? dev->bDeviceClass=FF[/COLOR]
	BtCon !=1? dev->bDeviceSubClass=1
	BtCon !=0? type=1
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
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 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
	[COLOR="#FF0000"]BtCon != 0xe0? dev->bDeviceClass=FF[/COLOR]
	BtCon !=1? dev->bDeviceSubClass=1
	BtCon !=0? type=1
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
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 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
	[COLOR="#FF0000"]BtCon != 0xe0? dev->bDeviceClass=FF[/COLOR]
	BtCon !=1? dev->bDeviceSubClass=1
	BtCon !=0? type=1
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
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 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
	[COLOR="#FF0000"]BtCon != 0xe0? dev->bDeviceClass=FF[/COLOR]
	BtCon !=1? dev->bDeviceSubClass=1
	BtCon !=0? type=1
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
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 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
	[COLOR="#FF0000"]BtCon != 0xe0? dev->bDeviceClass=FF[/COLOR]
	BtCon !=1? dev->bDeviceSubClass=1
	BtCon !=0? type=1
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
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 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
	[COLOR="#FF0000"]BtCon != 0xe0? dev->bDeviceClass=FF[/COLOR]
	BtCon !=1? dev->bDeviceSubClass=1
	BtCon !=0? type=1
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
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 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
	[COLOR="#FF0000"]BtCon != 0xe0? dev->bDeviceClass=FF[/COLOR]
	BtCon !=1? dev->bDeviceSubClass=1
	BtCon !=0? type=1
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
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 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
	[COLOR="#FF0000"]BtCon != 0xe0? dev->bDeviceClass=FF[/COLOR]
	BtCon !=1? dev->bDeviceSubClass=1
	BtCon !=0? type=1
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
	[COLOR="#FF0000"]BtCon != 0xe0? dev->bDeviceClass=FF[/COLOR]
	BtCon !=1? dev->bDeviceSubClass=1
	BtCon !=0? type=1
Descriptor 33 = HID
 
Last edited:
@KurtE
I kind of stopped playing with the T4 - something strange going on over there. Anyway, I am using the T3.6 with the generic BT dongle. Now it connects to the dongle no problem. After pairing it does connect to the PS4 controller and then stops again like it was disconnected. Here is the debug output:
Code:
02 0F 01 0A F0 F0 7F 3C 00 01 02 00 04 04 20 B7 
BT rx_data(16): 2 f 1 a f0 f0 7f 3c 0 1 2 0 4 4 20 b7 
56 
BT rx_data(1): 56 
    Inquiry Result - Count: 1
      BD:a:f0:f0:7f:3c:0, PS:1, class: 200404
02 0F 01 EA 94 9B E2 1F 00 01 02 00 08 25 00 E4 
BT rx_data(16): 2 f 1 ea 94 9b e2 1f 0 1 2 0 8 25 0 e4 
55 
BT rx_data(1): 55 
    Inquiry Result - Count: 1
      BD:ea:94:9b:e2:1f:0, PS:1, class: 2508
      Peripheral device
        Gamepad
BluetoothController::find_driver  driver 1fff48f8
JoystickController::claim_bluetooth TRUE
    *** Claimed ***
HCI_INQUIRY_CANCEL called (02 04 00 )
    control callback (bluetooth) 64
    Control callback (bluetooth): 100 : 2 4 0 
0E 04 01 02 04 00 
BT rx_data(6): e 4 1 2 4 0 
    Command Completed! 
HCI_CREATE_CONNECTION called (05 04 0d ea 94 9b e2 1f 00 18 cc 01 00 00 00 00 )
    control callback (bluetooth) 65
    Control callback (bluetooth): 101 : 5 4 d ea 94 9b e2 1f 0 18 cc 1 0 0 0 0 
0F 04 00 01 05 04 
BT rx_data(6): f 4 0 1 5 4 
    Command 405 Status 0
03 0B 00 00 00 EA 94 9B E2 1F 00 01 00 
BT rx_data(13): 3 b 0 0 0 ea 94 9b e2 1f 0 1 0 
    Connection Complete - ST:0 LH:0
HCI_AUTH_REQUESTED called (11 04 02 00 00 )
    control callback (bluetooth) 6E
    Control callback (bluetooth): 110 : 11 4 2 0 0 
0F 04 00 00 11 04 
BT rx_data(6): f 4 0 0 11 4 
    Command 411 Status 0
17 06 EA 94 9B E2 1F 00 
BT rx_data(8): 17 6 ea 94 9b e2 1f 0 
    Event: Link Key Request ea:94:9b:e2:1f:0
HCI_LINK_KEY_NEG_REPLY called (0c 04 06 ea 94 9b e2 1f 00 )
    control callback (bluetooth) 78
    Control callback (bluetooth): 120 : c 4 6 ea 94 9b e2 1f 0 
0F 04 00 01 00 00 
BT rx_data(6): f 4 0 1 0 0 
    Command 0 Status 0
0E 0A 01 0C 04 00 EA 94 9B E2 1F 00 
BT rx_data(12): e a 1 c 4 0 ea 94 9b e2 1f 0 
    Command Completed! 
16 06 EA 94 9B E2 1F 00 
BT rx_data(8): 16 6 ea 94 9b e2 1f 0 
    Event: Pin Code Request ea:94:9b:e2:1f:0
HCI_PIN_CODE_REPLY called (0d 04 17 ea 94 9b e2 1f 00 04 30 30 30 30 00 00 00 00 00 00 00 00 00 00 00 00 )
    control callback (bluetooth) 82
    Control callback (bluetooth): 130 : d 4 17 ea 94 9b e2 1f 0 4 30 30 30 30 0 0 0 0 0 0 0 0 0 0 0 0 
0E 0A 01 0D 04 00 EA 94 9B E2 1F 00 
BT rx_data(12): e a 1 d 4 0 ea 94 9b e2 1f 0 
    Command Completed! 
1B 03 00 00 05 
BT rx_data(5): 1b 3 0 0 5 
18 17 EA 94 9B E2 1F 00 27 71 89 86 D6 44 26 08 
BT rx_data(16): 18 17 ea 94 9b e2 1f 0 27 71 89 86 d6 44 26 8 
8B 2D 5B A2 D9 D8 A8 46 00 
BT rx_data(9): 8b 2d 5b a2 d9 d8 a8 46 0 
    Event: Link Key Notificaton ea:94:9b:e2:1f:0 Type:0
    key:27 71 89 86 d6 44 26 08 8b 2d 5b a2 d9 d8 a8 46 
06 03 00 00 00 
BT rx_data(5): 6 3 0 0 0 
    Event: HCI Authentication complete(0): handle: 0
`ConnectionRequest called(00 20 0c 00 08 00 01 00 02 00 04 00 11 00 70 00 )
    tx_data(bluetooth) 82
tx_data callback (bluetooth): 0 : 0 20 c 0 8 0 1 0 2 0 4 0 11 0 70 0 
0F 04 00 01 00 00 
BT rx_data(6): f 4 0 1 0 0 
    Command 0 Status 0
13 05 01 00 00 01 00 
BT rx_data(7): 13 5 1 0 0 1 0 

=====================
BT rx2_data(20): 0 20 10 0 c 0 1 0 3 0 8 0 40 0 70 0 1 0 2 0 
    L2CAP Connection Response: ID: 0, Dest:40, Source:70, Result:1, Status: 2
      Control Response
L2CAP_ConfigRequest called(00 20 10 00 0c 00 01 00 04 00 08 00 40 00 00 00 01 02 ff ff )
    tx_data(bluetooth) 82
tx_data callback (bluetooth): 0 : 0 20 10 0 c 0 1 0 4 0 8 0 40 0 0 0 1 2 ff ff 
13 05 01 00 00 01 00 
BT rx_data(7): 13 5 1 0 0 1 0 

=====================
BT rx2_data(22): 0 20 12 0 e 0 1 0 5 0 a 0 70 0 0 0 0 0 1 2 ff ff 
    L2CAP config Response: ID: 0, Source:70, Flags:0, Result:0, Config: 201
Set HID Protocol 0 (00 20 05 00 01 00 40 00 70 )

=====================
BT rx2_data(20): 0 20 10 0 c 0 1 0 4 1 8 0 70 0 0 0 1 2 ff ff 
    L2CAP config Request: ID: 1, Dest:70, Flags:0,  Options: 1 2 ff ff
      Control Configuration request
L2CAP_ConfigResponse called(00 20 12 00 0e 00 01 00 05 01 0a 00 40 00 00 00 00 00 01 02 a0 02 )
    tx_data(bluetooth) 82
tx_data callback (bluetooth): 200 : 0 20 12 0 e 0 1 0 5 
`ConnectionRequest called(00 20 0c 00 08 00 01 00 02 01 04 00 13 00 71 00 )
    tx_data(bluetooth) 82
tx_data callback (bluetooth): 0 : 0 20 c 0 8 0 1 0 2 1 4 0 13 0 71 0 0 0 1 2 a0 2 
    tx_data(bluetooth) 82
tx_data callback (bluetooth): 0 : 0 20 c 0 8 0 1 0 2 1 4 0 13 0 71 0 
13 05 01 00 00 01 00 
BT rx_data(7): 13 5 1 0 0 1 0 
13 05 01 00 00 01 00 
BT rx_data(7): 13 5 1 0 0 1 0 

=====================
BT rx2_data(9): 0 20 5 0 1 0 70 0 3 
    L2CAP Connection Response: ID: 1, Dest:70, Source:0, Result:201, Status: ffff
13 05 01 00 00 01 00 
BT rx_data(7): 13 5 1 0 0 1 0 

=====================
BT rx2_data(20): 0 20 10 0 c 0 1 0 3 1 8 0 41 0 71 0 1 0 2 0 
    L2CAP Connection Response: ID: 1, Dest:41, Source:71, Result:1, Status: 2
      Interrupt Response
L2CAP_ConfigRequest called(00 20 10 00 0c 00 01 00 04 01 08 00 41 00 00 00 01 02 ff ff )
    tx_data(bluetooth) 82
tx_data callback (bluetooth): 0 : 0 20 10 0 c 0 1 0 4 1 8 0 41 0 0 0 1 2 ff ff 
13 05 01 00 00 01 00 
BT rx_data(7): 13 5 1 0 0 1 0 

=====================
BT rx2_data(22): 0 20 12 0 e 0 1 0 5 1 a 0 71 0 0 0 0 0 1 2 ff ff 
    L2CAP config Response: ID: 1, Source:71, Flags:0, Result:0, Config: 201
HCI_WRITE_SCAN_ENABLE called(1a 0c 01 02 )
    control callback (bluetooth) 82
    Control callback (bluetooth): 130 : 1a c 1 2 

=====================
BT rx2_data(20): 0 20 10 0 c 0 1 0 4 2 8 0 71 0 0 0 1 2 ff ff 
    L2CAP config Request: ID: 2, Dest:71, Flags:0,  Options: 1 2 ff ff
      Interrupt Configuration request
L2CAP_ConfigResponse called(00 20 12 00 0e 00 01 00 05 02 0a 00 41 00 00 00 00 00 01 02 a0 02 )
0E 04 01 1A 0C 00 
BT rx_data(6): e 4 1 1a c 0 
    Command Completed! 
Write_Scan_enable Completed
    tx_data(bluetooth) 82
tx_data callback (bluetooth): 0 : 0 20 12 0 e 0 1 0 5 2 a 0 41 0 0 0 0 0 1 2 a0 2 
13 05 01 00 00 01 00 
BT rx_data(7): 13 5 1 0 0 1 0 

=====================
BT rx2_data(19): 0 20 f 0 b 0 71 0 a1 1 86 7f 7e 7f 8 10 1 0 0 
HID HDR Data: len: 11, Type: 1
LX: 134, LY: 127, RX: 126, RY: 127 
L-Trig: 0, R-Trig: 0, Trig-Button: 16 
Buttons: 8, PS: 1

Joystick update Rumble/LEDs00 20 24 00 20 00 01 00 52 11 80 20 ff 00 00 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 )
*** Device Bluet a12:1 - connected ***
    tx_data(bluetooth) 82
tx_data callback (bluetooth): 0 : 0 20 24 0 20 0 1 0 52 11 80 20 ff 0 0 0 0 0 ff 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

=====================
BT rx2_data(19): 0 20 f 0 b 0 71 0 a1 1 85 7f 7e 7f 8 10 1 0 0 
HID HDR Data: len: 11, Type: 1
13 05 01 00 00 01 00 
BT rx_data(7): 13 5 1 0 0 1 0

Pretty much the same thing happens with the CSR4.0 dongle. This one doen't seem to want to connect at all: https://www.amazon.com/gp/product/B007Q45EF4/ref=oh_aui_search_asin_title?ie=UTF8&psc=1
 
I see that comes from case #2 of USBHost::enumeration : dev->bDeviceClass = enumbuf[4];

The rest of that is show here:
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

Just looking a bit ...
 
Interesting for the CSR4
Device Descriptor:
12 01 00 02 E0 01 01 40 12 0A 01 00 91 88 00 02 00 01
VendorID = 0A12, ProductID = 0001, Version = 8891
Class/Subclass/Protocol = 224 / 1 / 1
Number of Configurations = 1
enumeration:
enumeration:
Product: CSR8510 A10
For the generic dongle
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:
No product name in this case.

EDIT: Just read your prior post - something must have crossed - for the joystick, I added your code:
Code:
JoystickController claim this=1FFF48E0
BluetoothController claim this=1FFF40C0
	BtCon != 0xe0? dev->bDeviceClass=E0
	BtCon !=1? dev->bDeviceSubClass=1
	BtCon !=0? type=0
Now for the dongle that doesn't work for me I am seeing exactly what you posted in post 54
 
Last edited:
Mike: Looking at your 2 logs - that 'status=' message is annoying - I generally turn that off after each install - though mine is on now too. Pending rewrite of USB and it not having shown anything it seems superDUPERfluous.

I'll focus on getting updated T_3.6 to work with debug_tt - other than info to get my old Bt dongle to work I can't add much there.

I'll test with T_3.6 doing debug_tt out Serial1 to a second Teensy (T_3.6) running EchoBoth [need to update that github to remove the spare println Kurt pointed me to :( ]

There are T4 oddities - may be my hack abuse getting Fault to work or some other half baked WIP as I only had my samples to test against. If I can clean it up on more stable T_3.6 it might get resolved. Also have the option to use Serial USB for data In/Out in the process.
 
Interesting for the CSR4

For the generic dongle
No product name in this case.

EDIT: Just read your prior post - something must have crossed - for the joystick, I added your code:
Code:
JoystickController claim this=1FFF48E0
BluetoothController claim this=1FFF40C0
	BtCon != 0xe0? dev->bDeviceClass=E0
	BtCon !=1? dev->bDeviceSubClass=1
	BtCon !=0? type=0
Now for the dongle that doesn't work for me I am seeing exactly what you posted in post 54

Mike: You have a difference! You pass the "dev->bDeviceClass=E0" test [where mine fails] - but your is failing on "BtCon !=0? type=0".

My Type is 1 - at least after the first instance - it is 1 on the last nine. In the single one posted yours is showing ZERO. Check that on the subsequent prints maybe? If that never goes 1 that will fail from what KurtE noted.
 
Tim: Yeah I know, was going to just delete them. Only left them in because I thought it might say something about he problem.
 
Mike: You have a difference! You pass the "dev->bDeviceClass=E0" test [where mine fails] - but your is failing on "BtCon !=0? type=0".

My Type is 1 - at least after the first instance - it is 1 on the last nine. In the single one posted yours is showing ZERO. Check that on the subsequent prints maybe? If that never goes 1 that will fail from what KurtE noted.

Tim: Think you got it backwards. The test for return false is if is not equal to 0. So if it >0 it returns then it is an error else if its 0, then you are good, so 1 fails the test.
Code:
if (type != 0) return false;

EDIT: Just ordered an XBOX One controller, lets see if we have the same problem with a different controller.
 
Correct - the real test is : if (type != 0) return false;
I knew It would be confusing when I abbreviated the debug text out … but in my case of 10 instances - the type changes and is only ZERO one time. Though in my case it will always fail with : BtCon != 0xe0? dev->bDeviceClass=FF

So that was really a question about what other values for type might be dumping your dongle - maybe they were all the same ZERO good - so something else failing in your case.
 
Not sure I was clear in my explanation, as usual. I have 3 dongles 2 work (they pass the test) and 1 doesn't. The one that doesn't has the same problem as yours"
Code:
BtCon != 0xe0? dev->bDeviceClass=FF
 
Not sure I was clear in my explanation, as usual. I have 3 dongles 2 work (they pass the test) and 1 doesn't. The one that doesn't has the same problem as yours"
Code:
BtCon != 0xe0? dev->bDeviceClass=FF

opps - okay we are clear now.

I wonder why some are FF and on EO? IIRC - these units I got failed to be useful on the PC's I got them for Win 7 or before - they are too small to throw in a dramatic fashion so they are just sitting around. Bt was always more expensive and other than my phone earpiece/headset (okay I've been through 5-8 of those) it never seemed useful given cheaper wireless mouse/keyboards. But if we can get today's higher data rates and cheap dongles it seems like it is worth exploring for expansion opprotunities.
 
So that then boils down to : Base Class FFh (Vendor Specific)
For my devices I can just toss them as they are not generic/compliant and probably so old there isn't a family of them alive that is worth supporting - and they should have moved to non-Vendor specific.

debug_tt: Something Odd in the saved pointers to strings I was using well on T4 (mostly except random acsii showing sometimes cycling over the first chars with the rest fine) with a bit of issue.

Worse on T_3.6: assumed the __func__ allocated const string space and gave a valid pointer to that - but it isn't a usable *ptr when stored at call.

I'll bail on saving __func__ so adding _tt doesn't break/complicate things - having a usable __LINE__ # is close enough for starters. I have a way for user to add unique string to confirm to work.
 
Stymied by the printing failure on Serial1 on both MCU's - I'll need to touch each print and use something more consistent and hopefully root out the problem. In some cases I'm calling printf and that may be where the issue comes in.

I ran this loop in setup() and twice more {once with passed ptr* and once Serial1} in the called debBegin_tt() code and all lines printed in whole and in good shape! No delay or flush - no funny chars or truncated output.
Code:
 int ii;
  for ( ii = 0; ii < 19; ii++ )
  {
    SERIAL_tt.print("\n" __FILE__ " " __DATE__ " " __TIME__);
    SERIAL_tt.print("\t********\t T4 connected Serial_1 *******  ONE\n");
    SERIAL_tt.println(ii);
  }

... Odd … :confused: - on T_3.6 the Serial1 was failing to garbage - decided to halve the baud to 921600, then get alternate garbage on Serial1. Moved it to pass " debBegin_tt( (HardwareSerial*)&Serial, ... " and that works perfectly on T_3.6?

Oddly the Teensy taking Serial1 on T4 would need reset at times?

Did other stuff first without changing the code to no effect ...

I had already turned off the __func__ passing in general instead passing #b of the #2 param for deb_tt() and in #a case of debTrace_tt() and it shows the text of the 'rvalue' used as the param so that should be a unique line/func id.

Perhaps I'm just blowing out a buffer? But Tx should block? and Rx is bigger and the Teensy on the other end - just changed EchoBoth to HWSERIAL.readBytes( buff, ii ); and still losing bytes and getting garbage. Also added .flush() and that didn't help. It works so well on USB Serial …

Bumped Tx and Rx buffers to 200 bytes on test Teensy and the Echo Teensy … still garbage and lost chars. Odd similar ugliness on both MCU's … no problem going to USB Serial.
 
Hope it turns out to be something simple. Like yesterday I did a quick and dirty change of a lot of the printing code int he library to use:
#define USBHOST_PRINT_DEBUG
#define USBHDBGSerial Serial1

And I did a global replace of Serial. to USBHDGSerial. Then figured out I screwed up and undid it in most of the .ino files...
Nothing printed to Serial1, until I did a Serial1.begin(....) Then got lots of output on Serial1...

Currently I am using KiTTy program (derivative of PuTTy) to see this output, currently at 115200. I was going to try using TyCommander (0.8.8-25-gd93a283) to do this, but I don't know how to set the baud rate here...

Note: I am using one of my Serial dongles to handle this.
 
Did some debug prints from the T4 with the USB Host shield (lib 2.0), connects no problem, and am attaching the dump.View attachment 15946
Maybe it will help with the debugging.

I should probably learn more about using the host shield 2... I never had it working with Teensy, but did have it working plugged into some AVR Arduino. I think I had it on a Mega...

I suspect I am either missing something simple and/or there is a state that I am not detecting. Something like you tell the device to reset and then ask it for information and it may respond it is busy, and then you need to ask (or tell) it again....
 
How should Bluetooth work on Teensy USBHost?

@Paul, @defragster, @mjs513 and other:
Once we hopefully figure out how to get these PS4 (and hopefully PS3) and the like working reasonably, I think we may then need to take a step back and figure out how the code should really work and also extend it.

That is I don't like having two constructors (sort of borrowed from Host shield 2), one that says to do a binding and another to hopefully just use the binding. You typically don't have to reprogram your radio in your car to tell it you wish to pair a new cell phone to it, you instead issue a command, or push a button or... And then the system will look for some amount of time for a new binding request or search for devices that are wanting to bind. And again the pin number is not some hard coded thing, sometimes a device does have a hard coded one, other times the UI will ask for one...

And more importantly and difficult: The Bluetooth code should be able to work with multiple devices. It has been awhile since I looked at some of the details, like how much of this is/should be remembered within the dongle itself, but once you bind/trust a device, it should know that and use that information...

And hopefully we should be able to use multiple devices at the same time... That is on my computer right now I have a Bluetooth keyboard (Kenisis Freestyle2 Blue), which is pretty good and a logitech bluetooth mouse which I sort of hate... Both of these work on my computer at the same time. Should hopefully be able to do the same with Teensy host. This will imply the code needs to act sort of like the HUB and may have a max number of conversations (maybe 4). There are probably hardware limits.... But this may imply that some of the data within the bluetooth code needs to be arrays and some of the code may have to figure out which connection...

Does this make sense?
 
@KurtE and @defragster

Wow. Guess I can't sleep anymore :)

Tim-Kurt: Last night I tried replacing all Serial prints in Bluetooth and usbhost_t36 with Serial1 but couldn't get anything to print - even had Serial1.begin. Maybe I missed something. Even tried debug_tt on Serial1 and saw the same thing - nothing printed.

Kurt: I have been using the usb host mini without a problem on the Teensy for years. It works with the dongle that work with USBhost. One thing I remember reading is that it should be an EDR dongle? The teensy page on the usb mini is a good source. The one possibility is that maybe when you were working with it, it didn't support the teensy?

Just looking at the UHS2.0 library - think what you need to look at is in bth.cpp. The code addresses the issue if their is a hub within the dongle, which then does something else - never looked at that one.
 
Hi Mike,

I will include a hacked up version of the code, that outputs the majority of stuff to Serial1...
I may have turned off the main library printing, but I think I have it turned on in Bluetooth stuff.

May need to see if I can find my mini shield... Do you know which one you have is? If I am going to get another one, might as well get one known to work :D

Actually the one I have I believe is this one: https://smile.amazon.com/gp/product/B01EWW9R1E

Wonder if I should try again...
 

Attachments

  • USBHost_t36.zip
    136.8 KB · Views: 94
Last edited:
Hi Kurt. Believe it or not I got the one direct from tkelectronics as well as a couple of knock offs. The problem with the Arduino style shield is that the spi comes from 6 pin header not the edge connectors. So if you use that one just take the connections from the header pin to the T4. I heard the Sparkfun works but never tried it. I always run the board_qc.ino just to make sure I have the connections right.

EDIT: I tried your hacked up version on the T4 and T3.6 and both worked, i.e., the debug stuff went to Serial1. :)

EDIT: Going back to your original lib and see if the stuff I added specific to PS4 is causing a problem
 
Last edited:
Back
Top