hello_world not working on frdm_k64f/qemu_cortex_m3 with newlib and arm gcc embedded 2018q2

[nashif]

crashes already when flashing...

====================] 100%
INFO:root:Programmed 34312 bytes (9 pages) at 16.04 kB/s
ERROR:root:link exception during link disconnect:
Traceback (most recent call last):
  File "build/bdist.linux-x86_64/egg/pyOCD/board/board.py", line 74, in uninit
    self.link.disconnect()
  File "build/bdist.linux-x86_64/egg/pyOCD/pyDAPAccess/dap_access_cmsis_dap.py", line 627, in disconnect
    self.flush()
  File "build/bdist.linux-x86_64/egg/pyOCD/pyDAPAccess/dap_access_cmsis_dap.py", line 589, in flush
    self._read_packet()
  File "build/bdist.linux-x86_64/egg/pyOCD/pyDAPAccess/dap_access_cmsis_dap.py", line 744, in _read_packet
    decoded_data = cmd.decode_data(raw_data)
  File "build/bdist.linux-x86_64/egg/pyOCD/pyDAPAccess/dap_access_cmsis_dap.py", line 419, in decode_data
    data = self._decode_transfer_data(data)
  File "build/bdist.linux-x86_64/egg/pyOCD/pyDAPAccess/dap_access_cmsis_dap.py", line 315, in _decode_transfer_data
    raise DAPAccessIntf.TransferFaultError()
TransferFaultError: SWD/JTAG Transfer Fault

with qemu:

To exit from QEMU enter: 'CTRL+a, x'
[QEMU] CPU: cortex-m3
/home/nashif/Work/SDK/0.9.4-rc1/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -vga none -pidfile qemu.pid -serial   mon:stdio -kernel /home/nashif/Work/github/zephyr/build/zephyr/zephyr.elf
qemu: fatal: Trying to execute code outside RAM or ROM at 0x00040000

R00=00000430 R01=00000000 R02=00000218 R03=20000000
R04=00000218 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=20000f10 R14=00000dc9 R15=00040000
PSR=00000173 ---- T svc32
FPSCR: 00000000
make[3]: *** [zephyr/CMakeFiles/run.dir/build.make:60: zephyr/CMakeFiles/run] Aborted (core dumped)
make[3]: Leaving directory '/home/nashif/Work/github/zephyr/build'
make[2]: *** [CMakeFiles/Makefile2:379: zephyr/CMakeFiles/run.dir/all] Error 2
make[2]: Leaving directory '/home/nashif/Work/github/zephyr/build'
make[1]: *** [CMakeFiles/Makefile2:386: zephyr/CMakeFiles/run.dir/rule] Error 2
make[1]: Leaving directory '/home/nashif/Work/github/zephyr/build'
make: *** [Makefile:209: run] Error 2
make: Leaving directory '/home/nashif/Work/github/zephyr/build'

[MaureenHelm]

I'm not able to reproduce this. It works fine for me on frdm_k64f and qemu_cortex_m3.

[nashif]

hmm

cmake -DCONFIG_NEWLIB_LIBC=y -DBOARD=qemu_cortex_m3 -Bbuild -Hsamples/hello_world; make VERBOSE=1 -C build/ -j20 run

with

export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE=/home/nashif/Work/SDK/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-

but if I use

export ZEPHYR_TOOLCHAIN_VARIANT=gccarmemb

it works. @SebastianBoe any idea?

[MaureenHelm]

I did the latter

[SebastianBoe]

Looking at the zephyr.map diff between gccarmemb and cross-compile it is clear that cross-compile is not using a thumb libc implementation.

I was able to reproduce the failure when CROSS_COMPILE was used.

However adding the flag

-DLIBC_LIBRARY_DIR=/home/sebo/Downloads/gcc-arm-none-eabi-7-2018-q2-update/arm-none-eabi/lib/thumb/v7-m

resolved the issue again.

The difference between cross-compile and gccarmemb is that with gccarmemb we are successfull in finding the correct newlib libc implementation, but cross-compile is not. gccarmemb.cmake sets SYSROOT_DIR, which in turn causes gcc.cmake to execute 'gcc --print-multi-directory' and detect the correct newlib libc implementation.

The libc build scripts has this to say about detecting the correct libc implementation:

# LIBC_*_DIR may or may not have been set by the toolchain. E.g. when
# using ZEPHYR_TOOLCHAIN_VARIANT=cross-compile it will be either up to the
# toolchain to know where it's libc implementation is, or if it is
# unable to, it will be up to the user to specify LIBC_*_DIR vars to
# point to a newlib implementation.

Fundamentally, auto-detection of the correct toolchain flags is believed to not be possible with cross-compile. So using it is always at one's own risk and maintenance. It is recommended to develop a toolchain cmake file to support a toolchain instead of using cross-compile.

If it was possible, we would not need any toolchain cmake files ...

To have this just-work one could try to extract the sysroot_dir or the newlib_dir from the compiler. But I don't know how to do this ...

Until this is figured out users should use gccarmemb instead of cross-compile.

[galak]

This looks to be fixed. I think commit aa049e5 fixes this issue.