Add kw24 support #2966
Add kw24 support #2966
Conversation
mmahadevan108
force-pushed
the
Add_KW24_Support
branch
from
e2e017b
to
fae0ea0
Compare
|
Below is the DAP Link binary for FRDM-KW24 board. Please rename to remove the .txt extension |
|
@mmahadevan108 nice! |
|
Why was this closed? |
|
Don't know. I might have done something by accident. Thanks. |
|
/morph test |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 1095 All builds and test passed! |
|
I ran automated tests locally and see a few fails. Please check. |
|
I see the below with all toolchains. All other tests passed. Below is what I see related to the 2 ERROR's from Low Power Timer tests: mbedgt: test suite 'mbed-os-tests-mbed_drivers-lp_timeout' ........................................... OK in 22.14 sec mbedgt: test suite 'mbed-os-tests-mbed_hal-lp_ticker' ................................................ OK in 21.90 sec utest is reporting all tests to pass, I am not sure why this is reported as an ERROR. |
|
@mmahadevan108 The fact that utest reported all tests as passing when there is an |
|
I don't see it fail when I run in verbose mode. My feeling is this is something to do with the way the test is written as I have confirmed the platform goes in and exits deepsleep mode successfully. |
|
@mmahadevan108 It's possible, I admit I'm not all that familiar with that particular test case. The fact that it passes when ran in exclusion is a good sign that it isn't actually broken. Is the same true for the lp_ticker test? |
|
Yes, same observation with the lp_ticker test. Results below: c:\cygwin\home\r9aadq\my_mbed>mbed test --run -t GCC_ARM -m KW24D -n mbed-os-tests-mbed_hal-lp_ticker -v |
|
@mmahadevan108 I can confirm that my results correlate with yours. The other fails I saw were due to having an old greentea version. |
|
Ready for merge?!? @mmahadevan108 @maclobdell @bridadan |
|
I'm starting to see some actual test failures that happen intermittently. Here's what I've been able to reproduce after running the tests a few times (it doesn't fail every time). I had to run There is a failure for the This is the problem line: The test tools expect a new line to be printed at the end of Also, I received the following failure for the The line EDIT: I mistakenly labled the |
|
I am confused by your analysis. The comment says the failure is related to deepsleep test but the test log shows failures in 500us lp_ticker which is different.
I have not seen this failures in this test case after running multiple times. I have no idea on the serial issue, why would it show up only when running this test. Could it be related to the amount of time the test waits for deepsleep to complete. |
|
@mmahadevan108 You're right, I mistakenly commented that the case was the deepsleep test, sorry about that! I meant to write it was the 500 us lp_ticker test. I only saw it happen once, so it may be a very rare case when it happens, but because the failure message was so clear I wanted to post it here in case you had any ideas. |
|
No idea. I have not been able to reproduce failure in the 500us lp_ticker case. The sleep code is fairly simple. |
|
With regards to the deepsleep test, deepsleep shuts off the UART peripheral, correct? This would be a good explanation as to why we're seeing the data get corrupted. The thing is, there shouldn't be any more serial data in the buffers since |
|
The UART does have a FIFO. I could potentially flush the serial FIFO in the deep sleep function before going into deepsleep mode. |
|
We've actually come across this before, and there has been quite a lengthy discussion on this: #1849 It looks like I was mistaken about We may need to look into flushing the buffers in the test framework each time to ensure the all the output has been sent. This affects other platforms, not just this one. This particular issue shouldn't block this PR though. As far as the 500us lp_ticker test, if we start to see it more often I suppose we can always come back to it. |
|
Sounds like this problem exists across most all boards. A |
|
Yeah most likely that's best we can do in terms of a fix for now. Since the test framework is using RawSerial, it's essentially calling the serial C hal directly. Maybe we need to extend the C hal and the SerialBase class with a function for checking to see if there is anything in the FIFO? |
|
@mmahadevan108 There's a conflict with |
mmahadevan108
force-pushed
the
Add_KW24_Support
branch
from
fae0ea0
to
60dac07
Compare
|
I have updated the PR to resolve the conflict in targets,json |
|
Thanks @mmahadevan108 ! /morph test |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 0 All builds and test passed! |
mmahadevan108
force-pushed
the
Add_KW24_Support
branch
from
60dac07
to
509f57f
Compare
|
@maclobdell I have added some additions to the PinNames.h file to include pins used to communicate with the RF chip. Thanks Mac for finding this. |
|
/morph test |
Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
… than setting the clock mode. Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
mmahadevan108
force-pushed
the
Add_KW24_Support
branch
from
509f57f
to
7e26876
Compare
|
@bridadan @maclobdell /* SPI defines used to communicate with the MCR20 RF device */ This is to fix issues seen when testing the MCR20 RF driver. I think this should be the last update needed. Apologies for these late additions. |
Result: FAILUREYour command has finished executing! Here's what you wrote!
|
|
@mmahadevan108 No worries, that explains the above failure. Thanks for the update! /morph test |
|
retest mbed-os |
1 similar comment
|
retest mbed-os |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 0 All builds and test passed! |
0xc0170
added
release-version: 5.2.1
and removed
release-version: 5.2.2
ready for merge
labels
Ports for Upcoming Targets Fixes and Changes 2966: Add kw24 support ARMmbed/mbed-os#2966 3068: MultiTech mDot - clean up PeripheralPins.c and add new pin names ARMmbed/mbed-os#3068 3089: Kinetis HAL: Remove clock initialization code from serial and ticker ARMmbed/mbed-os#3089 2943: [NRF5] NVIC_SetVector functionality ARMmbed/mbed-os#2943 2938: InterruptIn changes in NCS36510 HAL. ARMmbed/mbed-os#2938 3108: Fix sleep function for NRF52. ARMmbed/mbed-os#3108 3076: STM32F1: Correct timer master value reading ARMmbed/mbed-os#3076 3085: Add LOWPOWERTIMER capability for NUCLEO_F303ZE ARMmbed/mbed-os#3085 3046: [BEETLE] Update BLE stack on Beetle board ARMmbed/mbed-os#3046 3122: [Silicon Labs] Update of Silicon Labs HAL ARMmbed/mbed-os#3122 3022: OnSemi RAM usage fix ARMmbed/mbed-os#3022 3121: STM32F3: Correct UART4 and UART5 defines when using DEVICE_SERIAL_ASYNCH ARMmbed/mbed-os#3121 3142: Targets- NUMAKER_PFM_NUC47216 remove mbed 2 ARMmbed/mbed-os#3142
Description
Add support for FRDM KW24D board
mbedgt: test case results: 166 OK
mbedgt: completed in 756.52 sec