Skip to content
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

Release candidate for mbed-os-5.9.3 #7515

Closed
wants to merge 113 commits into from
Closed

Conversation

cmonr
Copy link
Contributor

@cmonr cmonr commented Jul 15, 2018

No description provided.

theotherjimmy and others added 30 commits July 13, 2018 14:03
This will make incremental compile more complete, taking device_has and
inheritance hierarchy into account.
Keep same clock configuration as done before this PR (LSE and PCLK1).
Use a JSON file to change it.
* Elevate RTC2 interrupt priority to same level as UARTE to prevent
race condition on shared variables.
* Remove unused TXDRDY event code.
* Fix typo in macro.
UART configuration parameters mispelled.
Use of MSG_FLAGS was updated in previous PRs but the doc was not updated
accordingly.
Copy edit for precise language and comma use.
Copy edit for precise language and comma use.
Setting ""nsapi.dns-cache-size": 0" still left some of the DNS
caching code in. Add crude #if to remove all of it.
This allows one to save 429 bytes of flash and 48 bytes of RAM on
ARMC5 builds.
1. Add USTICKER in device_has option of targets.json file.
2. Disable ticker interrupt in us_ticker_init
3. Add us_ticker_free
4. Enable interrupt in us_ticker_set_interrupt
1. Add LPTICKER in device_has option of targets.json file.
2. Disable ticker interrupt in lp_ticker_init
3. Add lp_ticker_free
4. Enable interrupt in lp_ticker_set_interrupt
This can happen with CLK_PowerDown() called first and then CLK_Idle() called.
Mark mbed-os-tests-mbed_hal-common_tickers/time_cpu_cycles not in-lined.
Otherwise, time_cpu_cycles may be in-lined somewhere and takes different
CPU cycles on invocation.
1. Introduce S/W interrupt enable/disable to reduce calls to TIMER_EnableInt/TIMER_DisableInt.
2. Allow dummy interrupt because clear interrupt flag is not synchronized.
3. Enable LPTICKER_DELAY_TICKS to make lp_ticker_set_interrupt non-blocking.
This is to make us_ticker/lp_ticker code consistent.
This is to make us_ticker/lp_ticker code consistent.
It is because dummy interrupt is very rare or pending time caused by it
is very short.
This is to make us_ticker/lp_ticker code consistent.
Deprecated API thus no changes there
I added the powerdown func by GIC in mbed_application because Cortex-A9 use GIC instead of NVIC.
This process prevent unexpected interrupt when updating software by using bootloader.
mprse and others added 22 commits July 13, 2018 14:06
The test sometimes fails on NRF51_DK (test case: "Test: LowPowerTimer - time measurement 1 ms.") in morph tests.

The test verifies if LowPowerTimer class correctly counts elapsed time. Sometimes we got measured ~1600 us for delay 1000 us (delta 550 us).
The delay is performed using `wait_us()` function which for delays greater than or equal to 1 ms (our case) calls `Thread::wait((uint32_t)ms);`. This causes rescheduling and potentially can put board into sleep (deep sleep mode is disabled by `wait_us()`). For our test purposes we don't need rescheduling/sleep since this actions takes extra time and have influence on the time measurement accuracy.
The solution is to implement function for delay which is based on busy loop and uses us ticker. It has been verified that this solves the problem. With this fix when measurement of 1 ms is repeated 1000 times we got usually measured time equal to ~1080 us, and sometimes ~1300us (checked that this is caused by systick interrupt handling). Since this is test for drivers layer and the results are acceptable I decided to not disabling systick in the test).
It was pointed out in #7432 and #7232 that the stack was comparing frame payload size
with the allowed payload size in a wrong manner in shcedule_tx().
We must strip the overhead from the frame before comparison.

We did have a similar check in prepare_ongoing_tx() API which would correctly analyse
the situation but a check was needed in schedule_tx() as well. The reason is that the
schedule_tx() API can be called automatically by the stack if the user intiated requested
was not promptly entertained because of duty cycle restriction. Now, the datarate can change
here (for CONFIRMED messages if the ack was not received after retries max out). That's why
a test for validity was needed.

We now perform a comparison using _ongoing_tx_message structure which contains the actual
FRMPayload size.

For proprietary type of messages only MHDR and Port field is used so we shouldn't add MAC commands
and other overhead into them.

In order to have consistent frame overhead, we have opted to always include Port field in the
frame.
timeout unit should be ms not micro second.
No files to build - should not be in targets
Reverts part of the #6178
This is a remedy for the issue #7230.
While the device is joining, LORAWAN_STATUS_CONNECT_IN_PROGRESS is returned.
However, if the device is already joined, we will return LORAWAN_STATUS_ALREADY_CONNECTED.
API documentation is updated to clear how the connection related return codes will
work from now on.
For ABP: First call to connect() or connect(params) will return LORAWAN_STATUS_OK
         and a CONNECTED event will be sent. Any subsequent call will return
         LORAWAN_STATUS_ALREADY_CONNECTED (posix EISCONN) and no event is generated.

FOR OTAA: First call to connect() or connect(params) will return LORAWAN_STATUS_CONNECT_IN_PROGRESS
          and a CONNECTED event will be sent whenever the JoinAccept is received. If the application
          calls connect again before receiving the CONNECTED event, LORAWAN_STATUS_BUSY will be returned.
          After the CONNECTED event is dispatched, any subsequent call to connect() or connect(params) API
          will be returned with LORWAN_STATUS_ALREADY_CONNECTED.

No new parameters are accepted after the first call. The application must disconnect before making
a connect() call with new parameters.
…eep-sleep.

Serial buffer must be flushed before entering deep sleep mode. In the test this is done by the additional delay which is implemented on the busy loop which decrements given value down to 0 (`void wait_cycles(volatile unsigned int cycles)`). This solution is not appropriate since it is very target specific and the cycles value has been already increased few times. Additionally very big number of loop cycles which is suitable for fast targets may take much longer on slower boards and results in test timeout.
It has been verified that 20ms is sufficient delay for the green-tea transmission. In this test we cannot simply use `wait_ms(20)` since this potentially may put board to sleep and wake up using lp ticker. The test re-initialzies the lp ticker(disables ticker interrupt) and this operation may break the schedule and time tracing by the upper layer. But we can use us ticker which is not affected by this test. The solution is to add a delay routine based on busy loop and us ticker only. This way are able to wait exactly 20 ms.
Code cleaning (L0 Cube update, comment precision)
This should allow custom targets to be transferred to each process
when building in parallel
@cmonr
Copy link
Contributor Author

cmonr commented Jul 15, 2018

/morph build
/morph mbed2-release

@mbed-ci
Copy link

mbed-ci commented Jul 15, 2018

Build : FAILURE

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

@NirSonnenschein
Copy link
Contributor

Hi @cmonr ,
In case you haven't seen this yet, the build failed because of a real compilation issue. possibly a conflict between the different PRs or something that was left out for some reason.
see:
[Error] LoRaMac.cpp@875,0: #135: class "LoRaPHYEU868" has no member "handle_receive"

[Error] LoRaMac.cpp@903,0: #135: class "LoRaPHYEU868" has no member "handle_receive"

[Error] LoRaMac.cpp@1800,0: #44: expression must have pointer type

@cmonr
Copy link
Contributor Author

cmonr commented Jul 16, 2018

Hmm... Haven't found anything obvious with the LoRa PRs that could be causing this. Suspect it might be related to the tools PRs. Going to close and resubmit after some local testing.

@cmonr cmonr closed this Jul 16, 2018
@cmonr
Copy link
Contributor Author

cmonr commented Jul 16, 2018

Looks like it was a LoRa API coming into 5.10 was the culprit.

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.