Skip to content

Release candidate for mbed-os-5.3.6 #3837

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

Merged
merged 16 commits into from
Feb 27, 2017
Merged

Release candidate for mbed-os-5.3.6 #3837

merged 16 commits into from
Feb 27, 2017

Conversation

adbridge
Copy link
Contributor

No description provided.

pbrier and others added 15 commits February 24, 2017 13:24
In case of prescaler_rank was 0, a -1 index was being used,
which resulted in initialization of the Init.BaudRatePrescaler with
random values.

Now let's better check index and avoid -1 operation, so that prescaler_rank
can be only from 0 to "last_index".
Tests the timer/semaphores at a lower level than the event queue,
which removes a layer of concerns from issues in the rtos timing.
The NCS36510 is limited to 16bit timers. Construction of larger
intervals is performed in software by counting the number of 16bit
intervals that pass.

Either this counting takes a bit of time, or there is a math error
somewhere (maybe a long critical section?), because there is a
roughly ~1us delay between when the interrupt occurs and the ticker
progresses onto the next 16bit interval. This is normally a completely
reasonable error, except that the error accumulates. After a while,
the equeue tests find themselves with tens of milliseconds of error.
To make matters worse, this error is random because of other interrupts
occuring in the system, making the exact issue quite a bit difficult
to track down.

This fix drops the software counter in favor of just recalculating
the next delay interval from the target time and value of the running
timer. The running timer used to calculate the current tick is left to
overflow in hardware and doesn't have this drift.
An odd bug (c0951c9) in the NCS36510 ticker code caused the timer/ticker
classes to become desynchronized. Updated the handling to not assume the
timers are perfectly in synch. This will increase the event's tolerance of
less robust platforms.
Fixes #2989. It was always true for valid values (if its not 8 neither 16 bits, fail).
It is added between I2C commands as I2C_COMMAND_FIFO is too fast to push commands out.
I modified the bug in PR #3289. But It seems not enough the changes.
For the reason, It occured the following issue.
#3694
So I reviewed and re-modified about the setting of initial value of interrupt edge in "gpio_irq_init".
@sg- sg- force-pushed the release-candidate branch from 79c2c1f to e0b27cc Compare February 24, 2017 21:03
@bridadan
Copy link
Contributor

/morph test-nightly

@mbed-bot
Copy link

Result: ABORTED

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1594

Build failed!

@bridadan
Copy link
Contributor

/morph test-nightly

@bridadan
Copy link
Contributor

/morph export-build

@mbed-bot
Copy link

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph export-build

Output

mbed Build Number: 129

All exports and builds passed!

@mbed-bot
Copy link

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1595

All builds and test passed!

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 27, 2017

LGTM, I checked the regression for mbed 2, did not find any. Please let me know

@0xc0170 0xc0170 merged commit 5faf4b2 into mbed-os-5.3 Feb 27, 2017
@adbridge
Copy link
Contributor Author

adbridge commented Feb 27, 2017

mbed-os 2 results:
Platform/target compilations/tests - no regressions from last release.
MBED_37 and MBED_38 have 20/24 passing tests, previous release had 23/27 passing tests. So it looks like 3 less (passing tests) were run. If any of the reported failures are regressions they will not block the release but may generate a known issue if applicable.

@tbondar tbondar mentioned this pull request Mar 1, 2017
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.