De­vel­op­ing ARM Tar­gets Us­ing GNU MCU Eclipse

If you are think­ing of kick­start­ing the de­vel­op­ment of mi­cro­con­troller tar­gets, but don’t have suit­able hard­ware, or if you are wor­ry­ing about hard­ware is­sues, here is the per­fect so­lu­tion for you. The GNU MCU Eclipse project comes with great fea­tures to

OpenSource For You - - Contents -

The GNU MCU Eclipse project, for­merly known as GNU ARM Eclipse, of­fers a va­ri­ety of plu­g­ins and com­po­nents for the de­vel­op­ment of ARM tar­gets for the Cor­tex-M se­ries ar­chi­tec­ture. In this ar­ti­cle, we’ll dis­cuss var­i­ous com­po­nents of­fered un­der this project, the sup­ported fea­tures, and the in­stal­la­tion and us­age of each. We’ll fol­low that up by build­ing a sim­ple project and em­u­lat­ing the Blinky code un­der the Qemu en­vi­ron­ment.

This project of­fers the fol­low­ing com­po­nents for ARM de­vel­op­ment:

MCU plu­g­ins to gen­er­ate tem­plate code, as well as to build, flash and de­bug.

Qemu, to em­u­late the gen­er­ated out­come with­out the need of ac­tual hard­ware, with good sup­port for pop­u­lar STM32 se­ries tar­gets.

OpenOCD, to flash and de­bug code through JTAG probes and de­bug­ging hard­ware.

Win­dows Build Tools, for the Linux-like make util­ity and ba­sic com­mands like rm and echo used in make­files.

Packs man­ager, to in­stall Keil/ARM CMSIS packs (in an ex­per­i­men­tal state, at present).

But the toolchain is not hosted un­der this project, and these plu­g­ins work well with stan­dard toolchains de­signed for sup­ported ar­chi­tec­ture. Let’s now take a tour of these com­po­nents, their in­stal­la­tion and us­age.

Toolchain

You need a toolchain to build the code for the tar­get ar­chi­tec­ture. For this, down­load the pre­built bi­na­ries of

GNU ARM Em­bed­ded Toolchain from de­vel­oper.arm. com/open-source/gnu-toolchain/gnu-rm ac­cord­ing to the host en­vi­ron­ment, i.e., Win­dows, Linux or Mac OS. This toolchain has a typ­i­cal cy­cle of quar­terly re­leases, and the lat­est re­lease is 6-2017-q2-up­date which ships with GCC 6. From 6-2016-q4-ma­jor on­wards, pre­built bi­na­ries for 32-bit Linux have been dropped and only sup­port for 64-bit Linux is avail­able. How­ever, one can build the toolchain from avail­able sources for any host ar­chi­tec­ture. Re­leases up to v5-2016-q3 are also avail­able at launch­pad.net/gcc-armem­bed­ded, with bi­nary sup­port for 32-bit Linux only, and through PPA for Ubuntu dis­tri­bu­tions.

This toolchain pro­vides var­i­ous tools for de­vel­op­ment and the anatomy of gen­er­ated files with the pre­fix ‘arm-nonee­abi-‘. A few sig­nif­i­cant tools are: arm-none-eabi-gcc, which is a wrap­per for var­i­ous phases of C de­vel­op­ment

arm-none-eabi-g++, a wrap­per for var­i­ous phases of C++ de­vel­op­ment arm-none-eabi-ld, which links sev­eral ob­ject files and li­braries, gen­er­at­ing an ex­e­cutable with the help of linker maps and startup code arm-none-eabi-as, for as­sem­bling code and to gen­er­ate ob­ject files arm-none-eabi-cpp, for pre­pro­cess­ing source code arm-none-eabi-ob­j­copy, to con­vert an ex­e­cutable file from elf for­mat into bin or hex for­mat arm-none-eabi-nm, to check the sym­bol ta­ble arm-none-eabi-ob­j­dump, which is to dis­as­sem­ble gen­er­ated ob­ject files and sec­tion anal­y­sis arm-none-eabi-read­elf, for read­ing the head­ers based on the magic num­ber present arm-none-eabi-size, to check the sec­tion wise foot­print of the gen­er­ated ex­e­cutable file arm-none-eabi-gdb, for de­bug­ging and trac­ing with the help of de­bug­ging hard­ware

OpenOCD

This on-chip de­bug­ger util­ity comes with flash­ing and re­mote de­bug­ging sup­port for var­i­ous tar­get boards. It works with dif­fer­ent JTAG probes con­nected to the host with on­board or ex­ter­nal hard­ware de­bug­gers. GNU MCU Eclipse OpenOCD is a fork of the orig­i­nal OpenOCD and it is de­signed to work well with MCU plu­g­ins. Pre­built bi­na­ries are avail­able at gnu-mcu-eclipse.github.io/openocd/re­leases for var­i­ous host en­vi­ron­ments.

Qemu

Qemu, in­for­mally known as ‘Quick emu­la­tor’, can ex­e­cute ap­pli­ca­tions built for var­i­ous tar­get ar­chi­tec­tures and can em­u­late full sys­tem im­ages also. Main­line Qemu has limited sup­port for bare metal tar­gets (a few of the TI Stel­laris fam­ily only) based on the Cor­tex-M ar­chi­tec­ture.

GNU MCU Eclipse Qemu is a fork of the orig­i­nal Qemu and comes with sup­port for var­i­ous pop­u­lar tar­gets of the STM32 Dis­cov­ery and Nu­cleo se­ries. Sup­port for more tar­gets like NXP/Freescale Free­dom Kinetis se­ries, NXP LPC se­ries, TI Tiva se­ries, At­mel SAM se­ries and In­fi­neon CPU Card/Board se­ries is in the pipeline for fu­ture re­leases. Please stay tuned to gnu-mcu-eclipse.github.io/qemu/ for more up­dates.

Down­load the lat­est sta­ble ver­sion of Qemu bi­na­ries from github.com/gnu-mcu-eclipse/qemu/re­leases, ex­tract to a suit­able lo­ca­tion and up­date the path to the bin di­rec­tory.

IDE with plu­g­ins

Down­load the lat­est sta­ble ver­sion of GNU MCU Eclipse IDE for C/C++ devel­op­ers from github.com/gnu-mcu-eclipse/org. eclipse.epp.pack­ages/re­leases. These ar­chives are al­ready bun­dled with CDT and MCU plu­g­ins. The first ma­jor re­lease (which is the lat­est one, as of now) is based on the Neon 3 re­lease of Eclipse IDE and v4.1.1 of MCU plu­g­ins.

Al­ter­na­tively, you can down­load the reg­u­lar Eclipse IDE for C/C++ devel­op­ers us­ing the Eclipse in­staller or through off­line ar­chive op­tions, and up­date the MCU plu­g­ins via Eclipse Mar­ket Place. For this, nav­i­gate to Help --> Eclipse Mar­ket Place, search for GNU MCU Eclipse and in­stall the plu­g­ins.

These plu­g­ins are avail­able at https://gnu-mcu-eclipse. netlify.com/v4-neon-up­dates, which can be spec­i­fied for man­ual in­stal­la­tion by nav­i­gat­ing to Help --> In­stall New Soft­ware and adding a new repos­i­tory with the above URL. This repos­i­tory su­per­sedes the ear­lier plu­g­ins of v3.x hosted at http://gnuarme­clipse.source­forge.net/up­dates.

The plu­g­ins come with sup­port for var­i­ous tar­gets from the STM32 se­ries, the NXP/Freescale Kinetis se­ries of boards and are ca­pa­ble of the fol­low­ing:

Gen­er­at­ing tem­plate projects

Build­ing the code with the help of a cross toolchain Flash­ing and de­bug­ging code us­ing OpenOCD, J-Link or CodeRed modes

Em­u­lat­ing us­ing Qemu in the ab­sence of hard­ware

To map the nec­es­sary com­po­nents with the in­stalled plu­g­ins, go to Win­dows --> Pref­er­ences --> MCU and fill the suit­able lo­ca­tions of Toolchain, OpenOCD, Qemu, etc, to en­able project wizards to make use of the tools avail­able in these di­rec­to­ries.

Note: Ac­tual com­po­nents like Toolchain, OpenOCD and Qemu need to be in­stalled in­di­vid­u­ally, as men­tioned in ear­lier sec­tions. This plugin set just sup­ports the above com­po­nents in a friendly mode.

Project tem­plates

The in­stalled plu­g­ins (pre­bun­dled or man­u­ally in­stalled via Mar­ket Place) en­able project wizards for the STM32 Fxxx se­ries, Freescale Kinetis KLxx se­ries, Ana­log De­vices’ ADuCM36X fam­ily of boards and a tem­plate for the generic Cor­tex-M se­ries tar­get. These wizards help us to cre­ate empty projects or Blinky tem­plates with ven­dor-spe­cific ab­strac­tion APIs and tar­get-spe­cific op­tions un­der Project set­tings.

Blinky demo

Let’s try a Blinky demo for the STM32 F4 Dis­cov­ery tar­get. This board is equipped with four user LEDs, one user push­but­ton, an on­board ac­celerom­e­ter, USB

OTG con­nec­tor, an au­dio in­ter­face and pin out for other in­ter­faces. OpenOCD works well with the on­board ST-Link hard­ware for de­bug­ging pur­poses. Cre­ate a new C project us­ing File --> New --> C Project. Next, choose STM32F4xx C/C++ project as Type and give it a suit­able name, say f4-blinky, as shown in Fig­ure 1.

In the next wizard, choose the de­sired MCU chip ac­cord­ing to the tar­get board and con­fig­ure other

pa­ram­e­ters like Flash mem­ory size, clock speed, etc. Choose the Blinky tem­plate un­der Con­tent type, and leave other op­tions with de­fault val­ues for the ini­tial work as shown in Fig­ure 2. Fol­low de­fault val­ues for Folder set­tings and se­lect con­fig­u­ra­tions in the next two wizards. In the fi­nal wizard, pro­vide the path of the bin di­rec­tory un­der the ex­tracted toolchain and hit Fin­ish to com­plete the set-up process.

Right-click on the gen­er­ated project, i.e., f4-blinky un­der the Project Ex­plorer pane, and then click on Build Project. On suc­cess­fully com­plet­ing the build, you can see the fol­low­ing con­sole out­put:

Fin­ished build­ing tar­get: f4-blinky.elf

In­vok­ing: GNU ARM Cross Cre­ate Flash Im­age arm-none-eabi-ob­j­copy -O ihex “f4-blinky.elf” “f4-blinky. hex” Fin­ished build­ing: f4-blinky.hex

In­vok­ing: GNU ARM Cross Print Size arm-none-eabi-size --for­mat=berke­ley “f4-blinky.elf” text data bss dec hex file­name 8599 160 420 9179 23db f4-blinky.elf Fin­ished build­ing: f4-blinky.siz

Project set­tings

Once the project is gen­er­ated, you can tune var­i­ous op­tions for the pre­proces­sor, C/C++ com­piler, linker, etc. For this, right-click on the project, and go to Prop­er­ties --> C/C++ Build --> Set­tings.

Un­der the Tool Set­tings tab, you can choose var­i­ous op­tions like Tar­get, Assem­bler, Com­piler, Linker, Flash, etc. Plu­g­ins will gen­er­ate suit­able op­tions of the toolchain for each se­lec­tion. For ex­am­ple, if you want to gen­er­ate a Flash im­age in Raw Bi­nary for­mat in­stead of Intel HEX, choose the out­put file for­mat un­der GNU ARM Cross Cre­ate Flash Im­age --> Out­put File For­mat. Like­wise, you can play around with var­i­ous op­tions un­der this tab view and check the se­lected val­ues un­der ‘All Op­tions’ ex­pected for var­i­ous tools in CLI mode. This way you can also learn about the var­i­ous op­tions to be used with a toolchain in sim­ple in­ter­ac­tive steps.

Flash­ing the code – Run/De­bug

Once project set­tings are cus­tomised, re­build the project. Right click the project and nav­i­gate to De­bug --> De­bug As --> De­bug Con­fig­u­ra­tions. Dou­ble-click on GDB

QEMU De­bug­ging to gen­er­ate a new con­fig­u­ra­tion (for the first time only). Un­der the De­bug­ger tab, fill in the

Board name as STM32F4-Dis­cov­ery and De­vice name as STM32F407VG, as shown in Fig­ure 4. You can try this with other board names as listed by qemu-sys­tem-gnuarme­clipse -M ? and other de­vice (MCU cores) names as listed by qemu-sys­tem-gnuarme­clipse -mcu ?

Now, launch the GDB ses­sion by hit­ting the De­bug op­tion. The Eclipse per­spec­tive will be changed to de­bug mode and you can try var­i­ous de­bug op­tions like sus­pend, re­sume, ter­mi­nate, step into, step over, step re­turn, etc.

Also, you can watch the state of vari­ables, break­points and reg­is­ters. You can also watch pe­riph­eral reg­is­ters if the packs plugin and tar­get-spe­cific packs are in­stalled.

Sim­i­larly, if you are flash­ing the code on a real tar­get, cre­ate an OpenOCD con­fig­u­ra­tion and fill in the con­fig op­tions as -f board/stm32f4dis­cov­ery.cfg un­der the De­bug­ger tab, and launch an OpenOCD ses­sion. You may re­name the gen­er­ated con­fig­u­ra­tion in a con­ve­nient way. You can spec­ify a suit­able OpenOCD script name for other tar­gets un­der the con­fig op­tions.

Once the de­bug ses­sion is launched, you will ob­serve that the se­lected LED is blink­ing for a given time in­ter­val on the real tar­get or on the graph­i­cal win­dow en­abled by Qemu em­u­la­tion, and semi-host­ing out­put from the tar­get un­der the Con­sole tab. At present, the Qemu based sim­u­la­tor sup­ports LED blink­ing and but­ton-press­ing only; to test other pe­riph­er­als, you need to go for a real tar­get.

If you are not plan­ning to trace the code, step by step, or watch the in­ter­me­di­ate snapshots, right click on the project and se­lect Run Con­fig­u­ra­tions un­der the Run As sub-menu. This ex­e­cutes code di­rectly on a real tar­get or un­der Qemu. Run and de­bug ses­sions can also be launched us­ing the avail­able menu op­tions or tool­bar op­tions.

RISC-V ar­chi­tec­ture sup­port

RISC-V, pro­nounced as RISC five, is an open in­struc­tion set ar­chi­tec­ture that is based on RISC prin­ci­ples. It en­ables open hard­ware de­sign in a bet­ter way as the ISA is patent­free, un­like other ar­chi­tec­tures, and many CPU de­signs are avail­able un­der the BSD li­cence. Sev­eral projects based on the RISC-V ar­chi­tec­ture are hosted at github.com/riscv like the toolchain, de­bug­ger, emu­la­tor and Linux ker­nel port, file sys­tem, stan­dard li­braries, etc. The GNU MCU Eclipse project comes with added sup­port for this open ar­chi­tec­ture through the plu­g­ins of v4.x on­wards.

Since the project code, nec­es­sary li­braries, toolchain and plu­g­ins are open un­der this en­vi­ron­ment, you can choose the de­sired ver­sions of the toolchain and de­bug­ger from any repos­i­tory of your choice. This helps in get­ting a bet­ter un­der­stand­ing of the whole de­vel­op­ment cy­cle and the anatomy of each phase, as well as the gen­er­ated out­come. You can try these steps and ex­plore fur­ther!

Fig­ure 1: Project tem­plate se­lec­tion

Fig­ure 2: Tar­get con­fig­u­ra­tion

Fig­ure 3: Project set­tings

Fig­ure 4: Blinky demo of Qemu de­bug­ging set­tings

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.