usbd_hid_composite not working on Mac?

[peterz]

Hi
my USB keyboard application works on Windows and Linux but not on a MacBook Air with
macOS Sierra 10.12.6. So I did step back and tried the combined HID example
nRF5_SDK_16.0.0_98a08e2/examples/peripheral/usbd_hid_composite/hex/usbd_hid_composite_pca10056.hex
with md5sum 6ffe5856a45b765a6ecf10ec0e348cdc
surprise: it does not work either

what I did:
flash the example hex file on PCA10056  version 2.0.1
connect the board to the MacBook Air

result:
mouse works perfectly as expected
keyboard is visible in the OS settings dialog for keyboards
no reaction at all on button3 (SHIFT) and button4 (letter G)
unexpected behaveour of LED3  - the picture below shows the LED timing on an oscilloscope:
stable for about 20ms then 4 toggles in row

I look at the code and from this point I'm guessing:
the LED might get inverted in APP_USBD_HID_USER_EVT_OUT_REPORT_READY
is the OS asking for information?
or trying to discover the type of the keyboard by provoking a reaction (which is not delivered by the example code)?

I'm aware that the OS does not recognize the type of the keyboard and it asks me to press the button right of LEFT-SHIFT.
This button might be 'Z' on an standard US keyboard or the additional "NON-US-KEY" (keycode 100 decimal) on non-US keyboards.
The DevKit is not a real keyboard so I can't press this key and I skip this step and set the european keyboard type later manually.
But this does not help - the keyboard part of the DevKit example is still stuck.

I'm new to USB and HID. And I don't know how to low level debug USB/HID on a Mac.
So I tried comparing USB descriptors of the example with a Holtek keyboard which works fine.
But I couldn't find a notable difference.
Just one detail - it could be a hint or spurious neglectable glitch:
when I compared descriptors on Linux I saw an empty (all zeroes) IN report coming from the Holtek keyboard at the beginning.
I didn't expect this report and I don't know if I should pay attention to it.

question:
are you able to reproduce the problem connecting the composite HID example to a Mac?

despite searching forums a lot I have no clue yet what to look for.
suggestions are welcome - for example: should I dive into USB spec to find if an OS can ask questions to a keyboard and the example does not cover this dialog?

best regards
Peter

[peterz]

Hi Einar

Wireshark can capture USB on a Mac - bad luck - the MacBook Air I have for testing is too old for it to work :-(

I added a lot of NRF_LOG everywhere in the code. To get output I had to add NRF_LOG_DEFAULT_BACKENDS_INIT() in main().

To my surprise hid_kbd_user_ev_handler(APP_USBD_HID_USER_EVT_IN_REPORT_DONE) was constantly called. It felt like an inifinite loop. In the code I could only find one call in app_usbd_hid.c line 428 function endpoint_in_event_handler().

you mentioned that changing vendorID to Apple eliminates the problem. I have no experience in this area but somehow I have to fix this, so I try a hypothesis: with an Apple vendorID the "foreign keyboard identification" process is skipped - even if the keyboard is not in an internal list of known Apple keyboards you cannot ask your customer what keyboard he connected if it comes from Apple too - that would be embarassing ;-)

So the problem might be the keyboard detection process itself which might behave differently. This might lead to a non-reset of a flag or a missing ACK and as a consequence to an infinite repetition of the IN report (?)

Maybe you can use Wireshark on a Mac or you have a hint what I should look for. I'll try to dive deeper into the code with a fresh mind tomorrow.

best regards

Peter

[Einar Thorsrud]

Hi Peter,

I have also seen that the hid_kbd_user_ev_handler() is called repeatedly. We believe that this issue is likely due to a missing feature at the application level of the usbd_hid_composite example, but we are not sure what MacOS expects the application to do. I will try to get some insight into this, hopefully, this week, but I cannot promise anything. Please let me know what you find during your investigation.

Einar

[peterz]

Hi Einar

thanks for your support - don't worry, it is not urgent, I still have a lot of other issues to solve.

What I did today: forum research and some trials - no effect yet. I even added 80mA power load and a bit of capacity by adding a USB cable between devkit and MacBook (inspired by some keyboard problem discussions in Apple forums where people solved weird problems by putting a memory stick into the keyboard or adding cables)

Switching on/off the mouse part does not make a difference - actually I use

#define PROPAGATE_PROTOCOL  0
#define CONFIG_HAS_MOUSE    0

I realize I don't know enough about the boot protocol. Using our product in a BIOS does not make any sense, so I think I could remove the boot protocol. And also I don't yet understand the event propagation. I see what it does but the intention behind it...?

enough for today - best regards

Peter

[peterz]

Hi Einar

I did more research and finally found something that looks interesting enough to have a closer look

https://web.archive.org/web/20130615145009/http://www.totalphase.com/solutions/wp/debugging_usb/

there is a section about "finding problems in Data Bit Toggling" which caught my eye. My understanding is still poor - I think I understood that wrong toggling could lead to message repetition - this could be a clue.

best regards

Peter

[peterz]

Hi Einar
although I'm learning a lot of details about USB implementation I'm still far from being competent.
I'm further developing my hypothesis of about what might happen.

With an Apple vendorID the application on the devkit works. I trust you on this, I didn't try it myself.
In forums I find evidence that setting an Apple vendorID circumvents the "foreign keyboard detection" process.

This detection process grabs the USB device before the keyboard can really talk to the system.
During detection keystroke events do not appear in the system and the detection complains if I press a key on the internal keyboard.
After detection the keyboard should be cleanly handed over to the system. So it wouldn't be a surprise if the detection process would perform some kind of (soft) reset on the keyboard before handing it over to make sure it is in a clearly defined state.

a candidate for such a "reset" might be app_usbd_core.c line 820
static ret_code_t setup_device_req_set_configuration()

which calls app_usbd.c line 1888
void app_usbd_all_iface_select_0()

USB spec: setting configuration resets the data toggling to Data0.
I also find that remark also in the. Might app_usbd_all_iface_select_0() reset too many EP, the wrong EP, whatever?


why does the application work properly on other OS?
this "soft reset" never happens in Windows or Linux context.
The keyboard detetction is the first and only time this happens.

as I said before: all this is hypothetical, pure speculation.
I'm just sharing my thoughts

best regards
Peter

[Einar Thorsrud]

Hi Petter,

Thank you for sharing your thoughts. We don't know more about this than you do, but  we would very much like to get this sorted out. I am sorry I have not had the chance to look properly into it yet, but I will try to dig into it as soon as possible.

Einar

[peterz]

Hi Einar

looking through the code I realized there is a legacy mapping. This inspired me to a test - bingo!

I tested usbd_hid_composite_pca10056.hex with 2 MacBooks: an old version (2010) and a younger, more powerful model.

SDK_14.0.0_3bcc1f7  works perfectly with both machines!

SDK_15.2.0_9412b96 and SDK_16.0.0_98a08e2 on newer MacBook: mouse is working but keyboard is dead. LED3 is toggling too fast to see it flicker.

SDK_15.2.0_9412b96 and SDK_16.0.0_98a08e2 on the slower, older MacBook: mouse is working but keyboard is NOT completely dead. LED3 is flickering. The buttons produce g and G but only with a probability of about 15%

Either the nrfx driver rewrite broke something or a sleeping bug was wakened. And the difference between the 2 machines raises questions about timing / race conditions. This might be hard to find :-(

best regards

Peter