LPC1768 us_ticker.c timer choice

[thesupershan]

Description

Adding option for LPC1768 by which user can select which timer to use for us_ticker.c
LPC1768 has available timers: 0, 1, 2 and 3. The default uses the original coded timer: timer 3.

Pull request type

[ ] Fix
[ ] Refactor
[X] Target update
[ ] Functionality change
[ ] Breaking change

[kegilbert]

LGTM (once the == 2 is fixed)! Also squashing if possible would be nice.

[thesupershan]

how does one force ci-* tests to go?

[cmonr]

Hi @thesupershan. Please refer to documentation on contributing to Mbed OS: https://os.mbed.com/docs/latest/reference/workflow.html

In specific, the maintainers group are the only ones that have access to start CI, for a variety of reasons. At the moment, we're prioritizing 5.10.0-rc3 PRs since the 5.10 release is coming up, but once that is out of the way, we'll be working through the needs: CI backlog.

[thesupershan]

got it, i thought they were automatic, thanks

[0xc0170]

/morph build

[mbed-ci]

Build : SUCCESS

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

Triggering tests

/morph test
/morph mbed2-build

[mbed-ci]

Test : FAILURE

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

[0xc0170]

/morph mbed2-build

[0xc0170]

Will restart CI tests a bit later when the queue gets smaller

[studavekar]

/morph test

[studavekar]

/morph export-build

[mbed-ci]

Exporter Build : FAILURE

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

[mbed-ci]

Test : SUCCESS

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

[NirSonnenschein]

/morph export-build

[NirSonnenschein]

/morph export-build

[NirSonnenschein]

/morph export-build

[NirSonnenschein]

/morph export-build

[cmonr]

/morph export-build

[cmonr]

/morph export-build

[cmonr]

@ARMmbed/mbed-os-test Any idea why our commands were being ignored?

[adbridge]

/morph export-build

[cmonr]

ಠ_ಠ

[mbed-ci]

Exporter Build : SUCCESS

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

[thesupershan]

master has e5000ab, but 5.10 pulled 190803a, why did that happen?

[cmonr]

@thesupershan 190803a is the actual commit that contains the code changes. The second commit is a merge commit that describes how two branches were brought together into one.

Our release process cherry-picks PRs according to their label, ignoring merge commits in the process.

[0xc0170]

Before it was edited, there was a mention about a bug on master? Is there any issue with this PR?

[thesupershan]

Yes, the second commit (190803a) has bug of which kegilbert identified above. The merge commit does actually have a code change in it. Sorry if i messed the cherry-pick process, I wanted to squash the merge-commit but alas, they cannot be squashed.

Looks like 5.11 got the e5000ab fix.

So master and 5.11 are correct, but 5.10 is incorrect.

[cmonr]

Woah, that's incredibly subtle and frustrating.

@0xc0170 Not master, but the 5.10 branch. The merge commit wasn't picked up in the release process, which left the lone fix behind.

I'm really dissapointed at GitHub for not being able to indicate this single line change properly.

@thesupershan Thanks for catching this. This will definitely need to be fixed with our release process. 5.11 doesn't have the problem because the branch was created by branching off of master, which does have merge commits.

[deepikabhavnani]

Not master, but the 5.10 branch.

I am bit confused here, release tag says 5.10.2 -> It means it was merged after 5.10 was released.

[cmonr]

@thesupershan Will have to confirm Monday, since most of my cohorts are on the other side of the globe and it's the weekend already, but odds are since we're about to finish the release process for 5.11.0, this will remain as a known issue for 5.10.

We're definitely going to look into updating our release process, and this gives us a test case to validate our updates. We don't want to discourage collaboration on the author's side of a PR :)

@deepikabhavnani The problem appears to be that the script that we use to bring PRs from master into a PR for a given release is skipping merge commits.

[thesupershan]

@cmonr, thanks for the digging, feedback and input, much appreciated! I have a work-around for 5.10 so i'm all set.

[0xc0170]

@cmonr Is this issue being tracked anywhere? Please create an issue

[cmonr]

@0xc0170 Patch release process issue created. The LPC issue is not an issue for 5.11, and is a won't-fix for 5.10 since we don't have a process to backport problems in older releases.