Release candidate for mbed-os-5.13.3 #11195
Conversation
|
Added nanostack PR 11156 |
0xc0170
force-pushed
the
release-candidate
branch
from
e885a79 to
e99d926
Compare
|
Force pushed, removed PR 10877 |
0xc0170
force-pushed
the
release-candidate
branch
from
8cf55ff to
e99d926
Compare
|
@0xc0170, thank you for your changes. |
0xc0170
force-pushed
the
release-candidate
branch
from
e99d926 to
e5e8027
Compare
|
Cleaned one wrong rebase, updated again |
|
CI started |
Test run: FAILEDSummary: 4 of 4 test jobs failed Failed test jobs:
|
|
One of the rebases with conflicts might have caused the build issues (there were around 5 PRs conflicting). I'll fix that |
|
I am going to recreate this RC. I've noticed at least one missing commit in here. Will fix it on Monday morning the latest. https://github.com/ARMmbed/mbed-os/pull/11139/commits - this PR contains 5 commits, IAR included but not here. I have it locally as a patch but was not applied (I know why, I ended up having no commits left and no action and script reported an error). |
- Fix assert when spi_master_block_write called with 0 size - Fix assert when spi_format called before spi_frequency - Simplify implementation of spi_master_write - Simplify pointer arithmetic expressions in cyhal_spi_transfer and cyhal_spi_transfer_async - Fix I2C driver not honoring the frequency specified during init.
For UTs mbed_assert_internal should not be declared as MBED_NORETURN as UT stub for mbed_assert_internal only prints out the assert trace and returns back to original code.
|
unittest fails, I recall only #11162 PR with conflict (one file addition to the list). Need your help @ARMmbed/mbed-os-wan here |
|
Failure is in CellularContext. The only commit touching that file is d160098 - was it applied correctly for 5.13 ? unit test url https://mbed-os.mbedcloudtesting.com/blue/organizations/jenkins/mbed-os-ci_unittests/detail/mbed-os-ci_unittests/3576/pipeline |
0xc0170
force-pushed
the
release-candidate
branch
from
6e79b26 to
b191ddc
Compare
|
Updated, removed 70c5817 - moved to 5.14. Still waiting for unittest cellular fix |
|
CI started |
Test run: FAILEDSummary: 3 of 4 test jobs failed Failed test jobs:
|
Due to the data buffer is loaded in two steps the whole block needs protection from being interrupted
This error prevented using this header in cpp code directly.
When STM32F746-DISCO board was being used in (unsupported) USBHost mode,
the communication was unreliable. Our investigation revealed that the
problem lied in redundant IN tokens that the host generated even though
it shouldn't. This could lead to endless high-frequency NAKs being
received from device, which caused watchdog reset as USBHost spent all
time in interrupt handlers.
In our application the clocks frequencies are:
* HCLK = 48 MHz
* APB1 = 6 MHz
* APB2 = 12 MHz
We have captured the raw USB High-Speed traffic using OpenVizsla.
Without this change, when USB MSD device connected to the system
responded to IN with NAK, there were excessive IN tokens generated about
667 ns after the NAK. With this commit the IN tokens are generated no
sooner than 10 us after the NAK.
The high frequency of the IN/NAK pairs is not the biggest problem.
The biggest problem is that the USB Host did continue to send the IN token
after DATA and ACK packets were received from device - *without* any request
from upper layer (USB MSD).
The USB MSD devices won't have extra data available on Bulk IN endpoint
after the expected data was received by Host. In such case IN/NAK cycle
time is only houndreds of nanoseconds, the MCU has no time for anything else.
The problem manifested not only on Bulk endpoints, but also during
Control transfers. Example correct scenario (when this fix is applied):
* SETUP stage
* SETUP [host -> address 0 endpoint 0]
* DATA0 [80 06 00 01 00 00 08 00] [CRC16: EB 94]
* ACK
* DATA stage
* IN
* NAK
... the IN/NAK repeated multiple time until device was ready
* IN
* DATA1 [12 01 10 02 00 00 00 40] [CRC16: 55 41]
* ACK
* STATUS stage
* OUT
* DATA1 ZLP
* ACK
Without this commit, in DATA stage, after the ACK was received, the host
did send extra IN to which device responded with STALL. On bus it was:
* DATA stage
...
* IN
* DATA1 [12 01 10 02 00 00 00 40] [CRC16: 55 41]
* IN
* STALL
* IN
* STALL
* STATUS stage
* OUT
* DATA1 ZLP
* STALL
In the fault case the next SETUP was sent only after 510 ms, which
indicates timeout in upper layer.
With this commit the next SETUP is sent 120 us after the STATUS stage ACK.
…13_x Nanostack patch release for Mbed OS 5.13.x
|
Another dependency, removed 11119 from this RC. Updated now |
0xc0170
force-pushed
the
release-candidate
branch
from
0dac8d2 to
d587e73
Compare
|
CI restarted |
|
@ARMmbed/mbed-os-test Can we fix merge failure : continuous-integration/jenkins/pr-merge — This commit cannot be built ? Also memory usage fails with the same error |
Test run: FAILEDSummary: 1 of 11 test jobs failed Failed test jobs:
|
|
@ARMmbed/mbed-os-test dynamic job reports internal path error ,pls review |
|
The CI is green, I am going to test client repos |
|
Looks like this is ready for integration, will merge once I get confirmation from the client team |
Description
I am still one PR short (Nanostack, will apply it manually).
There were lot of conflicts in various PR that looked so simple, will need to verify all commits are OK here.
Pull request type
Reviewers
Release Notes