Arm none eabi gcc fatal error no input files

DIY Memo: Cross-compile ARM on Windows

Just a quick memo for setting up the toolchains for building ARM firmware on Windows platform.

Software recommendations

First, download and install the following software:

• A source code editor that supports debugging (Atom, Visual Studio Code, Eclipse, etc.)
• MinGW – http://www.mingw.org/
• GNU ARM Toolchain – https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
• J-Link Software and Documentation Pack (can be skipped, see below) – https://www.segger.com/downloads/jlink/
• A make tool (mingw32-make)
• A task runner (optional)

For source code editor, I’ll be using Visual Studio Code like every sane developer in 2018 because it does not require Java installation, has IntelliSense, integrated source control support, task runner and an extension marketplace.

MinGW is the C and C++ compiler for Windows. I’ll write a different memo about getting GCC compiler to run on Windows using Cygwin and Linux Subsystems (Windows 10 only) later on but let’s stick to MinGW for the time being. It does not allow targeting ARM platforms but it does come with all the libraries necessary for C development.

Note:

Those who already have Visual Studio or Code::Blocks installed on their systems are likely to have GCC or Visual C++ installed and will not need MinGW for C development.

GNU ARM Toolchain is the development kit required for targeting ARM platforms. This is a must for the purpose.

J-Link Software and documentation pack come with the J-Link GDB Server and J-Link driver. This is meant for debugging ARM boards with J-Link Debug Probe or boards that support J-Tag debugging. If you have no plan on debugging the code (ergo, just build and deploy sample codes), or if the board you’re using does not support J-Tag debugging and you’re too cheap to pay $300 for the probe, then you’re welcome to skip this software.

MinGW’s basic package also contains a make tool called mingw32-make. It’s functionally the same as Linux’s make tool. This is necessary for the build process since there are a lot of steps involved and I don’t want to run the commands from a Notepad every time.

Finally, since I’m sane enough to use Visual Studio Code, I’ll be using VSCode’s built-in task runner as well. Another popular choice is Gulp.

Tricky installations

The source code editor and GNU ARM Toolchain are, thankfully, quite straightforward. Just run the installer and it will handle everything for you.

Unfortunately, MinGW and J-Link will require a bit more work to set up. Their installation directory will need to be added to Environment Variable path. The paths that need to be added are as follow (assume default installation):

• C:MinGWbin
• C:Program Files (x86)SEGGERJLink_V632c

Follow the guide below and add these two paths to environment variable:

Take note that the second path is version-dependent. If you installed a different J-Link version, please check the installed directory for the correct path. That should take care of J-Link.

But, it’s not done yet for MinGW. The software installed is merely a package manager. To get the actual compiler, launch MinGW Installation Manager. Select “Basic Setup” from the left pane, then tick “mingw32-base” and “mingw32-gcc-g++” (only for C++ development).

The basic MinGW Installation “mingw32-base” contains the C compiler and a built-in make tool as seen in the picture below:

Finally, go to Installation > Apply Changes, and wait for the download and installation to finish. It might run into an error or two as some packages in the mingw32-base bundle are dead. Ignore the errors for now; we can deal with them as they pop up during development.

Testing the installations

Open the console (Run > cmd) and test MinGW’s make tool, GNU ARM toolchain and J-Link GDB server using the commands below (the expected outputs are also showed):

Setting up makefile

In the root directory, create a new file called “makefile” (no extension) and copy paste the following content:

This is the build order and included folders for the sample project delay_intr.c on E-Learning system, which will not be provided here for readers outside of my class.

For these readers:

• Line 4 (SRC variable) is the name of the object file the main source file containing the main() function will be compiled into. In this case, the make tool will know to find delay_intr.c and compile it into delay_intr.o
• Line 15-23 (OBJS variable) is the list of object files that need to be compiled
• Line 25 (VPATH variable) is the list of directories that the make tool will look into for source files.

Running the following commands in cmd at the root directory will activate the “makefile” build and clean task

The build task will generate three files:

• “firmware.elf” is the executable created by the toolchain
• “firmware.hex” is the binary that can be flashed onto the Cortex M4
• “firmware.siz” is the flash size data file necessary for the flashing process

After to this point, a third-party flash tool or debugger independent of IDE can be used.

Those who wish to set up for easy debugging in Visual Studio Code, read on.

Setting up tasks

Launch Visual Studio Code in the directory of your project.

Select View > Command Palette (Ctrl + Shift + P) and type in “Task: Configure Task”

Select “Create a new tasks.json…”, this will create a new .vscode folder and tasks.json file in there.

Copy paste the tasks.json file below:

Setting up J-Link debugger

In Visual Studio Code, go to Extensions (Ctrl + Shift + X) and install “Cortex-Debug” from the marketplace.

Restart the editor so that the installation can take effect.

Go to Debug (Ctrl + Shift + D), Click on the cogwheel icon that says “Configure or Fix launch.json” > Select “Cortex-Debug” from the drop-down menu (or anything, actually). This will create launch.json in the .vscode folder created previously.

Now copy paste the launch.json file below:

Remember to change “device” into whatever ARM chip you’re actually using and the “executable” to whatever executable file you’re using. The J-Link debugger will internally generate the same binary “firmware.hex” and “firmware.size” so you don’t really have to concern yourself with these files for this approach.

Once this is done go back to Debug pane, the drop-down menu next to “Debug” label should now have “Debug (J-Link)” option. Select that and click the green arrow next to it to start the build and debug process via Serial USB.

Please note that switching target source file in “makefile”, it might be necessary to execute clean task manually. Run “mingw32-make clean” in cmd at the root directory to do so.

Источник

Еще один пример установки тулчейна для ARM-ов

Мне в очередной раз потребовалось произвести установку тулчейна для Cortex-ов.

В блоге есть несколько записей об этом процессе. И я, естественно, решил ими воспользоваться. (А для чего я тогда их написал?!). В двух словах — не получилось, ибо с тех пор мир Линукса опять изменился. К счастью, изменился в лучшую сторону.

Результаты установки для Ubuntu и для Debian отличаются. Сюрприз!

Нет-нет, не подумайте на кошмары, всё намного проще. Из-за того, что пространство на Launchpad ограничено, и ребята решили создать репозиторий только для двух LTS-версий Ubunt-ы:

Всё, что вам нужно сделать в Ubunt-е — это выполнить три шага:

1. Добавить частный репозиторий в свой список репозиториев:

2. После чего нужно произвести подновление системы, чтобы она знала, какие пакеты находятся в новом репозитории:

3. И как итог всех трудов — произвести установку тулчейна на комп

Это всё. В принципе, уже можно пользоваться — компилировать свои проги. Но, по большому счету, для полноценного юзания STM32 нужно сделать еще кое-какие действия. Но об этом после короткого рассказа от том, тулчейн ставится в Debian.

Хочу заострить внимание вот на каком моменте. Поскольку тулчейн находится в списке отслеживаемых репозиториев, то каждый раз выполняя команды

Вы подновляете систему с учетом и этого репозитория.

Авторы тулчейна напоминают, что если по каким-то причинам вы захотите отказаться от этого тулчена, то вам нужно выполнить команду:

В прочем, это и так очевидно. Ну, вот, пожалуй, это всё, что касается Ubuntu.

Установка тулчейна в Debian происходит иначе. В Debian-е нужно зайти на страницу

и найти с правой стороны сжатый файл архива для Linux:

Это четвертая кнопка сверху. В прочем, при задержке курсора на кнопке выскакивает подсказка — не ошибётесь!

Поскольку это обычный файл, то можно его скачать себе на комп даже не заходя в браузер. Наберите (точнее — закопипастите отсюда) в консоли команду для его закачки:

После того как файл так или иначе оказался у вас, нужно его разжать и разархивировать. Сделаем это одной командой:

Таким образом, рядом с файлом сжатого архива должен появиться директорий. Наша задача —скопировать директорий на место его постоянной дислокации. Поскольку, в большинстве случаев это место принадлежит root-у, то выполнять копирование нужно из-под рута.

Не особо утруждаясь в обдумывании, куда бы его пристроить, я скопировал его в директорий /opt/arm/.

В принципе, вместо копирования (команда cp) лучше использовать команду переименования/переноса (команда mv).

Ну вот, нам осталось только прописать пути к его исполняемым файлам. Разумеется, делать это надо не в учетной записи root-а, а в домашнем директории пользователя. Вы ведь не собираетесь писать программы и компилировать их из-под root-а?! В общем, переходим в свою учетную запись и там продолжаем. Находясь в своем домашнем директории я добавил в файл

/.profile следующую сторку:

На данный момент мы всего лишь поменяли конфигурационый файл. Но чтобы изменения в нем вступили в силу нужно либо выйти и снова зайти (как в Виндовсе), либо выполнить следующую команду (как это делают настоящие профи):

На данный момент нити установки тулчейна для Ubutntu и для Debian сошлись, и дальнейшие действия относятся и к тому, и к другому дистрибутиву.

Чтобы проверить, что компиляторы установлены и доступны для работы, давайте выполним парочку познавательных команд.

помимо прочей информации выведет список процессоров (ядер), которые известны компилятору. Эти наименования можно использовать при компиляции в опциях -mcpu и -mtune.

покажет какие библиотеки (модули) используются для расчетов с плавающей арифметикой.

Если вы, находясь в домашнем директории, может видеть адекватную реакцию кросс-компилятора, то можно считать, что он нормально установился в систему, и чтобы начать уже компилировать программы для конкретного процессора, нужно только дописать хэдерные и библиотечные файлы.

Кто-то переносит систему этих файлов в рабочий директорий (где ведется разработка проекта), кто-то прописывает их рядом со стандартными файлами компилятора. В первом случае, ваши проекты будут обладать автономностью и независимостью от других проектов, но при этом они будут иметь огромные размеры. Во втором случае, в проектах ничего не будет кроме ваших авторских файлов. В общем, кому как нравится. Я пока что еще не пришел к ни к тому, ни к другому.

Поэтому я создал поддиректорий

и тупо в него скопировал два файла core_cm3.h и core_cm3.c из поддиректория cmsis, а так же все содержимое поддиректория stm32_lib.

Вполне возможно, что так делать не надо, но я пока еще не столкнулся с трудностями компиляции на мелких (тестовых) проектах.

Следующий вопрос, который мне пришлось так же рассмотреть, — установка программного обеспечения для программатора. Я его вынес в отдельную тему. Там тоже произошли изменения.

Понравилось это:

Похожее

5 responses to “ Еще один пример установки тулчейна для ARM-ов ”

Ошибка в статье! tar jxf не работает. Просто в простое висит и ничего не делает. Правильно будет вот так: tar xvf

Давайте не спеша разберёмся.

Во первых, нужно чётко понимать различие понятий архивации и сжатия, которые приняты в Линуксе и в Виндовсе.

Виндовс под архивацией подразумевает объединение в единый файл указанных файлов и директориев с одновременным уменьшением общего объема.

Исторически так сложилось, что Линукс изначально разделял процесс архивации и процесс компрессии. В Линуксе под процессом архивации подразумевается объединение в единый файл указанных файлов и директориев. В отличие от Виндовса уменьшение объёма не производится. А вот понятие «сжатие» в Линуксе подразумевает как раз уменьшение занимаемого объема.

Условно можно сказать, что Виндовс смотрит на процесс архивации как на процесс в одно действие, в то время как Линукс процесс архивации раскладывает на два: сначала объединение указанных файлов/директориев, а потом сжатие.

Таким образом, понятие «архивация» в Виндовсе и в Линуксе различаются.

Обратный процесс — разархивация», условно говоря, в Линуксе также подразумевает два действия: сначала восстановление объема, а потом «вынимание» из общей кучи файлов и директориев.

Я ещё раз подчеркну — это всё условно! Архиваторы в Виндовсе и в Линуксе внешне работают одинаково (похоже друг на друга). Все дествия по архивации и там, и там производятся за один раз. При желании и там, и там можно действия сжатия и действия объединения выполнять по отдельности.

Далее рассмотрим, что даёт тот или иной символ (буква), указанные в ключе при вызове архиватора.

x — символ говорит архиватору о том, что указанный далее файл нужно разжать (декомпрессировать). Противоположность этому действию — является действие сжатия указанных файлов и директориев. Действие сжатия выполняется по команде, символ которой «с». Поскольку команды сжатия и декомпрессии противоположны, то использовать символы «x» и «c» в одной команде нельзя.

j — этот символ указывает на то, что в работе используется архиватор (точнее — метод сжатия) bzip2, а не zip, gzip и так далее.

v — этот символ заставляет архиватор «болтать». В основе философии (поведения) Линукса лежит принцип — если ты дал команду, то она должна быть выполнена. Если команда выполняется успешно, что какой смысл об этом сообщать, тем самым «зашумлять» экран? Конечно, когда при выполнении возникают проблемы, тогда — естественно — необходимо сообщать об этом пользователю. А если всё успешно — то зачем.

Но иногда в жизни возникают ситуации, особенно когда «мёртвый» безсловестный экран воспринимается как ничего не делающая программа. Это как раз тот самый случай, с которым Вы, уважаемый Петя, столкнулись. Разархивация 60-мегабайтного файла довольно-таки длительный процесс. На моём стареньком компе она выполняется примерно полминуты. В течении этого времени на экране ничего не происходит, и создаётся впечатление, что архиватор ничего не делает.

Чтобы изменить такой режим работы архиватора и сделать его «болтливым», используется ключ «v». За болтливость нужно платить, время работы «болтливого» разархиватора примерно на 10% больше, чем время работы «молчаливого» разархиватора.

f — этот ключ говорит о том, что следующей конструкцией в командной строке будет имя архивного файла. Этот ключ должен быть последним в «связке» ключиков.

Следует заметить, что указание ключа «j» не столь обязательно при разархивации. Если его не указать, то архиватор и сам догадается, что используется архивный файл, сжатый по алгоритму bzip2. А вот для процесса архивации ключик «j» принципиален. Если его не указать, то процесс сжатия будет иной.

Подводя итог можно сказать, что оба набора ключей и «jxf», и «xvf» в нашем случае извлечения файлов из архива — принципиально работают. Причём работают с одинаковым результатом, хотя внешнее поведение архиватора несколько различается.

Не следует посыпать пеплом голову и уходить в кусты. Все мы когда-то мало чего знали и плохо разбирались в устройстве этого мира.

Не важно, где ты находишься сейчас, важно куда ты идёшь. (с) — Я не помню откуда эта фраза. Не важно, что ты сейчас плохо разбираешься в некоторых моментах, важно — есть у тебя желание учиться.

Команда arm-none-eabi-gcc —print-multy-lib не работает.
Вот что выводится:
[ admin$:

] arm-none-eabi-gcc —print-multy-lib
arm-none-eabi-gcc: error: unrecognized command line option ‘—print-multy-lib’
arm-none-eabi-gcc: fatal error: no input files
compilation terminated.

Спасибо за обратную связь!

Я неправильно написал слово «multi» и не заметил.

Складывая наши усилия мы делаем мир лучше. Но если мы направляем свои усилия друг против друга, мы только разрушаем наш общий мир.

Правильно будет arm-none-eabi-gcc -print-multi-lib. Эх, ну исправьте уже ошибки в статье!

Источник

After trying and trying and spending more than double the original price I finally got hold of a couple of STM32F3Discovery (Dev) Boards.

These Boards pack a bit too much power from the perspective of a hobbyist like me who has used only 8-bit stuff till now and though I don’t have any specific plans for using the extra processing power, I wanted these boards cause of the 9-Axis IMU that comes on it all ready to be used.

To avoid repetition of explaining the board and what it has and what not, am just going to put in a  couple of links.

A few links which introduce the board better:

• STM32F3Discovery Board Product Page
• STM32 F3 and F4 Boards Comparison

I found out after getting the board that ST does not provide ready support for free-tools and the official supported IDEs/Debuggers are expensive and out of range for hobby work,  so I set out to find open-source and free solutions. I found quite a few but most were either Linux based or targeted some other STM32 Board and not this specific one. I have gathered bits from here and there and in this post will try to provide short and clear pathway to be able to build and burn projects for the STM32F3Discovery Board.

First Steps

Checking if the board works or not, these come with a pre-flashed firmware which demos the use of the IMU and the on-board LEDs, plug the USB port in the USB-ST-Link Port and see if it works, pressing the user button advances the demo. You may need to install the driver for the on-board ST-Link. Windows 8 has an additional step to restart in Device Signature Enforcement Disabled [Win8 Advanced Startup steps, for Arduino but same process].

Download and install the STM32 ST-Link Utility [and driver if needed] from ST site: http://www.st.com/internet/evalboard/product/251168.jsp

Run the STM32 ST-Link utility and click on the Connect to Target Icon (3rd from the left)  or click Connect in the Target menu and see if it detects the board and connects to it if NOT, there is some problem somewhere.

Installing the GCC ARM Toolchain and GNU make

After verifying that the board is working and is detectable, the next step is to download and install the GCC ARM Toolchain, which is basically C/C++ compiler suited for the ARM processors.

Download Link: GNU Tools for ARM Embedded Processors

The installation is simple as it can be, just REMEMBER to check the 3rd checkbox at the final install screen, “add path to environment variable“, this is a very essential step.

Test to see if GCC ARM Toolchain is installed

Open Command Prompt and type in:

arm-none-eabi-gcc

If it says Fatal error, then you are doing GOOD and the installation was successful  else you probably forgot to check the 3rd checkbox or you need to restart your PC.

arm-none-eabi-gcc  [ENTER]

RESULT
arm-none-eabi-gcc: fatal error: no input files
 compilation terminated.

Once that is done, now you need the GNU make binaries and dependencies, these may already be installed in your system if you have worked with AVR (have AVR Toolchain installed).  Enter make in command prompt, it should say

make  [ENTER]

RESULT
make: *** No targets specified and no makefile found. Stop.

If this is not the case and you get the error not recognized command, then follow these steps

We will need gnu make to be able to run makefiles. Makefiles are scripts that allow us to invoke the gcc compiler efficiently. It is very handy for building multiple source projects.

Download the “GNU make for windows”  binaries and the dependencies zip files from http://gnuwin32.sourceforge.net/packages/make.htm.

We unzip them and locate the “make.exe” file from the binaries zip file; which should be in the bin directory of that zip file, and the “libiconv2.dll” and “libintl3.dll” files from the dependencies zip file which you will also find under the bin directory in that zipped file. Once you locate “make.exe”, “libiconv2.dll” and “libintl3.dll”, copy them into the same directory containing the compiler binaries.

Which should be look something like: “C:Program Files (x86)GNU Tools ARM Embedded4.6 2012q2bin”  This way the make command can also be invoked from anywhere on your C drive.

—– steps directly copied from http://hertaville.com/2012/05/28/gcc-arm-toolchain-stm32f0discovery/

More NEXT TIME

Now that we have ARM GCC, GNU make and the STM32 ST-Link Utility installed, the foundations have been laid and the last remaining task is to setup a workspace/development folder and start coding from a template project which has the relevant bare-bones source files and the MakeFile.

I am working on the template project and until I do, I will write-up the remainder of the procedure in the second part.

Reference Pages [from where I copied MOST things]:

I am not very good with these MakeFiles etc and all that I am doing is simply copy-paste and changing a few settings here and a couple things there and all of the above and the rest coming is a summary from these and other pages found via Google.

• http://hertaville.com/the-stm32f0discovery-board/
  
• http://thehackerworkshop.com/?p=391
• http://pulkomandy.tk/_/_Electronique/_Discovering%20the%20STM32F3%20Discovery
• http://engineering-diy.blogspot.com/2012/11/stm32f3-discovery-eclipse-openocd.html

Even though MATLAB has permissions to write to the folder mentioned in the error message, the setup may fail due to the second error in that message. The second error message indicates that the arm-none-eaby-gcc.exe compiler received no input files for compilation.

During the setup stage —

1) Certain .C files are supposed to get compiled into corresponding .O files. eg. Compiling the source file “fsl_os_abstraction_bm.c» into «fsl_os_abstraction_bm.o» file.

2) Linking to .o files to build a library file called «libksdk_platform.a» in the bm folder and «libksdk_platform_freertos.a» in the freertos folder.

Note: the folders bm and freertos refer to:

C:ProgramDataMATLABSupportPackagesR2016btoolboxtargetsupportpackagesfreedomk64fsrcksdk_armgcc_libbm

C:ProgramDataMATLABSupportPackagesR2016btoolboxtargetsupportpackagesfreedomk64fsrcksdk_armgcc_libfreertos

However, for some reason either one or both of these steps are failing during the setup stage. The exact cause of this is not known since the issue is not reproducible. However to work around the problem, you can copy over the .o files and the .a files compiled from another computer where the setup works.

If it is not an option to copy over files from a different computer, you can also add the following line to the makefiles at the bm and freertos paths specified above, ensuring that it is the correct path to the Command Prompt:

SHELL=C:/Windows/System32/cmd.exe

Once you add the above line to both makefiles and save them, you should be able to complete the setup process.

Just a quick memo for setting up the toolchains for building ARM firmware on Windows platform.

Software recommendations

First, download and install the following software:

• A source code editor that supports debugging (Atom, Visual Studio Code, Eclipse, etc.)
• MinGW – http://www.mingw.org/
• GNU ARM Toolchain – https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
• J-Link Software and Documentation Pack (can be skipped, see below) – https://www.segger.com/downloads/jlink/
• A make tool (mingw32-make)
• A task runner (optional)

For source code editor, I’ll be using Visual Studio Code like every sane developer in 2018 because it does not require Java installation, has IntelliSense, integrated source control support, task runner and an extension marketplace.

MinGW is the C and C++ compiler for Windows. I’ll write a different memo about getting GCC compiler to run on Windows using Cygwin and Linux Subsystems (Windows 10 only) later on but let’s stick to MinGW for the time being. It does not allow targeting ARM platforms but it does come with all the libraries necessary for C development.

Note:

Those who already have Visual Studio or Code::Blocks installed on their systems are likely to have GCC or Visual C++ installed and will not need MinGW for C development.

GNU ARM Toolchain is the development kit required for targeting ARM platforms. This is a must for the purpose.

J-Link Software and documentation pack come with the J-Link GDB Server and J-Link driver. This is meant for debugging ARM boards with J-Link Debug Probe or boards that support J-Tag debugging. If you have no plan on debugging the code (ergo, just build and deploy sample codes), or if the board you’re using does not support J-Tag debugging and you’re too cheap to pay $300 for the probe, then you’re welcome to skip this software.

MinGW’s basic package also contains a make tool called mingw32-make. It’s functionally the same as Linux’s make tool. This is necessary for the build process since there are a lot of steps involved and I don’t want to run the commands from a Notepad every time.

Finally, since I’m sane enough to use Visual Studio Code, I’ll be using VSCode’s built-in task runner as well. Another popular choice is Gulp.

Tricky installations

The source code editor and GNU ARM Toolchain are, thankfully, quite straightforward. Just run the installer and it will handle everything for you.

Unfortunately, MinGW and J-Link will require a bit more work to set up. Their installation directory will need to be added to Environment Variable path. The paths that need to be added are as follow (assume default installation):

• C:MinGWbin
• C:Program Files (x86)SEGGERJLink_V632c

Follow the guide below and add these two paths to environment variable:

https://www.computerhope.com/issues/ch000549.htm

Take note that the second path is version-dependent. If you installed a different J-Link version, please check the installed directory for the correct path. That should take care of J-Link.

But, it’s not done yet for MinGW. The software installed is merely a package manager. To get the actual compiler, launch MinGW Installation Manager. Select “Basic Setup” from the left pane, then tick “mingw32-base” and “mingw32-gcc-g++” (only for C++ development).

The basic MinGW Installation “mingw32-base” contains the C compiler and a built-in make tool as seen in the picture below:

Finally, go to Installation > Apply Changes, and wait for the download and installation to finish. It might run into an error or two as some packages in the mingw32-base bundle are dead. Ignore the errors for now; we can deal with them as they pop up during development.

Testing the installations

Open the console (Run > cmd) and test MinGW’s make tool, GNU ARM toolchain and J-Link GDB server using the commands below (the expected outputs are also showed):

Microsoft Windows [Version 10.0.16299.431]
(c) 2017 Microsoft Corporation. All rights reserved.

D:DocumentsMicrocontroller>mingw32-make
mingw32-make: *** No targets specified and no makefile found. Stop.

D:DocumentsMicrocontroller>arm-none-eabi-gcc
arm-none-eabi-gcc: fatal error: no input files
compilation terminated.

D:DocumentsMicrocontroller>arm-none-eabi-gdb
GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128-git
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
---Type  to continue, or q  to quit---quit
Quit

D:DocumentsMicrocontroller>jlinkgdbserver

D:DocumentsMicrocontroller>

Setting up makefile

In the root directory, create a new file called “makefile” (no extension) and copy paste the following content:

################################
# Environment settings
################################

SRC = delay_intr.o
LINK_TARGET = firmware.elf
MAP_TARGET = firmware.map
SIZ_TARGET = firmware.siz
HEX_TARGET = firmware.hex

SECONDARY_TARGETS = $(MAP_TARGET) 
	$(SIZ_TARGET) 
	$(HEX_TARGET) 

OBJS = startup_s6e2cc.o 
	system_s6e2cc.o 
	delay.o 
	gpio.o 
	i2c.o 
	i2s.o 
	dstc.o 
	audio.o 
	$(SRC) 

VPATH = src include system/include/S6E2CCA

LIBS = -l"arm_cortexM4lf_math"

LINKER = arm-none-eabi-g++ 

COMPILER = arm-none-eabi-gcc 

ASSEMBLER = arm-none-eabi-gcc 

OUTPUT_OPTIONS = -mcpu=cortex-m4 
		-mthumb 
		-mthumb-interwork 
		-mfloat-abi=hard 
		-mfpu=fpv4-sp-d16 
		-munaligned-access 
		-O0 
		-fmessage-length=0 
		-fsigned-char 
		-ffunction-sections 
		-fdata-sections 
		-ffreestanding 
		-fno-move-loop-invariants  
		-g3 

LINKER_OPTIONS = -T"./ldscripts/s6e2cc_ram.ld" 
	-nostartfiles 
	-Xlinker 
	--gc-sections 
	-L"./libs" 
	-Wl,-Map,"$(MAP_TARGET)"  
	-Xlinker 
	--cref 
	-lm 

COMPILER_OPTIONS = -DDEBUG 
	-DTRACE 
	-D__FPU_PRESENT 
	-DARM_MATH_CM4 
	-I"./include" 
	-I"./system/include" 
	-I"./system/include/cmsis" 
	-I"./system/include/S6E2CCA" 
	-std=gnu11 
	-Wmissing-prototypes 
	-Wstrict-prototypes 
	-Wbad-function-cast 

ASSEMBLER_OPTIONS = -x 
	assembler-with-cpp 
	-DDEBUG 
	-DTRACE 
	-I"./include" 
	-I"./system/include" 
	-I"./system/include/cmsis" 
	-I"./system/include/S6E2CCA" 
	-MMD 
	-MP 
	-MT"$(@)" 

################################
# Make functions
################################

.PHONY : all
all: $(LINK_TARGET) $(SECONDARY_TARGETS)

$(LINK_TARGET): $(OBJS)
	@echo Build target: $@
	@echo 'Invoking: Cross ARM C++ Linker'
	$(LINKER)$(OUTPUT_OPTIONS)$(LINKER_OPTIONS) -o $@ $^ $(LIBS)
	@echo 'Finished building target: $@'
	@echo.

%.o : %.c
	@echo 'Building file: $<'
	@echo 'Invoking: Cross ARM C Compiler'
	$(COMPILER)$(OUTPUT_OPTIONS)$(COMPILER_OPTIONS) -c -o "$@" "$<"
	@echo 'Finished building: $<'
	@echo.

%.o : %.S
	@echo 'Building file: $<'
	@echo 'Invoking: Cross ARM GNU Assembler'
	$(ASSEMBLER)$(OUTPUT_OPTIONS)$(COMPILER_OPTIONS) -c -o "$@" "$<"
	@echo 'Finished building: $<'
	@echo.

%.hex : %.elf
	@echo 'Invoking: Cross ARM GNU Create Flash Image'
	arm-none-eabi-objcopy -O ihex "$<"  "$@"
	@echo 'Finished building: $@'
	@echo.

%.siz : %.elf
	@echo 'Invoking: Cross ARM GNU Print Size'
	arm-none-eabi-size --format=berkeley "$<"
	@echo 'Finished building: $@'
	@echo.

.PHONY: clean
clean:
	del -f $(OBJS) $(LINK_TARGET) $(SECONDARY_TARGETS)
	@echo Clean completed
	@echo.

This is the build order and included folders for the sample project delay_intr.c on E-Learning system, which will not be provided here for readers outside of my class.

For these readers:

• Line 4 (SRC variable) is the name of the object file the main source file containing the main() function will be compiled into. In this case, the make tool will know to find delay_intr.c and compile it into delay_intr.o
• Line 15-23 (OBJS variable) is the list of object files that need to be compiled
• Line 25 (VPATH variable) is the list of directories that the make tool will look into for source files.

Running the following commands in cmd at the root directory will activate the “makefile” build and clean task

mingw32-make

mingw32-make clean

The build task will generate three files:

• “firmware.elf” is the executable created by the toolchain
• “firmware.hex” is the binary that can be flashed onto the Cortex M4
• “firmware.siz” is the flash size data file necessary for the flashing process

After to this point, a third-party flash tool or debugger independent of IDE can be used.

Those who wish to set up for easy debugging in Visual Studio Code, read on.

Setting up tasks

Launch Visual Studio Code in the directory of your project.

Select View > Command Palette (Ctrl + Shift + P) and type in “Task: Configure Task”

Select “Create a new tasks.json…”, this will create a new .vscode folder and tasks.json file in there.

Copy paste the tasks.json file below:

{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "build",
"type": "shell",
"command": "mingw32-make",
"args": [],
"group": {
"kind": "build",
"isDefault": true
}
}
]
}

Setting up J-Link debugger

In Visual Studio Code, go to Extensions (Ctrl + Shift + X) and install “Cortex-Debug” from the marketplace.

Restart the editor so that the installation can take effect.

Go to Debug (Ctrl + Shift + D), Click on the cogwheel icon that says “Configure or Fix launch.json” > Select “Cortex-Debug” from the drop-down menu (or anything, actually). This will create launch.json in the .vscode folder created previously.

Now copy paste the launch.json file below:

{
"version": "0.2.0",
"configurations": [
{
"type": "cortex-debug",
"request": "launch",
"servertype": "jlink",
"cwd": "${workspaceRoot}",
"executable": "./firmware.elf",
"name": "Debug (J-Link)",
"device": "S6E2CCAJ0A",
"interface": "jtag",
"ipAddress": null,
"serialNumber": null,
"preLaunchTask": "build"
}
]
}

Remember to change “device” into whatever ARM chip you’re actually using and the “executable” to whatever executable file you’re using. The J-Link debugger will internally generate the same binary “firmware.hex” and “firmware.size” so you don’t really have to concern yourself with these files for this approach.

Once this is done go back to Debug pane, the drop-down menu next to “Debug” label should now have “Debug (J-Link)” option. Select that and click the green arrow next to it to start the build and debug process via Serial USB.

Please note that switching target source file in “makefile”, it might be necessary to execute clean task manually. Run “mingw32-make clean” in cmd at the root directory to do so.