Deel 1 ARM Assembly TI RSLK Robotics Learning Curriculum Lab 7 STM32 Nucleo: 16 stappe

2024 Outeur: John Day | [email protected]. Laas verander: 2024-01-30 07:24

Die fokus van hierdie Instructable is die STM32 Nucleo-mikrobeheerder. Die motivering hiervoor om 'n monteerprojek uit kaal bene te kan skep. Dit sal ons help om dieper te verdiep en die MSP432 Launchpad-projek (die TI-RSLK) te verstaan, wat alreeds die onderwerp was van verskeie instruksies.

Daar is nie baie hulp aanlyn om 'n projek wat slegs vir die MSP432 is, te skep met behulp van die Code Composer Studio. Tot dusver het ons net gekopieer/geplak van 'n voorafgaande monteerprojek. Hierdie benadering het ons goed gedien.

Maar nou, vir Lab 7, het ons 'n bietjie probleme ondervind. Of ten minste 'n tydelike hik. The Lab 7 stel eind-toestand-masjiene bekend, en die eerste ding wat ons teëkom, is die behoefte om 'n verskeidenheid waardes te skep en te gebruik. Aangesien die TI -kursus hoofsaaklik C -programmering gebruik - is dit nie 'n probleem nie. Maar hierdie instruksies het gefokus op die samestelling, nie op C.

Aangesien die skikking slegs leesalleen waardes het, is dit goed om dit in 'n flitsgeheue te plaas, nie in die geheue nie.

Dit lyk asof daar baie meer hulp aanlyn is vir monteerprojekte wat die STM32 MCU gebruik, en daarom begin ons met hierdie instruksies, met die doel om te gebruik wat ons geleer het, om dan aansoek te doen by die MSP432 en die Code Composer Studio.

Op pad na die doelwit het ons ook ervaring opgedoen met nog 'n gewilde mikrobeheerder.

Stap 1: Aanvanklike toets van die toestel

Weereens, waarom kies u veral die STM32 Nucleo?

Eerlik? Omdat ek op soek was na goeie artikels oor bloot-metaal-monteerprojekte vir ARM-beheerders, en ek het op hierdie reeks afgekom. En ook omdat die STM32 'n gewilde MCU blyk te wees.

Ek het wel ondersoek ingestel (daar is baie weergawes om uit te kies - sien prent hierbo), maar uiteindelik het ek dit gekry, aangesien ek Amazon (in die VSA) gaan gebruik.

Dit kom in 'n eenvoudige, maar professionele pakket, met 'n paar opstartinstruksies. Dit was 'n bietjie snaaks om te sien dat die demo wat in die kontroleerder ingebrand is, amper presies was wat ons in die vorige instruksies gedoen het - 'n LED flits en verander die snelheid volgens die druk van 'n knoppie.

Dit lyk asof hierdie ontwikkelingsbord baie ooreenstem met die MSP432, aangesien daar 2 LED's en een drukknoppie is. Die MSP432 het 2 gebruikersknoppies.

Soos u op die foto's kan sien, was ek 'n bietjie verbaas dat die bord 'n mini het en nie 'n mikro -USB nie. Moes hardloop om 'n koord te koop.

'N Ander goeie toets is dat as u dit aan u rekenaar koppel (ek gebruik 'n Linux -boks), dit in my lêerbestuurder verskyn as 'n lêerstelsel met die naam "NODE_F303RE". Opening wat twee lêers openbaar, een HTML en een teks.

Dit is dit, maar ten minste sê dit ook dat konneksie redelik maklik lyk.

Nou is ons gereed om te begin.

Ek gaan probeer om nie die goeie inligting uit die IVONOMICON Bare Metal -artikelreeks te herhaal nie, maar dit eerder uit te brei.

Stap 2: Die noodsaaklikhede

Die eerste ding wat ons nodig het, is 'n samesteller.

En dan het ons 'n ontfouter nodig:

devchu@chubox: ~ $ sudo apt-get install gdb-arm-none-eabi Leespakketlyste … Klaar Gebou vir afhanklikheid bou Lees inligting oor die staat … Klaar Die volgende NUWE pakkette sal geïnstalleer word: gdb-arm-none-eabi 0 opgegradeer, 1 nuut geïnstalleer, 0 om te verwyder en 8 nie opgegradeer nie. Moet 2, 722 kB argiewe kry. Na hierdie operasie word 7, 738 kB ekstra skyfspasie gebruik. Kry: 1 https://us.archive.ubuntu.com/ubuntu xenial/universe amd64 gdb-arm-none-eabi amd64 7.10-1ubuntu3+9 [2, 722 kB] Haal 2, 722 kB in 1s (1, 988 kB/s) Kies pakket wat voorheen nie gekies is nie, gdb-arm-none-eabi. (Lees databasis … 262428 lêers en dopgehou tans geïnstalleer.) Berei voor om uit te pak …/gdb-arm-none-eabi_7.10-1ubuntu3+9_amd64.deb… Gdb-arm-none-eabi uitpak (7.10-1ubuntu3+9) … Verwerk triggers vir man-db (2.7.5-1) … Opstel van gdb-arm-none-eabi (7.10-1ubuntu3+9) …

Stap 3: Die noodsaaklikhede - Windows

Bogenoemde stap het aanvaar dat ons Linux gebruik. Wat as ons Windows gebruik?

U kan na die arm ontwikkelaar -webwerf gaan, en daar is verskeie aflaai -opsies beskikbaar. Ek gebruik 'n Windows 8 -masjien.

Tydens die installasie het ek besluit om dit te installeer op die root "C: \" - skyf in plaas van programlêers, net omdat ek ook cygwin gebruik, en dit was makliker om 'n skakel van my plaaslike asblik na 'n wortel C: - lêergids te maak as al die ander gemors in die pad na programlêers (met spasies, ens.).

So lyk my cygwin -omgewing en pad, ens.

C: / cygwin64 / home / bin / arm-none-eabi-gcc, waar die arm-none-eabi-gcc 'n skakel is na C: / GNUToolsArmEmbedded / 7.2018.q2.update / bin / arm-none-eabi- gcc.

Ek het toe 'n "dev" -gids onder cygwin home geskep, en dit is waar ek die kern. S -lêer geplaas het en die opstel van die samesteller uitgevoer het. (sien verder hieronder vir die samesteller).

Ek het presies dieselfde gedoen vir gdb (arm-none-eabi-gdb).

Stap 4: Wat is die belangrikste aspekte?

So, wat is 'gcc-arm-none-eabi'?

Die gnu -samesteller (GCC) sal programmeertale (soos C) saamstel in inheemse kode vir die masjien waarop dit werk. As u byvoorbeeld 'n C -kode met behulp van GCC op u Windows -masjien sou saamstel, sou dit gebou word om op die Windows -masjien te werk. Die gegenereerde uitvoerbare program sal (tipies) nie op die ARM-mikrobeheerder uitgevoer word nie.

Om programme te bou om af te laai en in die ARM-mikrobeheerder te bou (in ons huidige geval is dit die STM32 Nucelo), moet ons GCC iets anders gee: die vermoë om te "kruis-saamstel". Dit wil sê die vermoë om 'n uitvoerbare stelsel te genereer, nie vir sy eie stelsel (en verwerker) nie, maar vir die doelstelsel (die ARM-mikrobeheerder). Dit is waar 'gcc-arm-none-eabi' ter sprake kom.

Wat is dan "gdb-arm-none-eabi"?

Sodra ons die nuut gegenereerde uitvoerbare in die mikrobeheerder afgelaai en verbrand (geflits) het, sal ons dit waarskynlik wil ontfout-stap vir reël deur die kode. GDB is die gnu -ontfouter, en dit het ook 'n manier nodig om sy werk te doen, maar is gerig op 'n ander stelsel.

Gdb-arm-none-eabi is dus vir GDB, wat gcc-arm-none-eabi vir GCC is.

'N Ander voorgestelde pakketinstallasie was die "libnewlib-arm-none-eabi". Wat is daardie een?

Newlib is 'n C -biblioteek en wiskundebiblioteek wat bedoel is vir gebruik op ingebedde stelsels. Dit is 'n samestelling van verskeie biblioteekonderdele, alles onder gratis sagtewarelisensies, wat dit maklik op ingebedde produkte maak.

En laastens, die pakket "libstdc ++-arm-none-eabi". Die een is redelik duidelik; dit is C ++ biblioteek vir die kruis-samesteller; vir ingebedde ARM-mikrobeheerders.

Stap 5: Die Linker -lêer

Kom ons maak 'n skakelskrif.

Een belangrike deel of blok in hierdie lêer is die MEMORY -opdrag.

--- van sourceware.org:

Die standaardkonfigurasie van die skakelaar laat alle beskikbare geheue toe. U kan dit oorheers deur die MEMORY -opdrag te gebruik. Die MEMORY -opdrag beskryf die ligging en grootte van geheueblokke in die teiken. U kan dit gebruik om te beskryf watter geheue streke deur die skakelaar gebruik kan word, en watter geheue streke dit moet vermy. U kan dan afdelings aan spesifieke geheue -streke toewys. Die skakelaar sal afdelingadresse stel op grond van die geheue -streke, en sal waarsku oor streke wat te vol word. Die skakelaar sal nie gedeeltes rondskommel om in die beskikbare streke te pas nie. 'N Skakelscript kan baie gebruike van die MEMORY -opdrag bevat, maar alle gedefinieerde geheueblokke word behandel asof dit in 'n enkele MEMORY -opdrag gespesifiseer is. Die sintaksis vir MEMORY is:

GEHEUE

{naam [(attr)]: OORSPRONG = oorsprong, LENGTE = len…}

Die voorbeeld in die artikel:

/* Definieer die einde van die RAM en die limiet van die stapelgeheue* //* (4KB SRAM op die STM32F031x6 -lyn, 4096 = 0x1000)*//* (RAM begin by adres 0x20000000) _estack = 0x20001000;

GEHEUE

{FLITS (rx): OORSPRONG = 0x08000000, LENGTE = 32K RAM (rxb): OORSPRONG = 0x20000000, LENGTE = 4K}

Ons moet dus uitvind hoeveel FLASH (vir ons program en konstantes, ens) en hoeveel RAM (vir gebruik deur die program; hoop en stapel, ens) vir ons spesifieke bord. Dit raak 'n bietjie interessant.

Die mooi kaartjie wat by die Nucleo kom, sê dat dit 'n flitsgeheue het van 512 Kbytes, en dat SRAM 80 Kbytes is. As u dit aan USB koppel, word dit egter as 'n lêerstelsel met twee lêers gemonteer, en beide die lêerbestuurder en GParted dui aan dat dit meer as 540+ kbytes spasie het. (RAM?).

MAAR as u probeer om die twee lêers met die lêerbestuurder uit te vee, om die toestel te ontkoppel en weer aan te sluit, word die twee lêers steeds gewys. (en die lêerbestuurder het iets herken omdat daar 'n klein "sluit" -ikoon op elke lêer is.

Laat ons dus gaan met die syfers op die kaart. Nou neem ons die voorbeeld hierbo en omskep dit in ons spesifieke bord.

U kan iets soos hierdie aanlyn -geheue -omskakelaar gebruik om van die algemene KB na 'n spesifieke aantal grepe te gaan.

Dan wil u dalk 'n aanlyn desimale na heksomskakelaar gebruik.

/ * Definieer die einde van die RAM en die limiet van die stapelgeheue */

/* (4KB SRAM op die STM32F031x6 -lyn, 4096 = 0x1000)* //* die voorbeeld*/

/ * stap 1: (80KB SRAM op die STM32F303RE, 81920 = 0x14000) * // * ons bord */

/* stap 2, voeg die hex -grootte by hex -beginadres (hieronder). */

/ * (RAM begin by adres 0x20000000) */

_estack = 0x20001000; / * die voorbeeld */

_estack = 0x20014000; / * ons bord */

GEHEUE {

FLITS (rx): OORSPRONG = 0x08000000, LENGTE = 512K

RAM (rxb): OORSPRONG = 0x20000000, LENGTE = 80K

}

Kom ons noem die bogenoemde lêer "linker.script.ld".

Stap 6: Die vektortabel

Nou gaan ons 'n klein samestellêer (met voorskrifte) skep om 'n baie basiese hantering van onderbrekings te doen. Ons sal die voorbeeld van die artikel volg en 'n lêer met die naam 'core. S' skep.

Hier is weer die voorbeeld van die lêerinhoud, maar ek het 'n verandering vir ons spesifieke bord aangebring:

// Hierdie instruksies definieer die eienskappe van ons chip en

// die monteringstaal wat ons sal gebruik:.syntax unified /*Sien hieronder na hierdie kodegebied* //*.cpu cortex-m0* / /*lewer kommentaar op hierdie reël van die voorbeeld* /.cpu cortex-m4 /* voeg in plaas daarvan die karton van ons bord toe. sien die prent hierbo in hierdie stap * / /*.fpu softvfp * / / *lewer kommentaar op hierdie reël van die voorbeeld * /.fpu vfpv4 / *voeg in plaas daarvan ons bord toe; dit het wel 'n FPU */.thumb // Globale geheue -liggings..global vtable.global reset_handler / * * Die werklike vektortabel. * Vir die eenvoud is slegs die grootte van die RAM en 'reset' hanteerder * ingesluit. */.tipe vtable, %object vtable:.word _estack.word reset_handler.size vtable,.-vtable

Hmm.. Nee '.align' richtlijn

Dit is egter nie kritiek nie. Meer hieroor (miskien) later.

.syntax verenig

.syntax [verenig | verdeel]

Hierdie richtlijn stel die Instruksiestel-sintaksis in soos beskryf in die afdeling ARM-Instruksieset

9.4.2.1 Instruksiestelsel Sintaksis Twee effens verskillende sintaksis ondersteun ARM- en THUMB -instruksies. Die standaard, verdeel, gebruik die ou styl waar ARM en THUMB instruksies hul eie, aparte sintaksis gehad het. Die nuwe, verenigde sintaksis, wat gekies kan word via die.syntax richtlijn.

.fpu vfpv4

Die GCC -samesteller kan binaries produseer met verskillende opsies aangaande dryfpunt: sag - geskik om op CPU's te werk sonder FPU - berekeninge word in sagteware gedoen deur sagteware wat deur die samesteller gegenereer word - geskik om op CPU's met of sonder FPU te werk - sal 'n FPU gebruik indien teenwoordig. Vir ons spesifieke saak (u moet u eie navorsing doen), voldoen die FPU van hierdie spesifieke raad aan vfpv4. Miskien moet u hiermee speel. Of laat dit selfs by softfp.

.duim (vs.arm)

Hierdie ARM -mikrobeheerder het eintlik 'n mengsel van instruksiestelle. Een is ARM, 'n ander is DUIM. Een verskil is 16-bis instruksies vs 32-bit instruksies. Hierdie opdrag sê dus vir die samesteller om die daaropvolgende instruksies as THUMB of ARM te behandel.

Ons gaan die res van die lêer net soos dit is, aangesien hierdie instruksies nog nie ingegaan het op onderbrekingsgedrewe samestelling nie.

Stap 7: Die vergaderingsweergawe van 'n 'Hello World' -program

Die volgende kan ook in die voorheen geskepte "core. S" -lêer ingaan. Dit kom weereens uit die voorbeeld in die artikel.

/ * * Die reset -hanteerder. Gebel op herstel. */.tipe reset_handler, %function reset_handler: // Stel die stapelwyser aan die einde van die stapel. // Die '_estack' -waarde word gedefinieer in ons skakelskrif. LDR r0, = _stack MOV sp, r0

// Stel 'n paar dummy waardes. As ons hierdie waardes sien

// in ons ontfouter weet ons dat ons program // op die skyfie gelaai is en werk. LDR r7, = 0xDEADBEEF MOVS r0, #0 main_loop: // Voeg 1 by om 'r0' te registreer. ADDS r0, r0, #1 // Lus terug. B main_loop.size reset_handler,.-Reset_handler

Die doel van bogenoemde program is dus om 'n herkenbare patroon in een kern MCU -register (in hierdie geval R7) te laai, en 'n toenemende waarde wat vanaf nul begin in 'n ander MCU -register (in hierdie geval R0). As ons deur die uitvoerkode gaan, moet ons die datatoename van R0 sien.

As u saam met die instruksies oor die MSP432 en die TI-RSLK-kursus/laboratoriums gevolg het, behoort u al die bogenoemde programme byna bekend te wees.

Die enigste nuwe ding wat ek kan sien, is die gebruik van "=" by die laai van "DEADBEEF" om R7 te registreer. Ons het dit nie gebruik nie.

Die 'core. S' lêer wat hier aangeheg is, bevat nou die volledige bron.

Stap 8: Stel die kode saam

Dit is tyd om 'n paar opdragreëls te doen. Iets werklik, uiteindelik.

Ons is egter nie heeltemal daar nie. Ons moet weer die opdrag in die artikel aanpas en aanpas by ons eie situasie.

Hier is die voorbeeldkode:

arm -geen -eabi -gcc -x samesteller -met -cpp -c -O0 -mcpu = korteks -m0 -duim -Wandkern. S -o kern.o

As ons na die gnu.org -webwerf gaan vir GCC, (in hierdie geval weergawe 7.3),

x

Die -x is om die taal te spesifiseer. As dit nie -x is nie, dan sal die samesteller probeer raai deur die lêeruitbreiding te gebruik. (in ons geval, *. S).

Bogenoemde voorbeeld uit die artikel spesifiseer assembler-with-cpp, maar ons kan net assembler doen.

c

Die -c sê stel saam, maar moenie skakel nie.

O0

Die -O is om die optimaliseringsvlak te stel. Deur -O0 (oh -zero) te gebruik, word gesê: "verminder die tyd om op te stel en maak die ontfouting die verwagte resultate. Dit is die standaard".

mcpu = korteks-m0

Die -mcpu spesifiseer die naam van die doelverwerker. In ons geval sou dit korteks-m4 wees.

duim

Die -mthumb spesifiseer die keuse tussen die generering van kode wat ARM- en THUMB -toestande uitvoer.

Muur

Die -Wall is natuurlik baie algemeen en bekend. Dit skakel alle waarskuwingsvlae aan.

Uiteindelik het ons aan die einde van die opdrag die invoerlêer core. S en die uitvoerlêer core.o.

Hier is die nuwe opdragreël wat by ons spesifieke geval pas.

arm -geen -eabi -gcc -x samesteller -c -O0 -mcpu = korteks -m4 -duim -Wandkern. S -o kern.o

En dit saamgestel.

Stap 9: Koppel die program

Direk uit die voorbeeld in die artikel, het ons dit:

arm -geen -eabi -gcc core.o -mcpu = korteks -m0 -duim -Wand --specs = nosys.specs -nostdlib -lgcc -T./STM32F031K6T6.ld -o main.elf

Die meeste van die bogenoemde het u gesien. Hieronder is wat nuut is.

spesies = nosys.specs

Hierdie een is 'n bietjie moeilik om te verduidelik.

Dit het te doen met 'semihosting' en 'retargeting', en dit het te doen met input / output. Dit het ook te doen met stelseloproepe en biblioteke.

Gewoonlik bied ingebedde stelsels nie standaard toevoer-/afvoertoestelle nie. Dit sal stelsel- of biblioteekoproepe beïnvloed (byvoorbeeld: printf ()).

Semihosting beteken dat die ontfouter (sien stap 11 -prent met ontfoutgedeelte in rooi omring) 'n spesiale kanaal het en die semihosting -protokol gebruik, en u kan die uitvoer van printf () op die gasheermasjien sien (via die ontfouter).

Retargeting, aan die ander kant, beteken dat dieselfde stelsel- of biblioteekoproepe iets anders beteken. Hulle doen iets anders, wat sin maak vir die ingebedde stelsel. In 'n sekere sin, sê vir printf (), is daar 'n nuwe implementering, 'n hergerigte implementering van die funksie.

As ons dit alles gesê het, beteken die --specs = nosys.specs dat ons nie halfhaas sal wees nie. Dit sou dan normaalweg beteken dat ons weer begin fokus. Dit bring ons by die volgende vlag.

nostdlib

Die skakelaar -nostdlib word gebruik om 'n program te koppel wat bedoel is om selfstandig te werk. -nostdlib impliseer die individuele opsies -nodefaultlibs en -nostart -lêers. Hieronder bespreek ons die twee opsies afsonderlik, maar die mees tipiese gebruik is net nostdlib vir eenmalige inkopies. strlen en vriende). Die skakelopsie -nodefaultlibs skakel skakel met die standaardbiblioteke uit; die enigste biblioteke wat gekoppel is, is presies die biblioteke wat u eksplisiet aan die skakelaar noem deur die -l -vlag te gebruik.

lgcc

libgcc.a is 'n standaardbiblioteek wat interne subroetines bied om tekortkominge van spesifieke masjiene te oorkom. Die ARM -verwerker bevat byvoorbeeld geen afdelingsinstruksie nie. Die ARM -weergawe van libgcc.a bevat 'n afdelingsfunksie en die samesteller stuur oproepe na die funksie waar nodig.

T

Dit is slegs 'n manier om die skakelaar te vertel om hierdie lêer as die skakelskrif te gebruik. In ons geval is die lêernaam linker.script.ld.

o main.elf

Laastens vertel ons die skakelaar wat die naam van die finale afbeeldingslêer sal wees wat in ons toestel verbrand/geflits sal word.

Hier is ons weergawe van die volledige opdragreël, aangepas vir ons spesifieke situasie:

arm -geen -eabi -gcc core.o -mcpu = korteks -m4 -duim -Wand --specs = nosys.specs -nostdlib -lgcc -T./linker.script.ld -o main.elf

Ons maak seker dat die scriptlêer en die core.o-lêer albei in dieselfde gids is, waar ons die bogenoemde opdragreël sal uitvoer.

En dit skakel sonder probleme.

N tjek

Ons hardloop dan:

arm-geen-eabi-nm main.elf

en ons kry:

devchu@chubox: ~/Development/Atollic/TrueSTUDIO/STM32_workspace_9.1 $ arm-none-eabi-nm main.elf 20014000 A _estack 08000010 t main_loop 08000008 T reset_handler 08000000 T vtable

Lyk goed. Die arm-none-eabi-nm-opdrag is 'n manier om simbole binne objeklêers te lys.

Stap 10: Toets verbinding met die STM32 Nucleo-64

U eerste missie, as u besluit om dit te aanvaar, is om u stelsel na u ontwikkelingsbord te laat kyk.

Die gebruik van Windows

Vir Windows het ek besluit om TrueSTUDIO van Atollic (gratis weergawe) te installeer. Dit was 'n pynlose installasie en dit het die bestuurder outomaties geïnstalleer, sodat ek die st-link kon gebruik om die verbinding te toets. Nadat ek die TrueSTUDIO geïnstalleer het en die apparaatbestuurder die toestel sien, het ek die texan/stlink -gereedskap afgelaai wat deur die Bare Metal -artikel voorgestel word. Ek het die gids weer direk onder "C: \" geplaas, en weer 'n paar skakels van my plaaslike cygwin -asblik na die opdragte geskep.

ln -s /c/STM32. MCU/stlink-1.3.0-win64/bin/st-info.exe ~/bin/st-info

As 'n aanvanklike toets om te sien of ons regtig met die toestel kan kommunikeer, hardloop ek:

st-info-sonde

En teruggekom:

Het 1 stlink -programmeerders gevind

Nou weet ons dat ons oor ons ontwikkelingsraad kan praat/navraag doen.

Gebruik Linux

Vir Linux het u nie regtig 'n bestuurder nodig nie. Maar vir Debian moet u die eerste gereedskap uit die bron bou.

git -kloon

Maak seker dat u libusb-1.0-0-dev geïnstalleer het.

gepaste lys | grep -E "*libusb.*dev*"

U moet sien:

libusb-1.0-0-dev/xenial, nou 2: 1.0.20-1 amd64 [geïnstalleer]

of iets soos dit.

Om dit te installeer:

sudo apt-get install libusb-1.0-0-dev

Let daarop dat bogenoemde nie dieselfde is as:

sudo apt-get installeer libusb-dev

Die korrekte ontbrekende libusb dev kan veroorsaak dat cmake probleme ondervind.

CMake -fout: die volgende veranderlikes word in hierdie projek gebruik, maar dit is ingestel op NOTFOUND. Stel dit asseblief in of maak seker dat dit in die CMake -lêers korrek ingestel en getoets is: LIBUSB_INCLUDE_DIR (ADVANCED)

Verander na die hoofmap van die projek (… blah /blah /stlink). Doen 'maak' release '.

Nadat dit gebou is, moet die gereedskap onder ".. /build /Release" wees.

U kan dan 'st-info --probe' uitvoer. Hier is die uitset met die Nucleo verbind, dan nie.

devchu@chubox: ~/Development/stlink $./build/Release/st-info --probe Gevind 1 stlink programmeerders reeks: 303636414646353034393535363537 openocd: "\ x30 / x36 / x36 / x41 / x46 / x46 / x35 / x30 / x34 / x39 / x35 / x35 / x36 / x35 / x37 "flits: 524288 (bladsygrootte: 2048) sram: 65536 chipid: 0x0446 descr: F303 toestel met hoë digtheid devchu@chubox: ~/Development/stlink $./build/Release/st- info --probe Gevind 0 stlink programmeerders devchu@chubox: ~/Development/stlink $

Stap 11: Kom ons gebruik GDB saam met Linux

As u dit alles probeer het, en tot dusver gekom het - wonderlik! Uitstekend. Laat ons nou 'n bietjie pret hê.

As u hierdie ARM-ontwikkelingsborde koop, of dit nou die MSP432 Launchpad van Texas Instruments is, of die een wat ons nou bespreek, die Nucleo-F303 (STM32 Nucleo-64), kom hulle gewoonlik al geflits met 'n lopende program, gewoonlik 'n paar blink programme wat ook die druk van 'n skakelaar insluit om die tempo waarteen die LED (s) flikker, te verander.

Voordat ons dit so vinnig wil skryf, laat ons kyk wat ons moet sien en doen.

Met Linux, maak 'n terminale oop, verander die gids van die stlink git-projek wat ons pas gebou het, en vind die st-util-instrument.

devchu@chubox: ~/Development/stlink $ vind. -naam st-util

./build/Release/src/gdbserver/st-util

Begin die hulpmiddel. Aangesien ons ons verbinding met st-info-probe alreeds getoets het, behoort ons 'n bietjie uitset te kry:

devchu@chubox: ~/Development/stlink $./build/Release/src/gdbserver/st-util

st-util 1.4.0-50-g7fafee2 2018-10-20T18: 33: 23 INFO common.c: Laai toestelparameters …. 2018-10-20T18: 33: 23 INFO common.c: Toestel gekoppel is: F303 hoëdigtheidstoestel, id 0x10036446 2018-10-20T18: 33: 23 INFO common.c: SRAM-grootte: 0x10000 grepe (64 KiB), Flash: 0x80000 grepe (512 KiB) in bladsye van 2048 grepe 2018-10-20T18: 33: 23 INFO gdb-server.c: Chip ID is 00000446, Core ID is 2ba01477. 2018-10-20T18: 33: 23 INFO gdb-server.c: Luister by *: 4242 …

Dit is die GDB -bediener wat nou werk, en dit sien ons ontwikkelingsbord, en nog belangriker, dit luister na poort 4242 (die standaardpoort).

Nou is ons gereed om die GDB -kliënt af te vuur.

Maak 'n ander terminale in Linux oop, voer dit in:

arm-geen-eabi-gdb -tui

Dit is presies dieselfde as om gdb streng opdragreëls uit te voer, maar dit produseer eerder 'n teksgebaseerde terminale (ek vermoed dat dit vloeke gebruik).

Ons het die GDB -kliënt en die GDB -bediener aan die gang. Die kliënt is egter nie aan die bediener gekoppel nie. Op die oomblik weet dit niks van ons Nucleo (of bord van u keuse nie). Ons moet dit vertel. In die terminaal moet u prompt nou die "(gdb)" wees. Voer in:

hulp teiken

Dit sal u 'n lys gee. Let op dat die een wat ons wil hê, 'n uitgebreide afstandsbediening is - Gebruik 'n afgeleë rekenaar via 'n reekslyn.

Maar ons moet dit ook die ligging gee. Tik dus by die (gdb) prompt:

(gdb) teiken uitgebreide-afgeleë plaaslike gasheer: 4242

U behoort so 'n antwoord terug te kry:

(gdb) teiken uitgebreide-afgeleë plaaslike gasheer: 4242

Foutopsporing op afstand met behulp van localhost: 4242 0x080028e4 in ?? ()

Intussen het ons by die terminale met die st-util gdbserver die volgende gekry:

2018-10-20T18: 42: 30 INFO gdb-server.c: 6 hw breekpuntregisters gevind

2018-10-20T18: 42: 30 INFO gdb-server.c: GDB gekoppel.

Stap 12: Laat ons herhaal, met Windows en flits ons program

Die stappe om die st-util gdbserver en die arm-none-eabi-gdb-kliënt te bestuur, is in wese dieselfde as wat ons tydens die vorige stap gedoen het. U maak twee terminale oop (cygwin, DOS cmd of Windows Powershell), vind die ligging van die st-util, voer dit uit. Voer die arm-none-eabi-gdb-kliënt in die ander terminale uit. Die enigste verskil is dat die -tui (terminale -gebaseerde teksaansig) -modus waarskynlik nie ondersteun word nie.

As bogenoemde in Windows gewerk het, moet u waarskynlik stop (net die kliënt). Op hierdie punt moet u op een of ander manier die GDB -kliënt laat loop waar u build -lêer is ("core.out"), of die hele pad na die lêer as 'n argument by die GDB -kliënt voeg.

Ek het my lewe vereenvoudig deur cygwin te gebruik en skakels te skep van my plaaslike $ HOME // bin -gids na waar albei hierdie instrumente geleë is.

Ok, ons het net soos voorheen saamgestel en gekoppel, en ons lêer main.elf gereed om geflits te word.

Ons gebruik st-util in een venster. Ons begin die GDB-kliënt weer, hierdie keer doen ons:

arm-geen-eabi-gdb main.elf

Ons laat dit begin, wag vir die (gdb) prompt, doen dieselfde verbindingskommando na die GDB-bediener (st-util), en ons is gereed om die uitvoerbare te flits. Dit is baie anti-klimaat:

(gdb) laai

As u met cygwin -terminale werk, is daar 'n bekende probleem dat konsole -opdragte soms nie uitgevoer word nie. In ons geval was die venster met die bediener heeltemal stil. Die een wat die kliënt bestuur, waar ons die vrag uitgevoer het, lewer hierdie:

Laai -afdeling. Teks, grootte 0x1c lma 0x8000000 Begin adres 0x8000000, laai grootte 28 Oordragkoers: 1 KB/sek, 28 grepe/skryf.

Stap 13: Flits met Linux - Meer beloning: D

Stap 14: Kom ons duik 'n bietjie dieper

As u hier kom, uitstekend. Kom ons gaan aan.

Waarom kyk u nie binne -in die main.elf -lêer, die uitvoerbare lêer nie? Voer die volgende uit:

arm-none-eabi-objdump -d main.elf

U behoort iets soos hierdie te sien:

main.elf: lêerformaat elf32-littlearm

Demontage van seksie. Teks:

08000000:

8000000: 00 40 01 20 09 00 00 08.@. ….

08000008:

8000008: 4802 ldr r0, [st., #8]; (8000014) 800000a: 4685 mov sp, r0 800000c: 4f02 ldr r7, [pc, #8]; (8000018) 800000e: 2000 movs r0, #0

08000010:

8000010: 3001 voeg r0 by, #1 8000012: e7fd b.n 8000010 8000014: 20014000.word 0x20014000 8000018: deadbeef.word 0xdeadbeef

Watter klein nuggets kan ons uit die bogenoemde uitset kry?

As u onthou toe ons die linker.script.ld -lêer bespreek en skep, het ons gesê dat hierdie ARM -toestelle RAM het wat begin by 0x20000000, en dat FLASH -geheue by 0x08000000 begin.

Ons kan dus sien dat die program inderdaad so is dat dit alles in FLASH -geheue voorkom.

Toe, hierbo, maar later, toe ons die gedeelte "Hallo wêreld" bespreek, was daar 'n verklaring waarin ons 'n onmiddellike, konstante letterlike waarde ("0xDEADBEEF") in 'n MCU -kernregister ("R7") laai.

Die verklaring was:

LDR R7, = 0xDEADBEEF

In ons kode is dit die enigste plek waar ons selfs DEADBEEF noem. Nêrens anders. En tog, as u na die bogenoemde gedemonteerde/gerekonstrueerde instruksies, ens. Kyk, is daar meer wat verband hou met DEADBEEF as wat ons gedink het.

Die samesteller/skakelaar het op die een of ander manier besluit om die waarde van DEADBEEF permanent in 'n FLASH -adres, op die plek 0x8000018, te flits. En dan het die samesteller ons bogenoemde LDR -instruksie verander na:

LDR R7, [PC, #8]

Dit het selfs vir ons 'n opmerking gemaak. Hoe lekker. En dit vertel ons om die huidige programtellerwaarde (die rekenaarregister) te neem, 0x8 by die waarde te voeg, en dit is waar DEADBEEF verbrand is, die waarde te kry en dit in R7 te vul.

Dit beteken dus ook dat die programteller (rekenaar) verwys na adres 0x8000010, wat die begin van die main_loop is, en dat die DEADBEEF -waarde op twee adresse sit na die einde van main_loop.

Stap 15: Laastens 'n kort kykie na die program wat uitgevoer word

Selfs as u GDB verlaat, voer die opdrag weer in. U hoef nie eens 'n lêer daaraan te gee nie; ons flikker nie meer nie, ons bestuur dit net.

Nadat u die GDB-kliënt weer aan die GDB-bediener gekoppel het, by die (gdb) opdragprompt:

(gdb) inligtingregisters

U behoort so iets te sien:

r0 0x0 0

r1 0x0 0 r2 0x0 0 r3 0x0 0 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0 sp 0x20014000 0x20014000 lr 0xffffffff 429496789500

Maar dan, by die (gdb) prompt, voer:

(gdb) gaan voort

En druk vinnig CTRL-C. Dit moet die program onderbreek. Voer die opdrag "info registers" weer in.

Hierdie keer lyk dit anders:

(gdb) inligtingregisters

r0 0x350ffa 3477498 r1 0x0 0 r2 0x0 0 r3 0x0 0 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0xdeadbeef 3735928559 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x100000 0000 0000 0000 0000 0000 0000 0000 00000 16777216

Wat het gebeur? Presies wat ons wou hê. DEADBEEF is in R7 gelaai, en R0 het (uiters vinnig) toegeneem. As u dit herhaal, sien u R0 weer met 'n ander waarde.

Stap 16: Ons wou 'n leesalleen-skikking in Flash skep

Een manier om die ekwivalent van 'n skikking te skep met behulp van samestelling en voorskrifte, is soos volg:

.type myarray, %object // die naam of etiket 'myarray' word gedefinieer as 'n objekttipe.

myarray: // dit is die begin van die verklaring van 'myarray' // (waaruit dit sal bestaan)..word 0x11111111 // die eerste lid of waarde in 'myarray'..word 0x22222222 // die tweede waarde (aangrensende adresse)..word 0x33333333 // ensovoorts..grootte myarray,.-myarray // die samesteller/samesteller weet nou waar die einde of // grens van 'myarray' is.

Noudat ons dit in FLASH -geheue opgestel het, kan ons dit in die program gebruik. Hieronder is 'n gedeelte:

LDR R1, myarray // laai data wat op die eerste plek van 'myarray' voorkom. ' // dit is nie wat ons wil hê nie.

LDR R1, = myarray // laai die liggingwaarde self (die 1ste adres), // nie die data nie. // // dit is wat ons wil hê.

MOV R2, #0 // R2 hou 'n telling om seker te maak ons loop nie weg nie

// einde van skikking. LDR R3, = myarrsize // R3 sal die ekwivalent wees van 'myarrsize'.

// R0 sal ons data bewaar

main_loop:

LDR R0, [R1] // Laai die data waarna R1 ('myarray') wys, in R0. CMP R2, R3 // Is ons by die limiet van die skikking? BEQ main_loop // As ons is, is ons klaar, so ons sal net vir ewig loop.

VOEG R2 by, #1 // Anders kan ons deur die skikking herhaal.

VOEG R1, #4 // Voeg 4 by om R1 te registreer, sodat dit korrek na volgende wys

// adres..

B main_loop // Lus terug.

Die video gaan deur dit alles, en daar is 'n fout daarin. Dis goed; dit toon aan dat dit 'n belangrike lopie- en ontfoutingskode is. Dit toon 'n klassieke geval van die einde van 'n skikking.