T3.6 USB Host - Bluetooth

Tim
That cycle connect/disconnect I have seen before so yeah probably what happens. I don't have the same device so I can't tell if its just the device. I have this keyboard that I tested with: https://www.amazon.com/gp/product/B00EZL1IQA/ref=oh_aui_search_asin_title?ie=UTF8&psc=1 and that one worked without an issue.

@KurtE and Tim
Been trying my damnest to get rumble to work - no such luck. It seems that after I send the command I get a bunch back but don't know what it means or even where to look:
Code:
update Rumble/LEDs
0b 20 53 00 4f 00 42 00 52 11 80 00 ff 00 
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 800 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 800 00 00 00 00 00 00 00 00 )

=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 80 7d 7f 7e 8 4 0 e9 0 
HID HDR Data: len: 11, Type: 1
tx_data callback (bluetooth): 0 : b 20 53 0 4f 0 42 0 52 11 80 0 ff 0 0 fe 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Leaving Serial1 at 115200 is a pain. Almost feel like going back to the T$
 
@... ;) - 115200 there is no hard rule for that... It is simply what I put into the sketch Serial1.begin(115200); We could just as easily do Serial1.begin(2000000)
Assuming that the dongle and whatever software on the other side can handle it... Or simply define it again as Serial...

Code:
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 800 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 800 00 00 00 00 00 00 00 00 )

=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 80 7d 7f 7e 8 4 0 e9 0

The code is in: BluetoothController::rx2_data

Not sure of the multiple messages here where not all of them are going off to process the A1 Hid Data... might need to debug some more...
 
Hardware under test for Teensy devices with USB_HOST ports

<First pass to get hardware list ???>

StatusUSB TypeReferenceComment
GoodBt DongleCSR 4.0 Bt DongleTim , Kurt
0xFF Bypass GoodBt DonglePANBT400 Plugable Bt 4.0 Low EnergyTim
ConnectsBt MMLogitech M557 Bluetooth MouseTim
Bt Block, USB SpewsPS3_Joy Bt&USBJAMSWALL PS3 ControllerTim
Connects most worksBt KBD/M/TchRii i8+ BT Wireless Touchpad KeyboardTim
Initial ConnectBt KBDLogitech Bt Multi-Device Keyboard K480Tim
Rejected?BtMSFT BT Keyboard 6000Tim
...
StatusUSB TypeReferenceComment
 
Last edited:
@... ;) - 115200 there is no hard rule for that... It is simply what I put into the sketch Serial1.begin(115200); We could just as easily do Serial1.begin(2000000)
Assuming that the dongle and whatever software on the other side can handle it... Or simply define it again as Serial...

Code:
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 800 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 800 00 00 00 00 00 00 00 00 )

=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 80 7d 7f 7e 8 4 0 e9 0

The code is in: BluetoothController::rx2_data

Not sure of the multiple messages here where not all of them are going off to process the A1 Hid Data... might need to debug some more...
I'm using a T3.2 on serial1 and tried boosting it up to like 1000000 but just got jibberish on the T3.2. Maybe its just the T3.2

Going to do a little more tomorrow with Serial and Serial1 and those messages.

Tim. Sent Robin the email.
 
I just updated Defragster/T4_demo/tree/master/EchoBoth

It has the 16x115200 baud of 1843200 and works for me on the two T_3.1's running against the T4. For the T_3.6 USB Host unit I am using a T_3.6 because it had the right pins - and my T_3.0 is still taped to the GPS unit breadboard from way back :)

NOTE: The only thing COOL about 1843200 is that I hardcode those values in T4's Print_init code so I can used the same EchoCode.

In the new version to be sure I stopped doing byte transfers and changed to read>write of .available in case that helps.

The last trouble I noted was not seeing the Serial# I was using on the T_3.6 Host unit was redefined to the slower rate just below that. Though from what I'm seeing - something may very well be zapping Serial code.

I started the Hardware under test for Teensy devices with USB_HOST ports message with a list of the hardware I had handy - Kurt you can add or reformat as desired - I just stole the table format from the T4 msg and picked some words and added some links. Mike when Robin processes your Sr+'ness you can add there so we can track what works to test or buy. If that looks to work - we can get a link in a first page post to jump to it.

<note> Just for reference the debTrace_tt timing I just did was 83 cycles between two inline calls - 90 cycles between calls in for loop. Doing a text and number print between logs between two traces and taking off 83 shows the two prints taking 430 cycles - so it does save time and doesn't violate _isr rules or otherwise busy the CPU. And for fun a single print (text and number) with the printf_tt code takes 17K cycles!
 
Last edited:
One reason the Fault code went to lockup was I removed the one call to tickle the Serial[array]. I'm working to enable that on T_3.6 and restoring that behavior to get back to where it was before the T$ hacking and I just got the CPU into AutoReboot mode.

The handy thing about having the setup call the debug_tt library is where it posts this notice of why the CPU restarted during the debBegin_tt() call:
>>> Reason for 'reset': 200 CoreLockup :: done Reason

There is similar info on the T$ that hasn't been collected yet - I have the sheets here in my pile somewhere.

… now to see what the 'tickle monster' has done :)

<edit> - the funny recursive thing is working on code to debug and having it show where it is when it dies ...
 
Last edited:
Figured out why T_3.6 was losing Serial output! I had only ever tested on USB Serial before going to the Pointer code.

Embedded in PJRC's FAULT code register dump is this "UNNEEDED" Serial port setup!
SIM_SCGC4 |= 0x00000400;
UART0_BDH = 0;
UART0_BDL = 26; // 115200 at 48 MHz
UART0_C2 = UART_C2_TE;
PORTB_PCR17 = PORT_PCR_MUX(3);

With that removed debug_tt is safe and informative to fault with! It show the initial code path log I created and allows calling the Debug_Dump() code in sketch to print more info, allows Restart or Bootloader and also stays active for Auto Upload to work.

I should have that up when you guys read this in the morning.

<Funny Story>: Decided to try it on T4 - Frank made a linkage edit to the FaultHandler I wanted to test again before I did Pull Request. So T4 on USB - and debug_tt on Serial1 and PJRC spew on Serial4.

I run the same Trace example … debug_tt output is somehow going OUT Serial4 and I have to enter the input on Serial1. … hopefully just an #ifdef I did before I renamed PJRC debug_printf code … but really FUNNY/odd.
 
Last edited:
Posted this note on T4 thread for updated debug_tt:
I just pushed up a working github.com/Defragster/T4_demo/.../debug_tt. It allows checking code flow to a failure point etc, and Trace records - even in _isr()'s to print later.
Two working/updated examples are xxx_tt. It works on T_3.6. On T4 it works the same unless the processor is faulted. With UART Serial.flush() 'edit' then the prompt code is just a tease because Serial input is broken. USB needs updated for input - but will display on output.

Found the source of the funny print - Using the PJRC printf code it was hardcoded to Serial4 under 1052 ifdef that I left alone to focus on T_3.6 use - then compiling T$ anything using that func() wrote Serial4.
 
I tried the 2000000 on serial1, with a usb to serial adapter and it was working...

@KurtE: Used Tim's echoboth on the T3.2 and reset Serial1.begin to match. Now it works. No idea what I did yesterday. Anyway, retested this morning, the extra messages disappeared - the 3.2 just wasn't keeping up so it was overwriting itself.

To be honest, I am just about out of ideas on getting BT rumble working, but I don't like giving up - has to be something I'm missing
 
@mjs513 - Not sure, I did a little hacking yesterday, of trying different channels, like trying to use one directly out of the BT structure, like: control_scid_

Did not help. Wondering about the function on host shield:
Code:
        void enable_sixaxis() { // Command used to make the PS4 controller send out the entire output report
                uint8_t buf[2];
                buf[0] = 0x43; // HID BT Get_report (0x40) | Report Type (Feature 0x03)
                buf[1] = 0x02; // Report ID

                HID_Command(buf, 2);
        };
Thinking of figuring out how to add on code for BT, that when the standard BT init code is done, allow the connected device to send out additional init messages... Like this one...

Then turned on some more debug stuff and in debug window saw things like:
Code:
Joystick update Rumble/LEDs
sendL2CapCommand: 2001ff18 79 41 0 : control: 40
    tx_data(bluetooth) 78
13 05 01 0B 00 02 00
The first message you have seen, the second one I put into the forwarder sendL2CapCommand - first 4 numbers are the parameters passed in control is value of control_lcid_, earlier I had it also printing out control_dcid_, interrupt_lcid_...

The next message tx_data(bluetooth) is where the system knows that the message was outputs... But I am trying to figure out the number 78 here (last night it was 82), never mind, was looking at wrong variable... But...

I am thinking there may need to be one or two more members in the BTHid class to maybe know when the main BT init code is done on the device. Also maybe add a parameter onto the function you call to send a message (sendL2CapCommand) you can specify a logical state number for this message, and when the message completes maybe call back to you to let you know it is done, as you then may have another one to send...

There also may turn out to be code ordering issues. I ran into this in past in USB code here, where you have to let the system acknowledge the previous message or the like before you can actually post another command...
 
@mjs513 - Not sure, I did a little hacking yesterday, of trying different channels, like trying to use one directly out of the BT structure, like: control_scid_

Did not help. Wondering about the function on host shield:
Code:
        void enable_sixaxis() { // Command used to make the PS4 controller send out the entire output report
                uint8_t buf[2];
                buf[0] = 0x43; // HID BT Get_report (0x40) | Report Type (Feature 0x03)
                buf[1] = 0x02; // Report ID

                HID_Command(buf, 2);
        };
Thinking of figuring out how to add on code for BT, that when the standard BT init code is done, allow the connected device to send out additional init messages... Like this one...

Then turned on some more debug stuff and in debug window saw things like:
Code:
Joystick update Rumble/LEDs
sendL2CapCommand: 2001ff18 79 41 0 : control: 40
    tx_data(bluetooth) 78
13 05 01 0B 00 02 00
The first message you have seen, the second one I put into the forwarder sendL2CapCommand - first 4 numbers are the parameters passed in control is value of control_lcid_, earlier I had it also printing out control_dcid_, interrupt_lcid_...

The next message tx_data(bluetooth) is where the system knows that the message was outputs... But I am trying to figure out the number 78 here (last night it was 82), never mind, was looking at wrong variable... But...

I am thinking there may need to be one or two more members in the BTHid class to maybe know when the main BT init code is done on the device. Also maybe add a parameter onto the function you call to send a message (sendL2CapCommand) you can specify a logical state number for this message, and when the message completes maybe call back to you to let you know it is done, as you then may have another one to send...

There also may turn out to be code ordering issues. I ran into this in past in USB code here, where you have to let the system acknowledge the previous message or the like before you can actually post another command...

I know what you mean - I tried a few different channels as well but no luck. I even tried implement the sixaxis code like you did - but I put in a different spot without any luck.

Here is a data point for you though, in looking through the UHS2 code the scid comes from function "BTHID::ACLData(uint8_t* l2capinbuf)", specifically this "if" block:
Code:
} else if(l2capinbuf[8] == L2CAP_CMD_CONNECTION_RESPONSE) {
                                if(((l2capinbuf[16] | (l2capinbuf[17] << 8)) == 0x0000) && ((l2capinbuf[18] | (l2capinbuf[19] << 8)) == SUCCESSFUL)) { // Success
                                        if(l2capinbuf[14] == control_dcid[0] && l2capinbuf[15] == control_dcid[1]) {
                                                //Notify(PSTR("\r\nHID Control Connection Complete"), 0x80);
                                                identifier = l2capinbuf[9];
                                                control_scid[0] = l2capinbuf[12];
                                                control_scid[1] = l2capinbuf[13];
                                                l2cap_set_flag(L2CAP_FLAG_CONTROL_CONNECTED);
                                        } else if(l2capinbuf[14] == interrupt_dcid[0] && l2capinbuf[15] == interrupt_dcid[1]) {
                                                //Notify(PSTR("\r\nHID Interrupt Connection Complete"), 0x80);
                                                identifier = l2capinbuf[9];
                                                interrupt_scid[0] = l2capinbuf[12];
                                                interrupt_scid[1] = l2capinbuf[13];
                                                l2cap_set_flag(L2CAP_FLAG_INTERRUPT_CONNECTED);
                                        }
                                }
                        } else if(l2capinbuf[8] == L2CAP_CMD_CONNECTION_REQUEST) {
......
                                if((l2capinbuf[12] | (l2capinbuf[13] << 8)) == HID_CTRL_PSM) {
                                        identifier = l2capinbuf[9];
                                        control_scid[0] = l2capinbuf[14];
                                        control_scid[1] = l2capinbuf[15];
                                        l2cap_set_flag(L2CAP_FLAG_CONNECTION_CONTROL_REQUEST);
                                } else if((l2capinbuf[12] | (l2capinbuf[13] << 8)) == HID_INTR_PSM) {
                                        identifier = l2capinbuf[9];
                                        interrupt_scid[0] = l2capinbuf[14];
                                        interrupt_scid[1] = l2capinbuf[15];
                                        l2cap_set_flag(L2CAP_FLAG_CONNECTION_INTERRUPT_REQUEST);
                                }
                        }


I was just looking through the code to see if I could pull the equivalent scid. I was just getting ready to test this to see if I could get it:
Code:
// l2cap support functions. 
void BluetoothController::sendl2cap_ConnectionResponse(uint16_t handle, uint8_t rxid, uint16_t dcid, uint16_t scid, uint8_t result) {
 	uint8_t l2capbuf[12];
    l2capbuf[0] = L2CAP_CMD_CONNECTION_RESPONSE; // Code
    l2capbuf[1] = rxid; // Identifier
    l2capbuf[2] = 0x08; // Length
    l2capbuf[3] = 0x00;
    l2capbuf[4] = dcid & 0xff; // Destination CID
    l2capbuf[5] = dcid >> 8;
    l2capbuf[6] = scid & 0xff; // Source CID
    l2capbuf[7] = scid >> 8;
    l2capbuf[8] = result; // Result: Pending or Success
    l2capbuf[9] = 0x00;
    l2capbuf[10] = 0x00; // No further information
    l2capbuf[11] = 0x00;

	DBGPrintf("L2CAP_CMD_CONNECTION_RESPONSE called(");
	DBGPrintf("SCID[1/2] %02x, %02x\n", scid & 0xff, scid >> 8);
    sendL2CapCommand(handle, l2capbuf, sizeof(l2capbuf));
}



void BluetoothController::sendl2cap_ConnectionRequest(uint16_t handle, uint8_t rxid, uint16_t scid, uint16_t psm) {
 	uint8_t l2capbuf[8];
    l2capbuf[0] = L2CAP_CMD_CONNECTION_REQUEST; // Code
    l2capbuf[1] = rxid; // Identifier
    l2capbuf[2] = 0x04; // Length
    l2capbuf[3] = 0x00;
    l2capbuf[4] = (uint8_t)(psm & 0xff); // PSM
    l2capbuf[5] = (uint8_t)(psm >> 8);
    l2capbuf[6] = scid & 0xff; // Source CID
    l2capbuf[7] = (scid >> 8) & 0xff;

	DBGPrintf("`ConnectionRequest called(");
	DBGPrintf("SCID[1/2] %02x, %02x\n", scid & 0xff, scid >> 8);
    sendL2CapCommand(handle, l2capbuf, sizeof(l2capbuf));
}
I added the extra DBGPrinf's.

But I have a couple of things to finish up. Like salting outside - a little icy after I shovel the slush from yesterdays storm - not much - just enough to be annoying. Also waiting for the repair service on the washer/dryer (have to see how much that is going to be, not sure if its covered under warranty).

Of course, the scid may not be an issue, but something like you described in the last 2 paragraphs.

EDIT: Hmm. those functions never seemed to be called - are those only for wired connections? [CORRECTION] Nevermind edited the wrong file :(
 
Last edited:
@KurtE

Just noticed something strange. In BluetoothController::sendl2cap_ConnectionResponse you have l2capbuf[7] = scid >> 8; but in sendl2cap_ConnectionRequest you have (scid >> 8) & 0xff.

Just want to make sure this is correct?

EDIT: Do have one question - after I do a sendl2CapCommand for the rumble message should I see a tx_data callback - because I am not. Are you?
 
Last edited:
Probably does not matter if we &0xff or not, as probably uint16_t value anyway getting assigned to a uint8_t... Probably just being anal...

The call back message, depends on debug settings. The one I showed in last posting was for the global USBHost debug...
If you also and/or turn on verbose debug in the bluetooth file you might see something like:
Code:
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 7k update Rumble/LEDs
[COLOR="#FF0000"]sendL2CapCommand: 2001ff18 79 41 0 : cont[/COLOR]
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 [COLOR="#FF0000"]7rol: 40[/COLOR]
0b 20 53 00 4f 00 41 00 52 11 80 00 ff 00 00 00 ff 00
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 700 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 700 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 70 00 00 00 00 00 )

=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 7f 7b 82 7c 8 8 0 0 ff
HID HDR Data: len: 11, Type: 1
13 05 01 0B 00 02 00
BT rx_data(7): 13 5 1 b 0 2 0
    tx_data(bluetooth) 82
tx_data callback (bluetooth): 0 : b 20 53 0 4f 0 41 0 52 11 80 0 ff 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 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

=====================
Again showing the multiple rx2_data messages...
The verbose showed the data that maybe was sent...
Also interesting with messages being interlaced... That is probably getting ISR data interspersed ... As I show the breakup of one message...
I am curious about maybe ... I was not seeing that yesterday, but was running debug output at 2k instead of 115200, will switchback, but also as a test, maybe just increase the size of the Serial1 Tx buffer...

Code:
uint8_t Serial1_write_buffer[1024];
...
 Serial1.addStorageForWrite(Serial1_write_buffer, sizeof(Serial1_write_buffer));
  Serial1.begin(115200);

Then get proper output... And hopefully avoid issues where we do TX, which hangs until space is available, which screws up lots of stuff...

Code:
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 7f 7d 82 7d 8 8 0 0 ff
HID HDR Data: len: 11, Type: 1
Joystick update Rumble/LEDs
sendL2CapCommand: 2001ff18 79 41 0 : control: 40
0b 20 53 00 4f 00 41 00 52 11 80 00 ff 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 )

=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 7f 7d 81 7c 8 8 0 0 ff
HID HDR Data: len: 11, Type: 1
    tx_data(bluetooth) 82
tx_data callback (bluetooth): 0 : b 20 53 0 4f 0 41 0 52 11 80 0 ff 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 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

=====================
Which looks a bit cleaner
 
Hi Kurt
Ok = looked a little closer again, after your post, and yep I am seeing it = like you said its getting interspersed. I didn't notice it before. I pretty much tried everything so it has to be something else at this point to get Rumble to work. I tried several scid's I saw but no luck. But not sure what else to try.

Oh, before I forget, did you get PS4 to register as "joysticktype". Right now its coming back as 0.
 
Hi Mike and Tim,

Just got back, went to PMB and picked up a few more things like the replacement Host shield mini... Need to get out soldering Iron.

Also cheap bluetooth mouse (TECKNET)... Thought I would try it out and see if it registers at all...
 
Hi Kurt
Enjoy your new toys. Sounds like you got the same mouse I just ordered from amazon.

BTW. What mini did you get?
 
The mouse registers, when I use the register new...) but errors out if I try with out the pin form... Need to investigate some...

But will hack in some code to handle the data now ...
Code:
=====================
BT rx2_data(14): b 20 a 0 6 0 71 0 a1 2 0 59 8 0
HID HDR Data: len: 6, Type: 2
MouseController::process_bluetooth_HID_data 5
  Mouse Data: 02 00 59 08 00

=====================
BT rx2_data(14): b 20 a 0 6 0 71 0 a1 2 0 47 7 0
HID HDR Data: len: 6, Type: 2
MouseController::process_bluetooth_HID_data 5
  Mouse Data: 02 00 47 07 00

=====================
BT rx2_data(14): b 20 a 0 6 0 71 0 a1 2 0 3a 7 0
HID HDR Data: len: 6, Type: 2
MouseController::process_bluetooth_HID_data 5
  Mouse Data: 02 00 3A 07 00

=====================

But if it times out, then get into the error state again, need to figure that part out as well... Always new challenges




Mini - HiLetGo: https://smile.amazon.com/gp/product/B01EWW9R1E/
 
TECKNET - that sounds fancy! They seem to have a number of devices and not as cheap as the name sounds. Speaking of Teck devices I found my Bt 'Microsoft Sculpt Touch Mouse' and it was found and connected with the JoyStickBt sketch.

After Connect like other things - powering mouse off then back on results in a stream of spew leading to disconnect. And that repeats each time it gets moved.

I followed Mike's PS4 link - has notes on PS3 - prior post here makes sense with other links I followed. It seems Sony rule is plug in once to pair controller - then it can run wireless on that station until it is associated with another station.

Came across the note from last year about the Bt LE bug - during association when getting a shared key it seems there was a bug with an in range man in the middle being able to complete the Bt association leaving it with credentials. I found that wondering if a Bt snoop/sniff might yield some device specific protocol details - but seems unlikely.

Is there a readable overview doc on the Host USB/Bt connect process? Given my understanding of drivers (the CSR dongle was packed with a mini CD) - it seems that complete and unique response to support all features of a given device would take intimate knowledge beyond just recognizing and recording it as 'connected'.

Followed SPI Host adapter above and saw this comment on aZon:
nero 5.0 out of 5 stars June 29, 2017
Worked perfectly using a Teensy 3.6, i'm using it as a midi host, i didn't modify it to provide 5v since the device i'm connecting doesn't need USB power. Either way i'm happy it worked out so well
 
Tecknet mouse is sort of working... That is we are now getting mouse events out. I pushed up some changes to the mouse.cpp file to handle the data.

When I try it without having to rebind... I get some debug output that looks like:

Code:
BT rx_data(12): 4 a 3e 58 b3 26 2c dc 80 5 0 1
    Event: Incoming Connect -  3e:58:b3:26:2c:dc CL:580 LT:1
      Peripheral device
        Mouse
BluetoothController::find_driver  driver 20003b58
Keyboard Controller::claim_bluetooth - Class 580
  driver 20003dd8
Keyboard Controller::claim_bluetooth - Class 580
  driver 20005bec
MouseController Controller::claim_bluetooth - Class 580
MouseController::claim_bluetooth TRUE
    *** Claimed ***
HCI_OP_REMOTE_NAME_REQ called (19 04 0a 3e 58 b3 26 2c dc 01 00 00 00 )
    Control callback (bluetooth): 0 : 19 4 a 3e 58 b3 26 2c dc 1 0 0 0
BT rx_data(6): f 4 0 1 19 4
    Command 419 Status 0
BT rx_data(16): 7 ff 0 3e 58 b3 26 2c dc 42 4d 33 30 58 20 6d
BT rx_data(16): 6f 75 73 65 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(1): 0
    Event: handle_hci_remote_name_complete(0)
    Remote Name: BM30X mouse
HCI_OP_ACCEPT_CONN_REQ called (09 04 07 3e 58 b3 26 2c dc 00 )
    Control callback (bluetooth): 0 : 9 4 7 3e 58 b3 26 2c dc 0
BT rx_data(6): f 4 0 1 9 4
    Command 409 Status 0
BT rx_data(10): 12 8 0 3e 58 b3 26 2c dc 0
BT rx_data(13): 3 b 0 b 0 3e 58 b3 26 2c dc 1 0
    Connection Complete - ST:0 LH:b
BT rx_data(5): 1b 3 b 0 5

=====================
BT rx2_data(16): b 20 c 0 8 0 1 0 2 2 4 0 11 0 42 0
    L2CAP Connection Request: ID: 2, PSM: 11, SCID: 42
L2CAP_CMD_CONNECTION_RESPONSE called(0b 20 10 00 0c 00 01 00 03 02 08 00 70 00 42 00 01 00 00 00 )
tx_data callback (bluetooth): 201 : b 20 10 0 c 0 1 0 3 2 8 0 70 0 42 0 1 0 0 0
L2CAP_CMD_CONNECTION_RESPONSE called(0b 20 10 00 0c 00 01 00 03 02 08 00 70 00 42 00 00 00 00 00 )
tx_data callback (bluetooth): 202 : b 20 10 0 c 0 1 0 3 2 8 0 70 0 42 0 0 0 0 0
L2CAP_ConfigRequest called(0b 20 10 00 0c 00 01 00 04 03 08 00 42 00 00 00 01 02 ff ff )
tx_data callback (bluetooth): 0 : b 20 10 0 c 0 1 0 4 3 8 0 42 0 0 0 1 2 ff ff

=====================
BT rx2_data(20): b 20 10 0 c 0 1 0 4 3 8 0 70 0 0 0 1 2 30 0
    L2CAP config Request: ID: 3, Dest:70, Flags:0,  Options: 1 2 30 0
      Control Configuration request
L2CAP_ConfigResponse called(0b 20 12 00 0e 00 01 00 05 03 0a 00 42 00 00 00 00 00 01 02 a0 02 )
BT rx_data(7): 13 5 1 b 0 2 0
tx_data callback (bluetooth): 0 : b 20 12 0 e 0 1 0 5 3 a 0 42 0 0 0 0 0 1 2 a0 2

=====================
BT rx2_data(22): b 20 12 0 e 0 1 0 5 3 a 0 70 0 0 0 0 0 1 2 30 0
    L2CAP config Response: ID: 3, Source:70, Flags:0, Result:0, Config: 201
Set HID Protocol 0 (0b 20 05 00 01 00 42 00 70 )
BT rx_data(7): 13 5 1 b 0 2 0
tx_data callback (bluetooth): 200 : b 20 5 0 1 0 42 0 70
`ConnectionRequest called(0b 20 0c 00 08 00 01 00 02 04 04 00 13 00 71 00 )

=====================
BT rx2_data(16): b 20 c 0 8 0 1 0 2 4 4 0 13 0 43 0
    L2CAP Connection Request: ID: 4, PSM: 13, SCID: 43
L2CAP_CMD_CONNECTION_RESPONSE called(0b 20 10 00 0c 00 01 00 03 04 08 00 70 00 43 00 01 00 00 00 )
BT rx_data(7): 13 5 1 b 0 2 0
tx_data callback (bluetooth): 201 : b 20 10 0 c 0 1 0 3 4 8 0 70 0 43 0
L2CAP_CMD_CONNECTION_RESPONSE called(0b 20 10 00 0c 00 01 00 03 04 08 00 70 00 43 00 00 00 00 00 )
tx_data callback (bluetooth): 202 : b 20 10 0 c 0 1 0 3 4 8 0 70 0 43 0 0 0 0 0
L2CAP_ConfigRequest called(0b 20 10 00 0c 00 01 00 04 05 08 00 43 00 00 00 01 02 ff ff )
BT rx_data(7): 13 5 1 b 0 2 0
tx_data callback (bluetooth): 0 : b 20 10 0 c 0 1 0 4 5 8 0 43 0 0 0 1 2 ff ff
tx_data callback (bluetooth): 0 : b 20 10 0 c 0 1 0 4 5 8 0 43 0 0 0 1 2 ff ff

=====================
BT rx2_data(9): b 20 5 0 1 0 70 0 0

=====================
BT rx2_data(20): b 20 10 0 c 0 1 0 3 4 8 0 41 0 71 0 4 0 0 0
    L2CAP Connection Response: ID: 4, Dest:41, Source:71, Result:4, Status: 0
      Interrupt Response
L2CAP_ConfigRequest called(0b 20 10 00 0c 00 01 00 04 05 08 00 41 00 00 00 01 02 ff ff )

=====================
BT rx2_data(16): b 20 c 0 8 0 1 0 6 5 4 0 70 0 42 0
    L2CAP disconnect request: ID: 5, Length:4, Dest:70, Source:42
BT rx_data(7): 13 5 1 b 0 2 0
tx_data callback (bluetooth): 0 : b 20 10 0 c 0 1 0 4 5 8 0 41 0 0 0 1 2 ff ff

=====================
BT rx2_data(18): b 20 e 0 a 0 1 0 1 5 6 0 2 0 0 0 0 0
    L2CAP command reject: ID: 5, length:6, Reason:2,  Data: 0 0
BT rx_data(6): 5 4 0 b 0 13
    Event: HCI Disconnect complete(0): handle: b, reason:13
BT rx_data(12): 4 a 3e 58 b3 26 2c dc 80 5 0 1
    Event: Incoming Connect -  3e:58:b3:26:2c:dc CL:580 LT:1
      Peripheral device
        Mouse
BluetoothController::find_driver  driver 20003b58
Keyboard Controller::claim_bluetooth - Class 580
  driver 20003dd8
Keyboard Controller::claim_bluetooth - Class 580
  driver 20005bec
MouseController Controller::claim_bluetooth - Class 580
MouseController::claim_bluetooth TRUE
    *** Claimed ***
HCI_OP_REMOTE_NAME_REQ called (19 04 0a 3e 58 b3 26 2c dc 01 00 00 00 )
    Control callback (bluetooth): 0 : 19 4 a 3e 58 b3 26 2c dc 1 0 0 0
BT rx_data(6): f 4 0 1 19 4
    Command 419 Status 0
BT rx_data(16): 7 ff 0 3e 58 b3 26 2c dc 42 4d 33 30 58 20 6d
BT rx_data(16): 6f 75 73 65 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
BT rx_data(1): 0
    Event: handle_hci_remote_name_complete(0)
    Remote Name: BM30X mouse
HCI_OP_ACCEPT_CONN_REQ called (09 04 07 3e 58 b3 26 2c dc 00 )
    Control callback (bluetooth): 0 : 9 4 7 3e 58 b3 26 2c dc 0
BT rx_data(6): f 4 0 1 9 4
    Command 409 Status 0
BT rx_data(10): 12 8 0 3e 58 b3 26 2c dc 0
BT rx_data(13): 3 b 0 c 0 3e 58 b3 26 2c dc 1 0
    Connection Complete - ST:0 LH:c
BT rx_data(5): 1b 3 c 0 5

=====================
BT rx2_data(16): c 20 c 0 8 0 1 0 2 2 4 0 11 0 45 0
    L2CAP Connection Request: ID: 2, PSM: 11, SCID: 45
L2CAP_CMD_CONNECTION_RESPONSE called(0c 20 10 00 0c 00 01 00 03 02 08 00 70 00 45 00 01 00 00 00 )
tx_data callback (bluetooth): 201 : c 20 10 0 c 0 1 0 3 2 8 0 70 0 45 0 1 0 0 0
L2CAP_CMD_CONNECTION_RESPONSE called(0c 20 10 00 0c 00 01 00 03 02 08 00 70 00 45 00 00 00 00 00 )
tx_data callback (bluetooth): 202 : c 20 10 0 c 0 1 0 3 2 8 0 70 0 45 0 0 0 0 0
L2CAP_ConfigRequest called(0c 20 10 00 0c 00 01 00 04 03 08 00 45 00 00 00 01 02 ff ff )
BT rx_data(7): 13 5 1 c 0 2 0
tx_data callback (bluetooth): 0 : c 20 10 0 c 0 1 0 4 3 8 0 45 0 0 0 1 2 ff ff

=====================
BT rx2_data(20): c 20 10 0 c 0 1 0 4 3 8 0 70 0 0 0 1 2 30 0
    L2CAP config Request: ID: 3, Dest:70, Flags:0,  Options: 1 2 30 0
      Control Configuration request
L2CAP_ConfigResponse called(0c 20 12 00 0e 00 01 00 05 03 0a 00 45 00 00 00 00 00 01 02 a0 02 )

=====================
BT rx2_data(22): c 20 12 0 e 0 1 0 5 3 a 0 70 0 0 0 0 0 1 2 30 0
    L2CAP config Response: ID: 3, Source:70, Flags:0, Result:0, Config: 201
Set HID Protocol 0 (0c 20 05 00 01 00 45 00 70 )
tx_data callback (bluetooth): 200 : c 20 5 0 1 0 45 0 70 3 a 0 45 0 0 0 0 0 1 2 a0 2
`ConnectionRequest called(0c 20 0c 00 08 00 01 00 02 04 04 00 13 00 71 00 )
tx_data callback (bluetooth): 0 : c 20 c 0 8 0 1 0 2
tx_data callback (bluetooth): 0 : c 20 c 0 8 0 1 0 2 4 4 0 13 0 71 0

=====================
BT rx2_data(16): c 20 c 0 8 0 1 0 2 4 4 0 13 0 40 0
    L2CAP Connection Request: ID: 4, PSM: 13, SCID: 40
L2CAP_CMD_CONNECTION_RESPONSE called(0c 20 10 00 0c 00 01 00 03 04 08 00 70 00 40 00 01 00 00 00 )
BT rx_data(7): 13 5 1 c 0 2 0
tx_data callback (bluetooth): 201 : c 20 10 0 c 0 1 0 3 4 8 0 70 0 40 0 1 0 0 0
L2CAP_CMD_CONNECTION_RESPONSE called(0c 20 10 00 0c 00 01 00 03 04 08 00 70 00 40 00 00 00 00 00 )
BT rx_data(7): 13 5 1 c 0 2 0
tx_data callback (bluetooth): 202 : c 20 10 0 c 0 1 0 3 4 8 0 70 0 40 0 0 0 0 0
L2CAP_ConfigRequest called(0c 20 10 00 0c 00 01 00 04 05 08 00 40 00 00 00 01 02 ff ff )
BT rx_data(7): 13 5 1 c 0 2 0
tx_data callback (bluetooth): 0 : c 20 10 0 c 0 1 0 4 5 8 0 40 0 0 0 1 2 ff ff

=====================
BT rx2_data(9): c 20 5 0 1 0 70 0 0

=====================
BT rx2_data(20): c 20 10 0 c 0 1 0 3 4 8 0 44 0 71 0 4 0 0 0
    L2CAP Connection Response: ID: 4, Dest:44, Source:71, Result:4, Status: 0
      Interrupt Response
L2CAP_ConfigRequest called(0c 20 10 00 0c 00 01 00 04 05 08 00 44 00 00 00 01 02 ff ff )

=====================
BT rx2_data(16): c 20 c 0 8 0 1 0 6 5 4 0 70 0 45 0
    L2CAP disconnect request: ID: 5, Length:4, Dest:70, Source:45
BT rx_data(7): 13 5 1 c 0 2 0
tx_data callback (bluetooth): 0 : c 20 10 0 c 0 1 0 4 5 8 0 44 0 0 0 1 2 ff ff

=====================
BT rx2_data(18): c 20 e 0 a 0 1 0 1 5 6 0 2 0 0 0 0 0
    L2CAP command reject: ID: 5, length:6, Reason:2,  Data: 0 0

I just need to walk it through and figure out the rejection and trace to see maybe what others do in this case...

As for USB Host Shield 2, I soldered it up and tried it out and got the same results as the previous one... Run the QC app and it would hang or die at the read revision
Code:
Circuits At Home 2011
USB Host Shield Quality Control Routine
Reading REVISION register... Die revision

So looked around at found the forum posting: https://forum.pjrc.com/threads/53452-USB-Host-Shield-with-Teensy-3-2?p=196967&viewfull=1#post196967
And it did not show anything hooked up to the Reset pin... So I removed the 3.3v connection and it runs farther:
Code:
Circuits At Home 2011
USB Host Shield Quality Control Routine
Reading REVISION register... Die revision 03
SPI long test. Transfers 1MB of data. Each dot is 64K
Test failed.  Value written: 01 read: 00
Unrecoverable error - test halted!!
0x55 pattern is transmitted via SPI
Press RESET to restart test
Maybe I misread the info on the page: https://www.pjrc.com/teensy/td_libs_USBHostShield.html
 
@KurtE
Mine is hooked up the exact same way as shown in https://www.pjrc.com/teensy/td_libs_USBHostShield.html in terms of pin connections.

Did you remember to cut the trace and wire VUSB to 5v?

I'll hook mine up and give it a try.

[UPDATE] Just tested mine with the same hookup with reset ->3.3v and got the exact same results as you did. I think I saw this before but I have go read the usb host shield website again. Going to rewire it again - last time this happened I had something hooked up wrong. But will have to wait - tired now
 
Last edited:
@mjs513 - Hopefully I did a simple screw-up.... :D

Now to take a quick look at the mouse reconnect issue... Then take a few more guesses on rumble and then maybe play with spider.
 
@KurtE

In case you are interested there is a nice lib put together by felis for testing the shield: https://github.com/felis/USB_Host_Shield.

I rewired everything with the same results. Why is this happening - looks like its a faulty oscillator based on the test sketch results:
"Error: OSCOKIRQ failed to assert"
from here https://www.circuitsathome.com/mcu/arduino/usb-shield/troubleshooting-arduino-usb-host-shield/ there is all sorts of troubleshooting info for their shield:
The “OSCOKIRQ failed to assert” message in the first line of test sketch output is also a good indicator of faulty oscillator. The best way to fix it is to replace the crystal.
There are a several comments where people had to return there boards.
 
Back
Top