Experimental GCC and ARMC6 (armclang) Support

[mbrossard]

This work is in the develop branch. See the instruction at the top of README.md.

We need help testing as many firmwares as possible (see current status of tests with GCC) and in particular cover all HIC (debugger MCUs).

You can download the latest builds on this page to test on currently supported targets.

[stephendpmurphy]

Hey @mathias-arm, I have been using my custom DAP-Link boards running on the F103 for a bit now and can confirm that all features have been working great for me when compiling with the gcc-arm-none-eabi-10-2020-q4-major toolchain.

• I can boot-load the F103 and update my IF firmware no problem ✔️
• I can program and debug my applications using the HID-DAP ✔️
• I can pipe UART data from my target micro to the F103 and then view the data via a Serial port on my PC. ✔️

Great work 👏

I am also working on getting the LPC55S69 tested with @flit.

• I can program and debug my applications using the HID-DAP ✔️
• We can't currently enter the bootloader via an external input - It's yet to be added to the new LPC55S69 source. ❌

A serial port enumerates when connecting the LPC via USB, and I seem to be getting activity on the LED indicating the LPC is receiving UART data from my target, but it doesn't come through on my Serial terminal. @flit FYI. I'll dig into this a bit deeper to rule out my setup.

[stephendpmurphy]

@elfmimi good to know. Thanks for the heads up. I was just adding the macro for CONF_JTAG manually and it appears to compile in the correct code.. I just need to find a darn JTAG target.

[elfmimi]

@stephendpmurphy I tried LPC11U35 + JTAG target. It works, with only a little fix. you'll need ...
this from #821 and this from #544 alongside CONF_JTAG.

[mathias-arm]

It seems the Pitaya Link (schematics) and IBDAP (schematics) are Debug Probes with LPC11U35 and the TDI pin usable. Browsing through the list ofprojects I have only found Ameba RTL8195 Arduino Wireless Board and Cerevo BlueNinja to connect TDI.

I think the subset that enables using JTAG on LPC11U35 should be extracted from #544, and the rest reviewed separately.

[elfmimi]

ok, I see #821 has been also merged into develop branch. that's good.

so I've found some legitimate JTAG targets everyone have at home, The RaspberryPi !
I tried RaspberryPi Zero with lpc11u35_if plus previously mentioned mod. I used openocd and gdb-multiarch. And it worked.
here are information you need to do that.

[stephendpmurphy]

@elfmimi well. We have like 4 of them laying around my desk.. Not sure why I didn't think of it sooner. I'll give it a try 👍

[elfmimi]

This is great. This is what I was waiting for. The fact that it does not require mbed-cli makes me very happy. Thanks a lot! 😃

note: minimal requirements are project_generator==0.11.* pyelftools jinja2 intelhex six
note2: also, I made it not to require six. experimental_compilers...elfmimi:fix_flash_algo

[elfmimi]

I tried building with NMake .

• You do not need MSYS2/MinGW/Cygwin to build.
• You can use CMake which is distributed along with Visual Studio 2019.
• You can use Python available at Microsoft Store. ex. https://www.microsoft.com/p/python-39/9p7qfqmjrfp7
• You do need GCC with support for arm targets. ex. https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
• NMake is also obtainable within "Build Tools for Visual Studio" . But I've not tested.

Build Steps

• install Python and GCC
• open "x64 Native Tools Command Prompt for VS 2019"
• make PATH environment variable to include path for GCC executables, that is path to arm-none-eabi-gcc and others.
• cd %WORKDIR%\DAPLink
• pip install project_generator pyelftools intelhex six
• python -m project_generator generate -t cmake_gcc_arm -p lpc11u35_if
• cd projectfiles\cmake_gcc_arm\lpc11u35_if
• cmake . -G "NMake Makefiles" -B build
• cd build
• nmake

note: you may utilize virtualenv but you still need to install pyelftools intelhex jinja2 to the outer environment. This is because when nmake executes commands with .py extension it will launch python in a new console and virtualenv does not take effect there.
note2: above inconvenience can be solved if pre_build_script and post_build_script are prepended explicitly with python as an interpreter.

[mbrossard]

Regarding the python I considered the issue project-generator/project_generator#474 (automatically pre-pending python in progen). But you are right this could be done in the pre_build_script and post_build_script.

As part of the CMake enhancements to project_generator, I added support for build with different generators, so you should be able to do the last five steps as:

$ python -m project_generator build -t cmake_gcc_arm -o generator=nmake -p lpc11u35_if

The generator options are make, mingw-make, msys-make, ninja and nmake.

Or you can use the wrapper script (which will do some additional post-processing for some supported configurations):

$ python ./tools/progen_compile.py -t cmake_gcc_arm -v -g nmake --parallel lpc11u35_if

[elfmimi]

Thanks. I haven't read that issue. I adopted your patch into cmakelist_gccarm.tmpl locally and it worked fine.
elfmimi/project_generator@18399bf

edit: this has got solved.
There is another problem with nmake. nmake does not have -C option or equivalent for it. I've filed a PR for this.
project-generator/project_generator#484

[elfmimi]

a bit of further investigation out of curiosity.
recent Visual Studios 2017 and 2019 come with optional package called "Embedded and IoT Development" .
which is actually the usual gcc toolchain targeting arm. the very compiler we call arm-none-eabi-gcc !
VS2017 installs: arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437]
to C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Linux\gcc_arm\bin
VS2019 installs: arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.1 20181213 (release) [gcc-8-branch revision 267074]
to C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Linux\gcc_arm\bin
the question is, are these sufficient to compile DAPLink?
unfortunately the version comes with VS2019 has a bug and cannot be used.
the version of gcc which comes with VS2017 works fine. but the version of cmake which comes with VS2017 is a bit too old.
In summary, if you have both VS2017 and VS2019 with proper selection of packages installed, and a python of your choice from Microsoft Store, you already have every piece of software needed to build DAPLink (except python packages you'll install by pip).

[mathias-arm]

There is a non-zero chance that those toolchains could work with many targets. I anticipate they do not support Cortex-M33 (as required by #803) and LTO might not work (required by the lpc11u35_musca_* targets).

[elfmimi]

Anticipated VS2022 Preview came out few days ago. so I tested it.
VS2022 Preview installs: arm-none-eabi-gcc (GNU Arm Embedded Toolchain 9-2020-q2-update) 9.3.1 20200408 (release)
to C:\Program Files\Microsoft Visual Studio\2022\Preview\Linux\gcc_arm\bin
cmake to C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin
nmake to C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.29.30130\bin\Hostx64\x64
and Python to C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64
you can also install "Git for Windows" as part of the install process.
So, you'll get everything you need to build DAPLink in one stop, finally.

from quick test I can say both lpc11u35_if and lpc55s69_if are working fine.
also tried adding records/tools/gcc_arm_lto.yaml to lpc11u35_if in unthinking manner. but this didn't get recognized as a usb device.

[shiva-pandit]

@mbrossard, thanks for adding the gcc support. I was able to test DAPLink on our custom boards using STM32F072CB as the HIC. I posted a PR for adding the support for this new HIC. Please take a look when you get a chance: #789.

[labbott]

The LPC55S69 support is working great for what I need (needed SWO streaming)

[stephendpmurphy]

@mathias-arm Can confirm that the k20dx_bl builds and works great using GCC v10.2.1. Tested using a K64F freedom dev kit. I erased it and reflashed it with the bootloader and then uploaded the k20dx_mimxrt1050_hyper_if project using the DAPLink bootloader 👍

(venv) ☁  build [develop] ⚡  arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[mathias-arm]

Note: This is a response to a earlier version of @stephendpmurphy's where it was not working with GCC v9.2.1, I will leave it as is, because it contains information that might be useful to others.

In my tests I have been using GCC v9.3.1 to compile, and recently I decided to focus only on the 10.3 version and changed CI accordingly. The main reason is the generated binary size being smaller. I have seen that error message being a symptom that the code does not fit (in this case I think 0x8000 is that limit).

You are right, I have not make a focused attempt to test bootloaders some of the reasons for that are:

• I have never encountered a case where the interface is working and the bootloader is not
• Installing bootloaders is generally more complicated than installing bootloaders
• Most people are going to test new interface with old bootloaders
• There are some interesting corner cases: the k20dx_bl now has the interface starting at a different place than it used to. So if I remember correctly k20dx_frdmk64f_if is packaged to be installed on a (so-called "legacy") bootloader that expects firmwares to start at 0x5000, when for k20dx_frdmk66f_if that value would be 0x8000. So if I install the new k20dx_bl on a FRDM-K64F the distributed images won't work.

Long explanation on why I have not done it yet, but I will have to before the release, but I am quite optimistic based on previous tests.

[stephendpmurphy]

No worries. I realized after the fact that I hadn't done ANY of my other testing using v9, but rather v10. I updated my toolset and it works perfectly using v10 👍 (Which is why I removed my comment). I didn't encounter any issues in regards to IF start address this test I suppose because I didn't use the proper project for the K64F... We needed hardware capable of verifying the drag-n-drop functionality from a K20dx to an iMXRT1050 (Which it works great)