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

[ghost]

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 [email protected]
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 <[email protected]>

: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?

[ghost]

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

[ghost]

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.

[carlescufi]

@bluetooth-mdw

I have tried to reproduce this but I have not suceeded.
I am on Windows 10 with:

• GNU Arm Embedded: 7 2018-q2-update
• af10d16 and current master

[carlescufi]

@WilliamGFish thanks for the feedback, but that is a different issue altogether unless I am mistaken. Overflowing the SRAM and flash areas is unrelated to the issue that @bluetooth-mdw is seeing, which is a malformed image.

[ghost]

For some reason I've not been receiving notifications, even when @bluetooth-mdw is in the comment. Testing, testing. Will check spam folder!

Anyway, just recreated with v1.14.0-rc2 and the peripheral_hr sample. Intend to upgrade my ARM toolchain as I'm running with something from 2017.

arm-none-eabi-gcc.exe (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 (release) 

[ghost]

Updated ARM tools and now I get this:

2018-q4-major\bin\a
rm-none-eabi-readelf.exe" -e zephyr.elf > zephyr.stat""
C:\Program Files (x86)\GNU Tools ARM Embedded\8 2018-q4-major\bin\arm-none-eabi-objcopy.exe: zephyr.hex 64-bit address 0x4b4fa300000000 out of
range for Intel Hex file
C:\Program Files (x86)\GNU Tools ARM Embedded\8 2018-q4-major\bin\arm-none-eabi-objcopy.exe:zephyr.hex: bad value
ninja: build stopped: subcommand failed.

[carlescufi]

@bluetooth-mdw that is a known bug in 8-2018-q4-major. You need to install 7-2018-q2-update instead.

[ghost]

Thanks @carlescufi . Installed the q2-update version and with 1.14-rc2 I still get the same problem:

Configuration written to 'C:/workspaces/zephyr_projects/peripheral_hr/build/zephyr/.config'
-- Cache files will be written to: C:\Users\Martin\AppData\Local/.cache/zephyr
-- The C compiler identification is GNU 7.3.1
-- The CXX compiler identification is GNU 7.3.1
-- The ASM compiler identification is GNU
-- Found assembler: C:/Program Files (x86)/GNU Tools Arm Embedded/7 2018-q2-update/bin/arm-none-eabi-gcc.exe
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
-- Configuring done
-- Generating done
-- Build files have been written to: C:/workspaces/zephyr_projects/peripheral_hr/build

C:\workspaces\zephyr_projects\peripheral_hr\build>ninja
[152/157] Linking C executable zephyr\zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      105247 B       256 KB     40.15%
            SRAM:       16268 B        16 KB     99.29%
        IDT_LIST:         104 B         2 KB      5.08%
[157/157] Linking C executable zephyr\zephyr.elf

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

With 1.14-rc1 checked out, I don't get this problem. The hex file installs fine. This does seem to be 1.14-rc2 related.

[carlescufi]

@bluetooth-mdw I wonder what the difference is then. I cannot reproduce this on my machine at all, using the exact same commands as you and the same toolchain.

[ghost]

It seems to relate to an older version of the DAPLink firmware on my micro:bit.

The problem occurs with my old microbit which states Interface version 0234 in the Details.txt file which is accessible via the mbed mass storage drive. I updated to 0250 per https://microbit.org/guide/firmware/ and re-tested. The problem did not occur. I also tested with another micro:bit that had Interface Version 0241 and that did not exhibit the problem either.

git bisect did point to a commit that related to the linker so I suspect there's a bit more to this than just a bug in the DAPLink firmware but it seems a solution has been found.

Closing this issue.