Skip to content

Fixing test builds for devices with softdevices. #1937

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

Merged
merged 1 commit into from
Jun 15, 2016

Conversation

bridadan
Copy link
Contributor

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 adds an option to copy hex files when compiling source as a library. This is currently being used when compiling tests within test.py

Please review @0xc0170 and @screamerbg
FYI @pan-

@0xc0170
Copy link
Contributor

0xc0170 commented Jun 14, 2016

What about static libraries, like there are bootloaders as static libs or just another software that can't be open sourced , but has to be included in the build?

@screamerbg
Copy link
Contributor

Can we copy hex files by default and drop the parameter? This is for library builds after all and do not affect application build.

@bridadan
Copy link
Contributor Author

I was hesitant to do this because I wasn't sure if the build_library function was used throughout the tools or just in this case. If you're confident this won't cause issues then I'm fine with making it the default behavior.

@sg-
Copy link
Contributor

sg- commented Jun 14, 2016

@bridadan see comments above. Dont modify build lib. its legacy

@bridadan bridadan force-pushed the fix-tests-softdevices branch from 9dbb13c to 6caf158 Compare June 15, 2016 08:17
@bridadan
Copy link
Contributor Author

@mbed-bot: TEST

HOST_OSES=windows
BUILD_TOOLCHAINS=GCC_ARM,ARM
TARGETS=NRF51822,NRF51_DK

@mbed-bot
Copy link

[Build 482]
FAILURE: Something went wrong when building and testing.

@bridadan
Copy link
Contributor Author

bridadan commented Jun 15, 2016

The build bot didn't try and build the tests locally, but I just tried. I'm getting the following linker error when building for the NRF51822 with GCC_ARM for many of the tests:

* NRF51822::GCC_ARM::RTOS_1
        Building project basic (NRF51822, GCC_ARM)
        Link: basic
        C:/Users/bridan01/Documents/dev/mbed/build/mbed/TARGET_NRF51822/TOOLCHAIN_GCC_ARM/NRF51822.ld:133 cannot move location counter backwards (from
 20004330 to 20003800)

@c1728p9 Do you know if this is because the tests are too big to fit in the ROM? I'm not familiar with this error

cc @pan-

@pan-
Copy link
Member

pan- commented Jun 15, 2016

@bridadan To makes mbed BLE works with the RTOS work, the main stack size has been changed.
Apparently there is not enough RAM left for the NRF51822, when this test is build.

Let me have a look, maybe it is possible to gain memory from elsewhere.

@@ -149,7 +149,8 @@
name="mbed-build",
macros=options.macros,
verbose=options.verbose,
archive=False)
archive=False,
copy_hex_files=True)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bridadan please remove the copy_hex_files=true. I think this was a leftover

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the catch! I've updated the commit.

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.
@bridadan bridadan force-pushed the fix-tests-softdevices branch from 6caf158 to 5a46ac7 Compare June 15, 2016 14:21
@sg-
Copy link
Contributor

sg- commented Jun 15, 2016

Thanks!! 👍

@sg- sg- merged commit fd983d1 into ARMmbed:master Jun 15, 2016
@screamerbg
Copy link
Contributor

This is still not propagated to Nordic's repository and they cannot use it.

@sg- @pan- @bridadan

@bridadan
Copy link
Contributor Author

@screamerbg Do we need to resolve this? Or maybe @pan- can help them rebase/update their fork?

@pan-
Copy link
Member

pan- commented Jun 22, 2016

@bridadan You don't need do it, I will just cherry-pick your commit.

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.

6 participants