Build process produces hex files which will not install on BBC micro:bit

Describe the bug
Building for BBC micro:bit against v1.14.0-rc2 I found that often (but not always) the resultant hex file would not copy onto the device over USB. micro:bit is an mbed device and flashing involves copying the binary hex file to a target USB drive. Copying would fail like this:

C:\workspaces\zephyr_projects\peripheral_hr\build>copy zephyr\zephyr.hex d:
The system cannot find the file specified.
0 file(s) copied.

and the mbed USB drive would disconnect. Physically unplugging the USB cable and plugging it in again would bring back the mbed drive.

The hello_world sample project builds and installs OK.

The bluetooth/peripheral_hr project exhibits the problem.

To Reproduce
Steps to reproduce the behavior:

1. Check out tag
2. Set up the bluetooth/peripheral_hr project for BBC micro:bit with

cmake -GNinja -DBOARD=bbc_microbit ..

3. Build with

ninja

4. Attempt to install to a USB connected micro:bit (assuming assigned drive letter is D: on Windows)

copy zephyr\zephyr.hex d:

Expected behavior

The hex file should successfuly copy to the mbed drive and the mbed drive should stay connected to the host computer:

C:\workspaces\zephyr_projects\peripheral_hr\build>copy zephyr\zephyr.hex d:
1 file(s) copied.

Instead, this happens:

C:\workspaces\zephyr_projects\peripheral_hr\build>copy zephyr\zephyr.hex d:
The system cannot find the file specified.
0 file(s) copied.

Impact
Have to work with 1.14.0-rc1. Showstopper for 1.14.0 if this is not fixed though.

Screenshots or console output

Environment (please complete the following information):

• OS: Windows
• Toolchain: Zephyr 1.14.0-rc2 with ninja
• Commit SHA or Version used

I used git bisect and determined that the following commit is probably where the problem was introduced:

af10d16 is the first bad commit
commit af10d16
Author: Daniel Leung daniel.leung@intel.com
Date: Sat Mar 9 00:58:57 2019 -0800

linker: sort sections by alignment

This turns on the linker flag to sort sections by alignment
in decreasing size of symbols. This helps to minimize
padding between symbols.

This also adds the linker options to sort common symbols by
alignment in descending to minimize the need for padding.

Signed-off-by: Daniel Leung <daniel.leung@intel.com>

:100644 100644 4e04694a38b07ddb063b7755bdbe932dd87b7de5 3ab4ef394cce8ea560304345f9d91165a77b54da M CMakeLists.txt

Additional context

It's been pointed out to me that this commit has relevance:

#14563

[carlescufi]

Setting this as high since it completely breaks more than one board. The alternative right now is
#14563

[galak]

Curious if anyone's tried to reproduce this using Linux SDK, is this a windows issue, and which windows toolchain is being used or a general linker/link script issue?

@galak what do you need to know about my Windows development environment, exactly?

FYI I just experienced this problem building against v1.14.0-rc1 which I had previously found to be OK.

[dcpleung]

On qemu_arc, the ro_data section was not 4-byte aligned (in terms of address and size) after sorting. Maybe this is similar to that? (see 507f8ca)

[WilliamGFish]

Not sure what is happening here as there are too many conflicting questions. I'll attempt to help but may be some misinterpretation by me:

1. Size of compiled hex for Micro-bit in 1.14; just used West to build and flash and it worked first time
2. Ninja highlights that the resulting file uses SRAM: 16268 B 16 KB 99.29% this is dangerously high yet did work.
3. The line command copy is an unusual method to transfer the file, as the first action of the MCU is to reset and run program. I expect that would cause the drive to at least momentarily disconnect hence you receive the "cannot find file" error.
4. The resulting hex file is normally found in a "build" sub-directory within the application/sample directory which to may be causing issues.

For building and flashing I use both CMake / ninja and the Zephyr West Tool, simply follow the Getting Started instructions.

Environment:
Win10, Zephyr 1.14 rc2

Almost forgot to mention that i even connected to my micro-bit using an Android phone and nRF Toolbox, all worked well.

If you have more question or further detail let me know.

Billy,,

[dcpleung]

Could you try this dcpleung@f8ff64d and see if it fixes the issue?

[WilliamGFish]

I've just pulled the v1.13 branch and the sample does not build for Micro-bit. It will not fit in memory.

SRAM: 16400 B 16 KB 100.10%

Struggling to build in 1.12 without some reconfiguration.

@bluetooth-mdw Martin are you using this for BLE Training sessions? Either way let me know the state of this. Thanks

[WilliamGFish]

The easiest option would be to create a micro-bit specific .conf and reduce the stack size to free up some space (CONFIG_MAIN_STACK_SIZE=512)

This is exactly how the is resolved in the Mesh examples.