NRF52 target and unification with NRF51 #2211
Conversation
Nrf52 port
A new wbase target has been added (NRF5). In this target, commonalities between 51 and 52 will be shared.
Factorization of NRF51 and NRF52 targets.
Introduce nordic SDK v11, cleanup path and targets.
…oved nrf_drv_config.h to MCU specific targets, updated lists of device features, so non-compiling stuff is excluded from build.
PwmOut::pwm renamed to PwmOut::pwm_name
implementation).
Update softdevice references. Add BLE and softdevice related macros. Add specific macros for NRF52_DK.
* Update softdevice offset so they match the offset of sd 2.0. * Update RAM initialization sequence. * Import fs_data section in final binary
Remove duplicated macro "BLE_STACK_SUPPORT_REQD" for MCU_NRF51 add macro "S132" for MCU_NRF52
Ble integration
Previously, .hex files were not copied when building source as a library. This prevents builds that pre compile source as a library and then includes the build directory as the only source (because there is no softdevice present). This PR copies hex files when compiling source as a library.
…pan-/mbed into refactored_serial_api # Conflicts: # hal/targets/hal/TARGET_NORDIC/TARGET_NRF5/sdk/drivers_nrf/uart/nrf_drv_uart.c
|
@sg- @bridadan I don't know what I should do here, as said earlier, the RTOS is build in SINGLE THREAD mode for those targets (build small), it make sense if the RTOS tests fail. I would also add that the tests for mbed-os, are not identical to the tests in mbed-micro. For instance, in the Semaphore test in mbed micro the stack has been adjusted, this is not the case with the test for mbed os. I can do a separate PR to bring those adjustments to the mbed os tests but there is nothing to do in this PR in my opinion. |
Refactored serial_api implementation.
|
@pan- Thanks for making those PRs, looks like they've been merged. I'll go ahead and rerun your PR. This should test both the NRF51_DK and the NRF52_DK. /morph test |
Result: FAILUREYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 513 Test failed! |
|
Ok, so after a quick look at the output: IAR NRF52/NRF51:
NRF51_DK:
|
|
@pan- The @PrzemekWirkus @mazimkhan do you guys have any idea why this is being reported as a failure? Here's the full output from that test: I looked through the rest of the test logs and saw that no other results had the following two keys queued at the same time: Is it possible that this timing is causing an issue? |
|
It definitely can be something with the test tools! Maybe an exception we can't see (suppressed). No idea. For sure @bridadan n Which version of Brian, you may need to delete content of the directory |
|
So I checked it and looks like |
|
@PrzemekWirkus Thanks for the feedback. I was using 1.1.3 which looks like you've since patched. I've corrected the steps to use the latest release now. I'll let you know if something else crops up! |
|
I'll go ahead and run this again. We're currently using IAR v7.40 in the CI, so this may be why the /morph test |
Result: FAILUREYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 525 Test failed! |
In cmsis_os.h OS_TIMERS is undefined unless the timer thread is disabled, in which case it is defined to 0. When comparing against an undefined value, the undefined value will evaluate as if it were 0. Because of this the MAIN_THREAD_ID was always set to 0x1. This patch fixes that problem by checking if OS_TIMERS is defined before comparing it to 0. This problem only effects IAR since it has a different heap/stack layout. GCC_ARM and ARM have a dedicated stack region so the presence of a guard word and stack checking does not cause problems. This problem manifested on the NRF51_DK in the pull request ARMmbed#2211 as a c_strings test failure on floating point. This is because the guard word of the main stack overlapped with standard library data used by sprintf and corrupted it.
|
@mbed-bot: TEST HOST_OSES=windows |
|
/morph test |
|
[Build ${MBED_BUILD_ID}] |
|
@mbed-bot: TEST HOST_OSES=windows |
|
[Build 723] |
Result: FAILUREYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 541 Test failed! |
This patch bring support of NRF52 in mbed-os.
In the process, the following changes were made:
The targets impacted by this change are
NRF51_DKand the newNRF52_DK.Other NRF51 based targets are not impacted by this patch.