Skip to content

STM32: allow HS USB endpoints and increase USB OTG_HS endpoints number #3

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

Closed
wants to merge 427 commits into from

Conversation

pennam
Copy link

@pennam pennam commented Oct 1, 2020

Summary of changes

  1. Allow USB High speed endpoints
  2. Increase USB OTG_HS endpoints number

This two commits can be squashed into one. The PR is independent from PORTENTA_H7 board so it can be mainlined before adding the new target

Impact of changes

Changes are enabled if :
MBED_CONF_TARGET_USB_SPEED == USE_USB_OTG_HS

Migration actions required

Documentation


Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[X] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers


@pennam pennam changed the title STM32: allow HS USB endpoints and increase them for OTG_HS ports STM32: allow HS USB endpoints and increase USB OTG_HS endpoints number Oct 2, 2020
@pennam pennam marked this pull request as ready for review October 6, 2020 07:33
0xc0170 and others added 28 commits October 16, 2020 16:22
Scancode: Fix false positive reported by scancode output analyser script
- Alignment with other STM32 families
- Subfamily level in targets.json
…x_testcase_update

Summary of changes
Remove WEP security Test Case with NULL as WEP security Key are sequence of Hex Values , the character "NULL" is (0x00) it is a valid value ( for ex: this is key index, followed by length and hex key array).

Impact of changes
Remove the test case for NULL( "" )key with NSAPI_SECURITY_WEP to test return value with NSAPI_ERROR_PARAMETER

The set_credentials(const char *ssid, const char *pass, nsapi_security_t security) API has no key length, the key length is derived by using strlen(pass), which works if the pass ( is a string) , but in case of NSAPI_SECURITY_WEP and NSAPI_SECURITY_WPA2_ENT, the key does not happen to be string but a hex char array.

WEP security Key are sequence of Hex Values , the character "NULL" is (0x00) it is a valid value ( for ex: this is key index, followed by length and hex key array).

The key index 0 , 1, 2, 3 are keys used for an WiFi Access point.
…che_usage-master

Enable Nanostack DNS cache usage
STM32G4 update drivers version to CUBE V1.3.0
SPDX are not yet done in our codebase. We suggest them to be present but 3rd party
drivers have not yet been updated. The check as it was causes problems when updating
3rd party drivers (red flags in the PR).

Proper fix will be to clean up SPDX id in the codebase.
…ndler

BLE: Introduce ChainableEventHandler and subclasses
STM32L5 update drivers version to CUBE V1.3.1
Do not force red status for PRs due to SPDX missing (license must be there). We will
add better SPDX checks later (more work required to enable these for 3rd party code).
Separate cloud example configurations to another file
STM32WB update drivers version to CUBE V1.8.0
+ STM32Cube_FW_L0_V1.10.0 original files
+ targets.json update introducing subfamily level
The connection id starts at the value 1. The entry accessed in the array should be connId - 1
The connection starts at 1, not 0. The entry in the array should be connId - 1
STM32L0 update drivers version to CUBE V1.11.3
- startup files pdated from Cube
- all SetSysClock aligned and checked
- license header updated
hugueskamba and others added 27 commits November 6, 2020 17:25
Added the board so it can be used for testing the bare-metal profile on a Mbed 2 board
$<TARGET_FILE:${target}> is the output from CMake. As it can contain suffix for some toolchains, we can use ${target} instead (output from hex/bin generation).
Co-authored-by: Rajkumar Kanagaraj <[email protected]>
Issue https://gitlab.kitware.com/cmake/cmake/-/issues/21093

Until this is fixed, we should disable response files for ARMClang + ninja on Windows.
Other toolchains and host systems should benefit from response files thus not disabling them
completely.

This fixes the issue with not finding includes. It's not trivial to find the root cause, it took me a while to figure out why ARMClang can't find the paths.

I moved the check to Mbed OS main cmake. It should not be in the toolchain file as it is not
related to the toolchain but to generator. We need toolchain properly set up first.

Note, I had to protect setting CMAKE_NINJA_FORCE_RESPONSE_FILE. If I set it to 0, ninja
would still use rsp files so I rather protected it and define that variable only when
required, not always.

Co-authored-by: Hugues Kamba <[email protected]>
Rename the CMake variable expected from applications from MBED_ROOT to
MBED_PATH to be consistent with the naming used for the configuration file
(MBED_CONFIG_PATH) also expected from applications.
As the assembler does not seem to recognise the request to the
linker to use microlib, remove that instruction.
Microlib is still used as the linker selects microlib as a result
of being explicitly asked to do so.
The new function (mbed_set_cpu_core_definitions()) should always be
called as it has defintions needed by Mbed OS to work with that
particular MCU core.
mbed_set_cpu_core_options() should only be called if a third-party
toolchain file has not been used as it has compile options that can
cause conflicts.
…put source file

The compile defintions should always be added depending on the
selected toolchain.
mbed_set_toolchain_options() should only be called if a third-party
toolchain file has not been used as it has compile options that can
cause conflicts.
Compile defintions are always included. However, functions that set compile options
are only called if a third party toolchain file is not used
Check if the selected application profile is supported by the selected Mbed Target
TEST: update cmake example on ble examples
@facchinm facchinm force-pushed the patch-stm32-usbhs-pull branch from 38e7d11 to f1ea281 Compare November 10, 2020 16:23
@pennam
Copy link
Author

pennam commented Jan 8, 2021

Closing because ARMmbed#13816 has been merged

@pennam pennam closed this Jan 8, 2021
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.