usbd_hid_composite not working on Mac?

RE: usbd_hid_composite not working on Mac?

peterz — Tue, 30 Jun 2020 09:23:14 GMT

Hi Kenneth

you made my day!
Both the original example and my own application work on the MacBook I have for testing.
I'll try other Apple machines as soon as possible but for now - GREAT!

have as much fun as I do :-)
Peter

RE: usbd_hid_composite not working on Mac?

Kenneth — Tue, 30 Jun 2020 08:40:41 GMT

Hello Peter,

Einar is on vacation, so I am taking over the case.

Could you please try to insert a new line in app_usbd_hid_kbd.c, function hid_kbd_on_idle(), just below NRF_DRV_USBD_TRANSFER_IN(...), around line 543:

(void)hid_kbd_transfer_next(p_kbd);

This inserted function updates the USB keyboard buffer to make sure that each "idle" transfer reflects the actual keyboard state.

Please let me know the result.

Best regards,
Kenneth

RE: usbd_hid_composite not working on Mac?

Einar Thorsrud — Mon, 22 Jun 2020 17:20:47 GMT

Hi Peter,

Thanks for the update. I do not have any updates from our side yet, unfortunately.

Einar

RE: usbd_hid_composite not working on Mac?

peterz — Thu, 18 Jun 2020 12:34:02 GMT

Hi Einar

comparing Windows vs MacOS is interesting, but it hasn't really helped me (yet).

In the code I didn't find evidence that STALLED would have interesting effects.

I'm still surprised that SDK16 with vendor Nordic produces HID IN periodic reports. I see no stimulus and no reason why they should be sent.

summary: no real progress on my side

Peter

RE: usbd_hid_composite not working on Mac?

peterz — Tue, 16 Jun 2020 09:58:37 GMT

Hi Einar

thanks - Windows uses a different approach at startup.
MacOS probes just 8 bytes of Device Descriptor to discover the buffer size, then restarts reading Device Descriptor with buffer size 64.

Windows fetches the Device Descriptor with 64 byte and then applies RESET, Set Address and re-fetches the Device Descriptor.

Interesting STALLED transfer at 3.784.

@ 3.783: get Serial Number string in ENGLISH_US right away without checking for supported languages.

@ 3.862: asking for only 4 bytes of string ???
Is this a check if the string is delivered but the content is not of interest?

daily business is calling - I continue later

Peter

RE: usbd_hid_composite not working on Mac?

Einar Thorsrud — Tue, 16 Jun 2020 09:28:04 GMT

Hi Peter,

Here is a USB analyzer trace of the unmodified SDK 16 composite HID example and Windows 10: devzone.nordicsemi.com/.../usbd_5F00_hid_5F00_composite_5F00_pca10056_5F00_sdk_5F00_16_5F00_windows_5F00_10.zip.

Einar

RE: usbd_hid_composite not working on Mac?

peterz — Tue, 16 Jun 2020 00:20:47 GMT

Hi Einar

just in case you create a dump when connected to a Windows or Linux system - I would like to compare SDK16 on Windows with SDK16 on MacOS.

Peter

RE: usbd_hid_composite not working on Mac?

Einar Thorsrud — Mon, 15 Jun 2020 08:35:44 GMT

Hi Peter,

We were also looking at the packet lengths. However, changing

            APP_USBD_CLASS_DESCRIPTOR_WRITE(LSB_16(NRF_DRV_USBD_EPSIZE)); // wMaxPacketSize LSB
            APP_USBD_CLASS_DESCRIPTOR_WRITE(MSB_16(NRF_DRV_USBD_EPSIZE)); // wMaxPacketSize MSB

            APP_USBD_CLASS_DESCRIPTOR_WRITE(8); // wMaxPacketSize LSB
            APP_USBD_CLASS_DESCRIPTOR_WRITE(0); // wMaxPacketSize MSB

in app_usbd_hid_mouse.c and app_usbd_hid_kbd.c died not have an effect, at lest. (I might have been long shot, though).

The SDK team has allocated time to analyze this issue in more detail, and I will let you know when they make progress. Please continue to let me know if you have any new findings.

Einar

RE: usbd_hid_composite not working on Mac?

peterz — Sun, 14 Jun 2020 12:03:08 GMT

Hi Einar

further analyzing the dumps: I see SDK14 sets wMaxPacketSize == 8 in the IN Endpoint Descriptor for both mouse and keyboard while SDK16 sets wMaxPacketSize == 64

wild speculation: the internal buffer is only 8 bytes long, but gets cleared 64 bytes deep (array index out of bounds). this would overwrite memory. The additional request for some Apple specific feature (vendor ID Apple) leads to STALLED because the requested feature is not implement and restores some of the overwritten values.
wild speculations, but for the moment I it's the most promising trail I see. I have to check that in the code.

Not yet clear: does the host activate boot protocol or not ?

And I see the precompiled hex version in SDK14 does not set SUBLANGUAGE for the strings, it's just ENGLISH. I don't know if this is legal - it HAS an impact on host behaviour, but I do not think this should lead to trouble. Also I see variations in the order the interfaces are set up: I assume that the host spawns a thread per interface

best regards
Peter

RE: usbd_hid_composite not working on Mac?

Einar Thorsrud — Fri, 12 Jun 2020 18:06:40 GMT

Hi Peter,

Sounds good. Please let me know if you make any progress. I will update this thread when we have some results.

Einar

RE: usbd_hid_composite not working on Mac?

peterz — Thu, 11 Jun 2020 23:19:58 GMT

Hi Einar

thank you very much for the analyzer traces, they are VERY helpful. I have to be cautious with interpretation for I'm a beginner and it's not clear what is cause and what is consequence. In the traces SDK16 with Nordic vendor id I see the start of the famous 4-transfers-with-20ms-pause loop I saw on my oscilloscope.

Interesting detail: the very first group (at 7.673 141) appears spontaneously 12.3 ms after the last "Class request" and is only 3 IN reports long (not 4).

Comparing this to Apple vendor id: the time between the last "Class request" and the last "Get Descriptor" is 9.5ms. And the last "Class request" appears only for Apple vendor id - it might be asking for an Apple specific feature - and gets answered with STALLED (maybe because it is not implemented).

This might give me 2 clues:
a) STALLED might execute code which resets something in the driver
b) there might be some timeout in the range of 10-12ms which expires before the last "Get Descriptor" call appears

Before reading those traces I expected to have more interaction when macOS tries to identify an unknown keyboard. Now I see it's the other way around: there is one more request when macOS tries to get some additional information it expects from an Apple keyboard but not from a third party product. This makes sense.

enough for today - I will try to understand more the next days

best regards
Peter

RE: usbd_hid_composite not working on Mac?

Einar Thorsrud — Mon, 08 Jun 2020 13:48:20 GMT

Hi Peter,

I am seeing the same thing. For reference I attach hex files and USB analyzer traces: devzone.nordicsemi.com/.../USB-composite.zip. I do not have any progress though, unfortunately.

Update: We are continuing to look into this and will update this thread when I have more information.

Einar

RE: usbd_hid_composite not working on Mac?

peterz — Mon, 08 Jun 2020 11:05:27 GMT

Hi Einar

the code in SDK 16 compared to SDK 14 is a complete rewrite, adding timestamp makes little sense.

I compiled usbd_hid_composite example from nRF5_SDK_16.0.0_98a08e2 modifying sdk_config.h to get RTT debug output. Below to find the debug output when I connect to Windows 8.1, Linux, MacBook.

The sequences are quite different, depending on OS. Looking at the code I'm surprised most of the seuqnece
APP_USBD_EVT_DRV_RESET
APP_USBD_EVT_DRV_RESET
APP_USBD_EVT_DRV_RESET
APP_USBD_EVT_DRV_RESET
APP_USBD_EVT_DRV_RESET
APP_USBD_EVT_STATE_CHANGED
APP_USBD_EVT_STATE_CHANGED
is this the consequence of (unwanted?) recursion?

usbd_core_state_set(app_usbd_state_t state) does more than it says

I'm stuck on this for 2 weeks now and the more I dig into it the less I think this is a Mac issue.
Peter

here comes the debug RTT output when I just connect the devkit (no buttons pressed)

debug output when plugged into Windows 8.1
00> <info> app: USBD HID composite example started.
00> <info> app: enter main loop
00> <info> app: USB power detected
00> <info> app: USB ready
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_STATE_CHANGED
00> <info> app: usbd_user_ev_handler STARTED
00> <info> app: usbd_user_ev_handler SUSPEND
00> <info> app: usbd_user_ev_handler RESUME
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_DRV_RESET
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_STATE_CHANGED
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_DRV_RESET
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_DRV_RESET
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_STATE_CHANGED
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_STATE_CHANGED
00> <info> app: hid_kbd_user_ev_handler OUT report

debug output when plugged into a Linux machine
00> <info> app: USBD HID composite example started.
00> <info> app: enter main loop
00> <info> app: USB power detected
00> <info> app: USB ready
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_STATE_CHANGED
00> <info> app: usbd_user_ev_handler STARTED
00> <info> app: usbd_user_ev_handler SUSPEND
00> <info> app: usbd_user_ev_handler RESUME
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_DRV_RESET
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_STATE_CHANGED
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_DRV_RESET
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_STATE_CHANGED
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_STATE_CHANGED
00> <info> app: hid_kbd_user_ev_handler OUT report

debug output when plugged into a old, slow MacBook Air with El Capitan
00> <info> app: USBD HID composite example started.
00> <info> app: enter main loop
00> <info> app: USB power detected
00> <info> app: USB ready
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_STATE_CHANGED
00> <info> app: usbd_user_ev_handler STARTED
00> <info> app: usbd_user_ev_handler SUSPEND
00> <info> app: usbd_user_ev_handler RESUME
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_DRV_RESET
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_STATE_CHANGED
00> <info> app: usbd_user_ev_handler SUSPEND
00> <info> app: usbd_user_ev_handler RESUME
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_DRV_RESET
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_DRV_RESET
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_DRV_RESET
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_DRV_RESET
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_DRV_RESET
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_STATE_CHANGED
00> <info> app: usbd_user_ev_handler APP_USBD_EVT_STATE_CHANGED
00> <info> app: hid_kbd_user_ev_handler IN report
00> <info> app: hid_kbd_user_ev_handler IN report
00> <info> app: hid_kbd_user_ev_handler IN report
......... same line repeated many times per second .......

RE: usbd_hid_composite not working on Mac?

Einar Thorsrud — Fri, 05 Jun 2020 09:20:39 GMT

Hi Peter,

[quote user="zankl"]the results I get make me think of timing and race conditions. I would like to add some debug output messages with high resolution timestamps.[/quote]

That seems sensible.

[quote user="zankl"]What can I use as reference timer, is there something like System.getTimeMicroseconds() ?[/quote]

The easiest is to use the RTC, and just start it and read the COUNTER register to get a timestamp. However, this is only 32.768 kHz. Since the example already uses the app_timer, all you need to do in this case is to modify sdk_config.h so that APP_TIMER_CONFIG_RTC_FREQUENCY is 0 (to get a higher accuracy), and set APP_TIMER_KEEPS_RTC_ACTIVE to 1. Then you can call app_timer_cnt_get() to get the counter value.

If you need higher accuracy than what you get with the RTC, then you must use a TIMER. In that case, you cannot read the counter register directly, so you need to capture it to a CC register, and read it from there.

Einar

RE: usbd_hid_composite not working on Mac?

peterz — Fri, 05 Jun 2020 08:47:15 GMT

Hi Einar

the results I get make me think of timing and race conditions. I would like to add some debug output messages with high resolution timestamps. What can I use as reference timer, is there something like System.getTimeMicroseconds() ?

best regrads
Peter

RE: usbd_hid_composite not working on Mac?

Einar Thorsrud — Thu, 04 Jun 2020 10:30:51 GMT

Hi Peter,

I am sorry for the late reply. Yes, I get the same results. The example from SDK 14 works (including 14.2). I am not close to properly understanding the issue, though.

Br,

Einar

RE: usbd_hid_composite not working on Mac?

peterz — Thu, 04 Jun 2020 09:36:52 GMT

Hi Einar

do you get the same result?
The usbd_hid_composite example from SDK 14 works fine with macOS.
The same example from SDK 15 fails.

best regards
Peter

RE: usbd_hid_composite not working on Mac?

peterz — Fri, 29 May 2020 22:31:25 GMT

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

RE: usbd_hid_composite not working on Mac?

Einar Thorsrud — Fri, 29 May 2020 12:39:36 GMT

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

RE: usbd_hid_composite not working on Mac?

peterz — Fri, 29 May 2020 09:32:07 GMT

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

RE: usbd_hid_composite not working on Mac?

peterz — Thu, 28 May 2020 20:19:11 GMT

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

RE: usbd_hid_composite not working on Mac?

peterz — Thu, 28 May 2020 00:11:58 GMT

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

RE: usbd_hid_composite not working on Mac?

Einar Thorsrud — Wed, 27 May 2020 14:07:09 GMT

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

RE: usbd_hid_composite not working on Mac?

peterz — Tue, 26 May 2020 20:33:25 GMT

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

RE: usbd_hid_composite not working on Mac?

Einar Thorsrud — Tue, 26 May 2020 14:16:51 GMT

Hi Peter,

Yes, this definitely has to be fixed. Using Apple's Vendor ID is not an option for an end product, but the fact that it makes things work is an interesting observation. I do not have an explanation for why this happens at the moment, though, nor a proper fix yet.

Einar