Kinetis update to fix tickless #11412

mmahadevan108 · 2019-09-04T16:30:23Z

Description

Pull request type

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

mmahadevan108 · 2019-09-04T16:30:50Z

cc @0xc0170 @jamesbeyond @kjbracey-arm @maciejbocianski

ciarmcom · 2019-09-04T17:00:27Z

@mmahadevan108, thank you for your changes.
@maclobdell @ARMmbed/mbed-os-maintainers please review.

kjbracey

Looks basically good to me, except for the apparently unbalanced PRE/POST calls - please check that.

Other stuff is basically style bike-shedding you can take with a pinch of salt.

kjbracey · 2019-09-05T08:08:24Z

targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_K66F/serial_api.c

+    int clock_enabled = 0;
+    switch (uart_index) {
+        case 0:
+            clock_enabled = (SIM->SCGC4 & SIM_SCGC4_UART0_MASK) >> SIM_SCGC4_UART0_SHIFT;


Personally, I'd be inclined to pare this down to more like:

static bool serial_is_enabled(uint32_t uart_index) { switch (uart_index) { case 0: return SIM->SCGC4 & SIM_SCGC4_UART0_MASK; default: return false; } }

Let bool take the strain. But this is fine.

kjbracey · 2019-09-05T08:09:15Z

targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_K66F/serial_api.c

+
+        /* Check if data is waiting to be written out of transmit buffer */
+        if (!(kUART_TransmissionCompleteFlag & UART_GetStatusFlags((UART_Type *)base))) {
+            uart_tx_ongoing = 1;


Again, I'd just return true. But maybe doesn't fit the style in this unit.

kjbracey · 2019-09-05T08:13:48Z

targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_IMX/sleep.c

-    serial_wait_tx_complete(STDIO_UART);
+    /* Check if any of the UART's is transmitting data */
+    if (serial_check_tx_ongoing()) {
+        return;


Aha! This is actually an approach I hadn't considered, and it is actually much better than waiting or going into shallow sleep. Thank you.

Returning is best here. This gives waking interrupts a chance to operate, rather than sitting there looping with interrupts disabled inside the HAL - possibly bad for performance. The core code will re-enable interrupts briefly, giving them a chance to execute, and then come back here again if it still wants to sleep. The loop will happen at a higher level, with proper "I've changed my mind about sleeping" checks.

Except it looks unbalanced with respect to the vPortPRE_SLEEP_PROCESSING above. Should this check be done before that?

Aha! This is actually an approach I hadn't considered, and it is actually much better than waiting or going into shallow sleep. Thank you.

Returning is best here. This gives waking interrupts a chance to operate, rather than sitting there looping with interrupts disabled inside the HAL - possibly bad for performance. The core code will re-enable interrupts briefly, giving them a chance to execute, and then come back here again if it still wants to sleep. The loop will happen at a higher level, with proper "I've changed my mind about sleeping" checks.

Except it looks unbalanced with respect to the vPortPRE_SLEEP_PROCESSING above. Should this check be done before that?

I have addressed the unbalannce PRE/POST by moving the serial check earlier.

kjbracey · 2019-09-05T08:14:47Z

targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_IMX/sleep.c

@@ -19,8 +19,7 @@

 extern void vPortPRE_SLEEP_PROCESSING(clock_mode_t powermode);
 extern void vPortPOST_SLEEP_PROCESSING(clock_mode_t powermode);
-extern void serial_wait_tx_complete(uint32_t uart_index);
-
+extern int serial_check_tx_ongoing();


Should really be bool. I think only reason there's not much bool in the existing code is because it predates C99 being enabled in Mbed OS. Oh, and (void). This isn't C++ - still need (void) in declarations, or else you're leaving parameters unspecified.

I have changed this to bool.

The code checks if any of the UART's is still transmitting. If so then prevent from entering deepsleep Signed-off-by: Mahesh Mahadevan <[email protected]>

We should not block in case the UART is busy transmitting. The API has been updated to check the status of all UART's and return 1 in case any of them is busy transmitting. Signed-off-by: Mahesh Mahadevan <[email protected]>

The code checks if any of the UART's is still transmitting. If so then prevent from entering deepsleep Signed-off-by: Mahesh Mahadevan <[email protected]>

We should not block in case the UART is busy transmitting. The API has been updated to check the status of all UART's and return 1 in case any of them is busy transmitting. Signed-off-by: Mahesh Mahadevan <[email protected]>

0xc0170 · 2019-09-06T11:01:30Z

CI started

mbed-ci · 2019-09-06T12:41:33Z

Test run: FAILED

Summary: 1 of 4 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

jenkins-ci/mbed-os-ci_build-GCC_ARM

mmahadevan108 · 2019-09-06T12:44:10Z

Build failures do not seem related to this PR

0xc0170 · 2019-09-06T12:47:50Z

CI restarted

mbed-ci · 2019-09-06T15:00:12Z

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 2
Build artifacts

jamesbeyond · 2019-09-06T16:17:17Z

Hi @0xc0170, this issue, has bigger impacts, and fails one of mbed-os example, I suggest get it into mbed-os-5.14-rc2

0xc0170 · 2019-09-09T08:36:12Z

Release version updated as requested, cc @adbridge

ciarmcom requested review from maclobdell and a team September 4, 2019 17:00

ciarmcom added the needs: review label Sep 4, 2019

mmahadevan108 mentioned this pull request Sep 4, 2019

Temporarily disable tickless on K64F #11403

Closed

0xc0170 approved these changes Sep 4, 2019

View reviewed changes

0xc0170 requested a review from kjbracey September 4, 2019 19:36

kjbracey reviewed Sep 5, 2019

View reviewed changes

0xc0170 added needs: work and removed needs: review labels Sep 5, 2019

0xc0170 self-requested a review September 5, 2019 08:56

mmahadevan108 added 2 commits September 5, 2019 13:58

MCUXpresso: Change the Kinetis deep sleep implementation

6eca8d2

The code checks if any of the UART's is still transmitting. If so then prevent from entering deepsleep Signed-off-by: Mahesh Mahadevan <[email protected]>

mmahadevan108 force-pushed the Kinetis_Update_To_Fix_Tickless branch from a47f5eb to 5c48e4e Compare September 5, 2019 19:13

mmahadevan108 added 2 commits September 5, 2019 14:16

MCUXpresso: Change the MXRT deep sleep implementation

b30e294

The code checks if any of the UART's is still transmitting. If so then prevent from entering deepsleep Signed-off-by: Mahesh Mahadevan <[email protected]>

MCUXpresso: Update the MXRT Serial driver for MBED_TICKLESS

31da8ff

We should not block in case the UART is busy transmitting. The API has been updated to check the status of all UART's and return 1 in case any of them is busy transmitting. Signed-off-by: Mahesh Mahadevan <[email protected]>

mmahadevan108 force-pushed the Kinetis_Update_To_Fix_Tickless branch from 5c48e4e to 31da8ff Compare September 5, 2019 19:16

kjbracey approved these changes Sep 6, 2019

View reviewed changes

0xc0170 added needs: CI release-version: 5.14.1 and removed needs: work labels Sep 6, 2019

0xc0170 added release-version: 5.14.0-rc2 and removed release-version: 5.14.1 labels Sep 9, 2019

0xc0170 added ready for merge and removed needs: CI labels Sep 9, 2019

0xc0170 merged commit f35e16e into ARMmbed:master Sep 9, 2019

0xc0170 removed the ready for merge label Sep 9, 2019

This was referenced Sep 11, 2019

[Mbed OS OoB 5.14] System reboot due to fatal error ARMmbed/mbed-os-example-lorawan#164

Closed

Hard Fault while using 5 DIO pins ARMmbed/mbed-semtech-lora-rf-drivers#38

Closed

mmahadevan108 deleted the Kinetis_Update_To_Fix_Tickless branch April 6, 2020 15:46

Kinetis update to fix tickless #11412

Kinetis update to fix tickless #11412

Uh oh!

Conversation

mmahadevan108 commented Sep 4, 2019

Description

Pull request type

Uh oh!

mmahadevan108 commented Sep 4, 2019

Uh oh!

ciarmcom commented Sep 4, 2019

Uh oh!

kjbracey left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xc0170 commented Sep 6, 2019

Uh oh!

mbed-ci commented Sep 6, 2019

Uh oh!

mmahadevan108 commented Sep 6, 2019

Uh oh!

0xc0170 commented Sep 6, 2019

Uh oh!

mbed-ci commented Sep 6, 2019

Uh oh!

jamesbeyond commented Sep 6, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

0xc0170 commented Sep 9, 2019

Uh oh!

Uh oh!

jamesbeyond commented Sep 6, 2019 •

edited

Loading