webUSB: serial reads blink the LED even when there's no serial data sent

[jaustin]

This issue is more for discussion than for an immediate fix.

When using webUSB and serial (for example with DapJS), the host machine polls DAPLink for serial data (https://github.com/ARMmbed/dapjs/blob/master/src/daplink/index.ts#L150). Even if there's no data to return, the LED blinks.

One boards like micro:bit where there's only one LED this makes it look like the device is doing something active (and it kinda is, but not an active thing that's relevant to the user....), and particularly looks like the device is being flashed. Kids have learned not to unplug their micro:bit when it's still flashing (unless they know they're sending serial data) and this has confused people (including me!) into thinking their device is still being flashed - for example

microsoft/pxt-microbit#1002

That issue contains two things, one is a real bug, but the other is just us being confused because the LED stays flashing...

This can, to some extent, be mitigated in the host software, but an ideal situation for us would be the following:

• Blink on all USB activity unless the device is polled for serial data, but none is available.

This appears to be complicated by the fact the flash (I think) is coming from the top level code in usbd_user_hid.c but we don't know whether we have data until later in the callchain in/DAP_vendor.c

A slightly less good option for us would be

• Disable the HID LED in general and add code to blink the 'serial' and 'msd' LEDs when the HID activity maps to serial or device flashing. (I think this one is likely to end up with confusing corner cases like 'when I use HID to flash the device using a debugger it doesn't give me any indication of that')

@arekzaluski you wanted a headsup when I filed this.

I'm sure there are a bunch of other ways to mitigate the confusion so very welcome to suggestions. The goal is to avoid the LED blinking when there's no serial traffic, but keep all other existing flashing behaviour the same.

[brianesquilona]

@jaustin , I did a quick check on the LEDs, if it comes from serial, probably it is cdc, but also msc and hid should not blink. I tried using the interface https://python.microbit.org/v/beta but I can not replicate it. If this is still an issue, can you provide more details replicating it.

[j-austin]

Hey Brian. The best place to reproduce is in MakeCode https://makecode.microbit.org/beta?webusb=1#editor (Click on the 'gear' and click 'pair') After the first webUSB flash the LED will blink as it polls serial. I think this is from the 'serial over HID' we use for webUSB J

…

-- Please excuse brevity or typos, this was sent from a phone From: [email protected] Sent: 22 August 2018 10:50 pm To: [email protected] Reply to: [email protected] Cc: [email protected] Subject: Re: [ARMmbed/DAPLink] webUSB: serial reads blink the LED even when there's no serial data sent (#479) @jaustin<https://github.com/jaustin> , I did a quick check on the LEDs, if it comes from serial, probably it is cdc, but also msc and hid should not blink. I tried using the interface https://python.microbit.org/v/beta but I can not replicate it. If this is still an issue, can you provide more details replicating it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#479 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AGESQ_fymyqAaqhe0rQ1NvHAcF0prspIks5uTdIygaJpZM4V92i->. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[brianesquilona]

@jaustin You're right it is hid, I happened to replicate the blinking once, with a weird USB product "LPC1768", then I tried again now the correct USB product descriptor, was displayed on the 'pair', and I have not replicated the issue since then.

[j-austin]

okay, weird. @microbit-carlos has also seen the issue with 'LPC 1768' being listed and was trying to reliably reproduce so he could file an issue. However I haven't ever seen that and can reproduce the serial poll flashing consistently in MakeCode like this - reload MakeCode - Pair with micro:but - flash program to micro:bit using webUSB - led continues to blink as serial polling has started (There seems to be some cases where MakeCode decides not to poll but I'm not sure what triggers that. It seems rare for me)

…

-- Please excuse brevity or typos, this was sent from a phone From: [email protected] Sent: 22 August 2018 11:36 pm To: [email protected] Reply to: [email protected] Cc: [email protected]; [email protected] Subject: Re: [ARMmbed/DAPLink] webUSB: serial reads blink the LED even when there's no serial data sent (#479) @jaustin<https://github.com/jaustin> You're right it is hid, I happened to replicate the blinking once, with a weird USB product "LPC1768", then I tried again now the correct USB product descriptor, was displayed on the 'pair', and I have not replicated the issue since then. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#479 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AGESQ3Rz9CQjOUoQVJL49OuBW0syovU_ks5uTdzfgaJpZM4V92i->. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[brianesquilona]

@jaustin I was not able to replicate this issue on my chrome again, our guest is the that chrome or your internet browser mistakenly identified the vid and pid of the device to some other boards, and there might be some protocol issues from it.

My suggestion is reconnect the board if the device name in the pairing is wrong, it should be Daplink CMSIS-DAP, soon to be change to BBC micro:bit CMSIS-DAP

[jaustin]

@arekzaluski and @microbit-carlos you two also saw this (I think with the serial example in DAPjs too?) - do you have any more reliable reproduction steps?

[microbit-carlos]

I don't have any reliable reproduction steps yet.
I was able to see it quite a few times when we were looking into the issues of the WebUSB driver not being installed correctly on Windows, and during that process I ended up installing/uninstalling the Mbed drivers several times, so perhaps that had something to do with it (a fresh driver install and fresh Chrome pairing).

[arekzaluski]

@jaustin Yes, I'm aware of this issue. I agree with Carlos that it happens during the first time when device is requested by user in Chrome. I think that It happens because all DAPLink boards have the same vid and pid. Chrome associates it with LPC1768.

Please check following steps:

1. Disconnect board from your laptop.
2. Go into site settings in chrome (lock icon next to url)
3. Remove all saved usb devices
4. Reconnect board

As of the second issue (LED blinking while polling serial data) - I can definitely reproduce it. It exists because DAP.js is polling for a serial data every 200ms. It sends a DAP command to DAPLink and it causes an LED to blink. It behaves like that by design (I wanted to notify user that something is going on on a board and it should not be simply disconnected without stopping serial monitor first). I however understand that it is extremely confusing on boards like micro:bit (single LED). It should not be difficult to change in DAPLink.

@flit @c1728p9 what is your opinion about serial monitor and led? I see few options:

1. Disable LED blinking while polling serial data for all boards.
2. Keep it as it is, LED is blinking with every serial data DAP request.
3. Client (DAP.js) should be able to control this behaviour and either enable/disable it.
4. Blink led only when there is an actual data to be read on serial port.

[jaustin]

I think talking about two separate issues here is confusing us. Could one of you that can reproduce the LPC1768 please file that?

For the DAP flashing issue I think best case would be '4' in Arek's suggestion but '3' would also make it possible.

One other possibility is to push the blinking down the call stack so each 'task' is responsible for their own blinking (possibly that's how you'd need to make '4' happen?). Or that a return value from the calls that process the command can say 'don't blink'

DAPLink team, what do you think?

[microbit-carlos]

Opened #486 to move the LPC1768 name discussion.

[brianesquilona]

The hid response packet on a single command is [ request byte ] [ response length ] [ data1 ] [ … ]
This happens on UART read, maybe some other commands.

In a single command like this the response length is 0. I will check if there is any other command that returns a response length of 0 even when, otherwise this could be consider a workaround.
The problem is if there is a filtering out of UART read (ID_DAP_Vendor3) on top of hid processing, these request ID and behavior could change in the future.

I could only think of adding bit status in DAP_ExecuteCommand return (currently 16bit response length + 16bit request length) (15bit is big enough to make offset jumps to a DAP_PACKET_SIZE currencty set to 64 in kl64Z), to indicate a nope status to work around this.

@c1728p9 @flit , any comments?

[brianesquilona]

#493

[brianesquilona]

Fixed by the PR