Skip to content

Add USB endpoint tests #6880

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

fkjagodzinski
Copy link
Member

@fkjagodzinski fkjagodzinski commented May 11, 2018

Description

Extend tests-usb_device-basic with:

  • endpoint test abort,
  • endpoint test data correctness,
  • endpoint test data toggle reset,
  • endpoint test halt,
  • endpoint test parallel transfers,
  • endpoint test parallel transfers ctrl.

Pull request type

[ ] Fix
[ ] Refactor
[ ] New target
[x] Feature
[ ] Breaking change

CC @c1728p9 @maciejbocianski @jamesbeyond

@fkjagodzinski
Copy link
Member Author

The comments with test description are missing. I'll add them here or in the consecutive PR.

@fkjagodzinski
Copy link
Member Author

fkjagodzinski commented May 11, 2018

The endpoint test abort test case needs #6884 to work.

@fkjagodzinski
Copy link
Member Author

I added the missing docstrings.

while time.time() < end_ts and not ctrl_error.is_set():
loopback_ep_test(ep_out, ep_in, ep_out.wMaxPacketSize)
except usb.core.USBError as err:
if err.errno not in (32, 110):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On windows this error is None when the endpoint is stalled. You might need to remove this check if the error codes aren't portable.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

while time.time() < end_ts:
halt_ep_test(dev, bulk_out, bulk_in, bulk_out, log)
bulk_out.clear_halt()
intf.set_altsetting() # Force the device to start reading data from all OUT endpoints again.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if setting the alternate again is the right way to handle this, but I would like to get your thoughts on this @fkjagodzinski. Some possible alternatives

  • Require that if a transfer was started then the transfer is resumed when halt is cleared (USBPhy responsible for this)
  • Have the class driver handle the clear halt request and start the transfer again

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was the simplest solution I was thinking about. I haven't thought about the test class callback for a clear request though. I'll update the code this way.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added VENDOR_TEST_READ_START device request. It's used to explicitly start reading on given OUT endpoint.


delayed_halt = Timer(delay, timer_handler)
delayed_halt.start()
end_ts = time.time() + 1.5 * delay
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This delay wasn't long enough for my machine and caused intermittent failures. It may be good to set this to a really long delay (1 second?), as it will break from the loop early due to the stall anyway.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, updated code does not use end_ts at all.

log('Testing aborting an in progress transfer for IN endpoints.')
for ep_in in (bulk_in, interrupt_in):
payload_size = (NUM_PACKETS_UNTIL_ABORT + NUM_PACKETS_AFTER_ABORT) * ep_in.wMaxPacketSize
payload_in = ep_in.read(payload_size)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On my setup, Windows 10 using libusb-win32, this raises a timeout exception so payload_in never gets returned:

USBError: [Errno None] libusb0-dll:err [_usb_reap_async] timeout error

Maybe instead of aborting and stopping the transfer, abort and start a new transfer with a buffer with different contents. Alternatively, this could be broken up into two reads, where the first one should complete fully, and the second one should timeout without any data.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Now reading data in chunks of wMaxPacketSize each.


if verbose:
log('Testing OUT/IN data correctness for bulk endpoint pair.')
for payload_size in range(1, bulk_out.wMaxPacketSize + 1):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Zero is a valid size, so it might not hurt to test that value as well. If you were seeing errors with this earlier #6922 should fix the errors.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated; thanks for the reminder!

@cmonr
Copy link
Contributor

cmonr commented May 21, 2018

Umm... Is this PR still ongoing?

#6884 is now closed...

@fkjagodzinski
Copy link
Member Author

@cmonr, Yes, I'm updating the code according to @c1728p9 comments.

@fkjagodzinski fkjagodzinski force-pushed the test-feature-hal-spec-usb-device branch from 6464312 to 8fb7922 Compare May 22, 2018 16:05
@fkjagodzinski
Copy link
Member Author

Update:

  • rebased to current feature-hal-spec-usb-device, 675b24e,
  • fixed host script issues present on Windows machines,
  • added 0 B payload size to bulk endpoints test,
  • updated halt and abort tests according to PR comments,
  • added an explicit request to start reading on OUT endpoints.

@cmonr
Copy link
Contributor

cmonr commented May 31, 2018

@c1728p9 Mind re-reviewing?

@c1728p9 c1728p9 force-pushed the feature-hal-spec-usb-device branch from 675b24e to 565ec75 Compare June 6, 2018 19:48
@c1728p9
Copy link
Contributor

c1728p9 commented Jun 7, 2018

This needs to be rebased but after that I will re-review. cc @fkjagodzinski

@fkjagodzinski fkjagodzinski force-pushed the test-feature-hal-spec-usb-device branch from 8fb7922 to ea32ceb Compare June 13, 2018 09:17
@fkjagodzinski
Copy link
Member Author

  • rebased to current feature-hal-spec-usb-device, c753780,
  • added endpoint test data toggle reset.

fkjagodzinski and others added 4 commits July 3, 2018 14:16
Endpoint callbacks no longer have endpoint as a param. This update was
introduced in ARMmbed#7267.
After an endpoint is unstalled any pending transfers are terminated.
This patch re-starts any reads that were ongoing.
Although the USB spec sets the upper limit on FS isochronous endpoint
payloads to 1023 B, this value is hard to test in practice. Moreover,
not all the targets Mbed OS supports (like NUCLEO_F207ZG) are able to
handle all the endpoints set to max.
Wait for a locally created Timer thread to finish before returning.
@fkjagodzinski fkjagodzinski force-pushed the test-feature-hal-spec-usb-device branch from 1de5b2c to 4759a20 Compare July 3, 2018 12:57
@fkjagodzinski
Copy link
Member Author

  • rebased to current feature-hal-spec-usb-device, 9165547
  • updated the test code according to @c1728p9 feedback

@fkjagodzinski fkjagodzinski force-pushed the test-feature-hal-spec-usb-device branch from 4759a20 to 5b501e1 Compare July 17, 2018 08:41
Validate that endpoint buffer is not used after a transfer has been
aborted.
@fkjagodzinski fkjagodzinski force-pushed the test-feature-hal-spec-usb-device branch from 5b501e1 to b1fdfd8 Compare July 17, 2018 09:33
@0xc0170
Copy link
Contributor

0xc0170 commented Jul 17, 2018

/morph build

@mbed-ci
Copy link

mbed-ci commented Jul 17, 2018

Build : SUCCESS

Build number : 2622
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6880/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

@mbed-ci
Copy link

mbed-ci commented Jul 17, 2018

@mbed-ci
Copy link

mbed-ci commented Jul 17, 2018

@fkjagodzinski
Copy link
Member Author

@cmonr @0xc0170 I can see that quite a few random test cases timed out. This PR only extends tests-usb_device-basic, so shouldn't have such a huge impact on other test suites. Can we retrigger ci-morph-test?

@0xc0170
Copy link
Contributor

0xc0170 commented Jul 18, 2018

/morph test

@mbed-ci
Copy link

mbed-ci commented Jul 18, 2018

Test : FAILURE

Build number : 2378
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6880/2378

@0xc0170
Copy link
Contributor

0xc0170 commented Jul 18, 2018

Test results same. We had similar failures 2 weeks ago (no space left on device error), @cmonr please review

@cmonr
Copy link
Contributor

cmonr commented Jul 18, 2018

@studavekar FYI.

Devices power cycled. Restarting.
/morph test

@mbed-ci
Copy link

mbed-ci commented Jul 18, 2018

Test : SUCCESS

Build number : 2379
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6880/2379

Copy link
Contributor

@0xc0170 0xc0170 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note, please run astyle for this feature branch once the work is done (might need to tweak astyleignore file))

@0xc0170 0xc0170 merged commit 5fa3cb9 into ARMmbed:feature-hal-spec-usb-device Jul 18, 2018
@fkjagodzinski fkjagodzinski deleted the test-feature-hal-spec-usb-device branch July 19, 2018 13:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants