MouseBt connected keyboard when I added ::
Serial1.begin(1843200);
This was already done in JoystickBt but not MouseBt - both using the same code with all _debug enabled.
I didn't expect these results - it looks like this might be useful in tracking down some errors. My test usage is ham handed just to see it work - but even so it looks to show something? This goes along with failure when _DEBUG is disabled?
Here is a CodeCompare screenshot of the difference in Trace_tt messages from MouseBt.ino where LEFT is YES it works to connect Keyboard with Serial1.begin and RIGHT is NO connect of the keyboard [NO is when Serial.begin() is missing]::
There are minor 'blue' diffs in the values on some otherwise same lines - usually just CycleCounter Values so ignore those.
These lines are printed at the END of each loop() in my use:: debTraceShow_tt( -4, "V1: %u", "\tV2: %u", "\tfunc %s" ); // -4 is NEW - print all lines and clear trace data on exit.
Here is my current Zipped copy of USBHost_t36 - and the two text files and the image file in one - don't feel like gihub now - just put in current debug.tt lib too.
Looking at these three YES only lines - I used different Trace commands in test - NOTE: Oldest is on Top as #3 [first two chars] - the next two came on the next loop() where newest is first, i.e. #2 is before #1 from the same loop()
#3: V1: 536822624 V2: 5439821 func BtC::rx_callback in transfer() L#:349
#1: V1: 15 V2: 6 func rx_data in rxbuf_[0]() L#:391
#2: V1: 536831168 V2: 6 func rx_data in transfer() L#:377
On the right is L# as LINE#:
for #349 V1 is 536822624 - that is from expression "transfer" in class Rx_callback - where I put the func name abbreviated and V2 is CYCCNT
void BluetoothController::rx_callback(const Transfer_t *transfer)
{
debTraceE_tt( transfer, ARM_DWT_CYCCNT, "BtC::rx_callback" );
for #391 V1 is "15" value of rxbuf[1] and V2 is len of 6 and that is in rx_data using __func__
if (rx_packet_data_remaining == 0) { // read started at beginning of packet so get the total length of packet
debTraceE_tt( rxbuf_[0], len, __func__ );
for #377- that is same Rx function and V1==transfer and V2==len
for (uint8_t i=0; i < len; i++) DBGPrintf("%x ", buffer
);
DBGPrintf("\n");
debTraceE_tt( transfer, len, __func__ );
That suggests a clear bunch of callbacks missing when there is no Serial1 debug output! Those are just the funcs() I put a Trace on. Included copy of Debug_tt in case it looks fruitful and you can see how it works and customize it for your reading pleasure.
NOTE: I set up debug_tt on Serial2 so it does not interfere with USBHost _debug on Serial1 - other added sketch code is in setup()
NOTE: The code had/has a disable of TRACE logging during printing - this can/will result in loss of any messages coming from an interrupt as written.
NOTE: This is really ugly output as it was done based on the idea - before actual usage -
<add>: I put a master trace++ counter on - and I increment it before leaving when interrupt enters while disabled I see some trace elements getting lost indeed - one group of 7 it seems ( I did it quick&dirty so just approx. cnt). I'll make a way to add entries during print 'snapshot'. There is some correlation to blank printed lines and lost trace records - and that must go along with the floating spare numbers printed - like that 49 in both sides of the codecompare. This could be reduced if not printed while 'active' USB during the startup period - at least not EACH loop() exit until I get it fixed. The _isr pin could be used and put it at priority above USB and then add DebugDump to show the trace log - but that could cause USB to break being gone a few ms.