ARM Cortex M0 Artykuły na programistamag 73 74 75 Rafała Kozika

Odpowiedz Nowy wątek
2019-07-08 12:06
0

Cześć.

Nie wiem czy wątek Embedded to dobre miejsce na to, z góry przepraszam jeśli nie. Chociaż piszę tutaj teraz z konkretnym problemem, dałem ogólną nazwę tematu, ponieważ może być tutaj kontynuowana dyskusja o tym, o tych artykułach, coretx m0 itd. Ok, do rzeczy.

Zainteresowały mnie artykuły Rafała Kozika na temat CortexM0. Począwszy od artykułu "Małe jest piękne" z numeru 73 programisty do numeru 75 w którym jest opisane jak kodować w C. Kupiłem 2 miesiące temu tę płytkę Nucleo-F031K6, do tej pory próbowałem klepać kod w assemblerze, a teraz chciałem w C. Z pierwszym kodem który miga diodą nie ma problemu, wklejam do terminala ten kod który jest tam podany w tym artykule, dodaję / Vector table / asm(".long 0x20001000"); asm(".long main+1"); bo bez tego nie będzie migać, program się kompiluje, wgrywam go i wszystko działa jak należy. Dioda miga.

arm-none-eabi-gcc -Wall -g -mcpu=cortex-m0 -mthumb -O0 -Ttext 0x8000000 -e main -nostartfiles -o main.elf main.c

Jednak z tym przykładem jak wysyłać i odbierać informacje przez port szeregowy mam problem przy kompilacji. Tak samo, kopiuję te listingi z artykułu i wklejam do terminala.

arm-none-eabi-gcc -c -Wall -g -mcpu=cortex-m0 -mthumb -O0 –specs=nano.specs -o uart.o uart.c
 arm-none-eabi-gcc -g -o uart.elf -T linker.ld --specs=nano.specs -nostartfiles -mcpu=cortex-m0 -mthumb startup.o uart.oarm-none-eabi-size uart.elf

I dostaję m.in błędy arm-none-eabi-gcc: error: pecs=nano.specs: No such file or directory oraz arm-none-eabi-gcc: error: uart.oarm-none-eabi-size: No such file or directory arm-none-eabi-gcc: fatal error: input file 'uart.elf' is the same as output file które widać na rysunku poniżej.

Ze skopliowaniem kodu startowego czyli komendą nie ma problemu. Jednak z tym wyżej wywala jakieś błędy i nie bardzo wiem jak ten problem rozwiązać.

arm-none-eabi-gcc -g -o uart.elf -T linker.ld --specs=nano.specs -nostartfiles -mcpu=cortex-m0 -mthumb -I CMSIS startup.S uart.c

Dodam że pobrałem instalki GCC gcc-arm-none-eabi-8-2018-q4-major-win32 z https://developer.arm.com/too[...]nu-toolchain/gnu-rm/downloads
OpenOCD serwer GDB z github.com/gnu-mcu-eclipse/openocd/releases
Niby wszystko powinno być ok, skoro pierwszy program w C do migania diodą działa, a jednak nie jest i nie wiem skąd te błędy. Albo coś przeoczyłem, nie wiem...

Może ktoś miał taki sam problem albo wie jak to rozwiązać.
Pozdrawiam.

title

Pozostało 580 znaków

2019-07-08 12:34
2

--specs a nie -specs (bądź odwrotnie, ale konsewkentnie). To tak najsampierw. ;)

Pozostało 580 znaków

2019-07-08 12:54
0
alagner napisał(a):

--specs a nie -specs (bądź odwrotnie, ale konsewkentnie). To tak najsampierw. ;)

Udało się rozwiązać ten problem :) Skompilowało bez błędu, czyli listing

arm-none-eabi-gcc -c -Wall -g -mcpu=cortex-m0 -mthumb -O0 –specs=nano.specs -o uart.o uart.c 

to znaczy był jeszcze błąd w ścieżce do stm32f042x6.h ale dałem #include "CMSIS/stm32f042x6.h" bo ten plik jest w folderze CMSIS. Ogólnie dziwne, bo z dwoma kreskami --specs coś tam załapało ale skompilowało z jedną kreską tzn -specs ... do skutku... Dzięki.

Ok, zostało jeszcze do rozwiązania to. Co pisze w programistamag o tym - "Kolejnym krokiem jest zlinkowanie naszego kodu z biblioteką standardową oraz zasemblowanym wcześniej kodem startowym"- czyli ten listing poniżej.

arm-none-eabi-gcc -g -o uart.elf -T linker.ld --specs=nano.specs -nostartfiles -mcpu=cortex-m0 -mthumb startup.o uart.o arm-none-eabi-size uart.elf

Bo w kolejnym kroku jest właśnie ten listing, i tutaj mam dalej te błędy

arm-none-eabi-gcc: error: arm-none-eabi-size: No such file or directory
armm-none-eabi-gcc: fatal error: input file 'uart.elf' is the same as output file

Pojawiło się uart.o teraz, więc wszystkie pliki niby są...

title

edytowany 4x, ostatnio: goose_, 2019-07-08 13:07

Pozostało 580 znaków

2019-07-08 13:16
0

Masakra, dopiero teraz się zorientowałem że to są 2 osobne linie, tyle że zabrakło w tym artykule znaku > przy drugiej linii i tak:

arm-none-eabi-gcc -g -o uart.elf -T linker.ld --specs=nano.specs -nostartfiles -mcpu=cortex-m0 -mthumb startup.o uart.o
arm-none-eabi-size uart.elf

A arm-none-eabi-size to jest kolejny listing, tylko myślałem że to jest razem heh
Dobra, udało sie skompilować. Dzięki alagner za pomoc, bo sam bym tego nie rozkminił.

No, i teraz ten program mi śmiga, dzięki za pomoc :)

edytowany 1x, ostatnio: goose_, 2019-07-08 13:19

Pozostało 580 znaków

2019-07-08 14:37
3

@goose_: patrz gdzie jest bubel:

arm-none-eabi-gcc -c -Wall -g -mcpu=cortex-m0 -mthumb -O0 –specs=nano.specs -o uart.o uart.c
                                                          ^
                                                          ło tu

Komuś Word zrobił psikusa i zamienił dwa minusy na półpauzę. ;)


edytowany 1x, ostatnio: furious programming, 2019-07-08 14:38

Pozostało 580 znaków

2019-07-08 15:27
0

Już działa, dzięki. Rzeczywiście coś było chyba z edytorem bo ten znak - jest chyba inny, więc po skasowaniu tej kreski i wklepaniu jeszcze raz tych znaków -- przed specs załapało.

edytowany 2x, ostatnio: goose_, 2019-07-08 16:44

Pozostało 580 znaków

2019-07-15 06:23
0

Witam ponownie. Miał ktoś do czynienia z FreeRTOS w tym wydaniu https://github.com/WRansohoff/min_freertos_blink ?

Tutaj jest link do bloga skąd to wziąłem https://vivonomicon.com/2018/[...]6-multitasking-with-freertos/ . Ogólnie jest tam kilka eksperymentów z tą płytką Nucleo-F031K6 https://vivonomicon.com/category/stm32_baremetal_examples/

Ok, z jakim problemem teraz piszę :)
W pliku Makefile na samym początku są zmienne dla MCU i jest tam domyślnie włączone MCU ?= STM32F103C8, reszta jest jako komentarz https://github.com/WRansohoff[...]os_blink/blob/master/Makefile . To jest zdaję się Cortex M3 a mnie interesuje Cortex M0 czyli #MCU ?= STM32F030K6 , to jest pierwsza zmienna która jest jako komentarz. Więc zmieniam to, poprzednie jako komentarz a to MCU ?= STM32F030K6 włączam jako zmienna. Następnie make all i dostaję plik main.elf który sobie mogę wgrać teraz na płytkę. Tylko co mnie zastanawia to jego rozmiar, bo ma on aż 169 kB. Ta płytka ma tylko 64 kB pamięci flash, więc coś jest chyba nie tak...

Co tam jeszcze zmieniałem w tych plikach?

  1. Pliku FreeRTOSConfig.h z folderu głównego nie zmieniałem tylko skopiowałem do freertos\Source\include
  2. W tym pliku Makefile w linii 55 jest ścieżka do tych programów arm-none-eabi-xxx TOOLCHAIN = /usr/bin , więc dałem ścieżkę tam gdzie mam to zainstalowane, czyli TOOLCHAIN = C://Program Files (x86)/GNU Tools ARM Embedded/8 2018-q4-major/bin
  3. W pliku STM32F030K6T6_boot.S https://github.com/WRansohoff[...]r/boot_s/STM32F030K6T6_boot.S w linii 67 zamiast B main dałem BL main. Dopiero raczkuję w temacie, ale B to skok pod etykietę a BL to odwołanie do funkcji, a tutaj jest właśnie odwołanie do funkcji a nie skok pod etykietę. Jakiś błąd wywalało przy kompilacji i dlatego to zmieniłem. I ruszyło.

Coś takiego mi wywala w terminalu przy kompilowaniu make all jak jest B w tej linii 67 ale jak dam BL, potem make clean, make all to jest już ok, kompiluje się. Przy tym domyślnym MCU z Makefile nie dostaje żadnych błędów ale dla tego pierwszego tak.

boot_s/STM32F030K6T6_boot.o: in function `reset_bss_loop':
(.text+0x2a): relocation truncated to fit: R_ARM_THM_JUMP11 against symbol `main
' defined in .text.startup.main section in src/main.o
collect2.exe: error: ld returned 1 exit status
make: *** [main.elf] Error 1

Ogólnie pytanie czy ktoś bawił się z tym i czy nie zepsuję sobie tej płytki jak spróbuję wgrać ten plik teraz? Bo jednak chyba coś jest nie tak moim zdaniem skoro ten plik ma aż 169 kb!

j31oi51h3oi5h13oiu5hb1o5b1o251ol2n512l512.png

btw. Czytałem artykuł o tym jak zrobić własny RTOS z 42 numeru programisty, zainteresował mnie temat systemów operacyjnych ogólnie. Fajny jest też artykuł "Mały rysownik grafiki trójwymiarowej" z programistymag 76 i 77. Jest tam zadanie żeby zrobić port tego silnika właśnie na tego typu płytce, czy da radę renderować grafikę w czasie rzeczywistym taki procesorek, może nie Cortex M0, ale coś mocniejszego. Więc chcę się trochę tym pobawić teraz...

edytowany 4x, ostatnio: goose_, 2019-07-15 06:55

Pozostało 580 znaków

2019-07-15 08:16
0

BL to o ile pamiętam odpowiednik (w uproszczeniu) "call" z x86 czyli zapamiętuje adres powrotu. Chcesz z maina wychodzić?
EDIT: sprawdź jeszcze jakich rozmiarów HEXa/BINa generuje objcopy.

edytowany 1x, ostatnio: alagner, 2019-07-15 08:18

Pozostało 580 znaków

2019-07-15 09:17
0
alagner napisał(a):

BL to o ile pamiętam odpowiednik (w uproszczeniu) "call" z x86 czyli zapamiętuje adres powrotu. Chcesz z maina wychodzić?
EDIT: sprawdź jeszcze jakich rozmiarów HEXa/BINa generuje objcopy.

Hej, no więc wklepuje do terminala to arm-none-eabi-objcopy -O binary main.elf main.bin I dostaję plik main.bin, ale ma tylko 3 KB (nawet widać na rysunku wyżej ten plik), nie wiem czy to dobrze czy źle... Jakoś dziwnie mało jak na silnik RTOS <?!> Albo ja czegoś nie ogarniam. Otworzyłem w hexedytorze ten plik binary żeby zobaczyć co tam jest w ogóle, niby są tam LED.blink1 LED.Blink2 ale... Poza tym nie wgrywałem do tej pory pliku bin tylko elfy i nie wiem czy to mam tak samo robić jak z tymi przykładami z programistamag, że odpalam openOCD i do drugiego terminala wklepuje arm-none-eabi-gdb potem target remote :3333 potem load main.elf następnie file main.elf, to mogę to zrobić tak samo z .bin że load main.bin i tak dalej.

ale do hexa to nie wiem jak zrzucić, bo ihex to raczej nie jest to, zresztą i tak wywala błąd arm-none-eabi-objcopy: main.hex 64-bit address 0x4b4fa300000000 out of range for Intel Hex file jak daję takie komendy w terminalu arm-none-eabi-objcopy -O ihex main.elf main.hex oraz arm-none-eabi-objcopy -I binary -O ihex main.bin main.hex . A to jest 32 bitowy procesor.

edytowany 5x, ostatnio: goose_, 2019-07-15 09:23

Pozostało 580 znaków

2019-07-15 09:23
0

Raczej dobrze jest, bin to "goły" wsad do pamięci. Jak to programować - a bo ja pamiętam... google Twoim przyjacielem.
Zamiast BL spróbuj B.W albo podobnie. Ogólnie to bym się nie bał, najgorsze imho co możesz płytce zrobić to konieczność podpinania się debugerem przy resecie...
https://community.st.com/s/qu[...]runcated-to-fit-rarmthmjump11

Pozostało 580 znaków

2019-07-15 11:22
0

Ech, masakra jednak z tym jest, bo na Ubuntu 14.04 to stlink się kompliuje a na win8.1 nie, ech.
http://pi19404.github.io/pyVi[...]ion/2015/12/28/STLinkInstall/

Zrzut dmesg

[  355.325392] usb 2-1.4: New USB device found, idVendor=0483, idProduct=374b
[  355.325404] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  355.325411] usb 2-1.4: Product: STM32 STLink
[  355.325417] usb 2-1.4: Manufacturer: STMicroelectronics
[  355.325422] usb 2-1.4: SerialNumber: 066EFF343339415043101640
[  355.381920] usb-storage 2-1.4:1.1: USB Mass Storage device detected
[  355.382222] scsi host8: usb-storage 2-1.4:1.1
[  355.382952] cdc_acm 2-1.4:1.2: ttyACM0: USB ACM device
[  356.382866] scsi 8:0:0:0: Direct-Access     MBED     microcontroller  1.0  PQ: 0 ANSI: 2

Więc idVendor oraz idProduct z folderu stlink.git/etc/udev/rules.d mają zdefiniowe te same wartości co widzę po pisaniu dmseg do terminala. Potem kopiuję te pliki .rules z tego folderu tą komendą sudo cp *.rules /etc/udev/rules.d i restartuje ale tym poleceniem sudo udevadm control --reload-rules && sudo service udev restart && sudo udevadm trigger

I potem wchodzę do folderu gdzie mam ten plik main.bin, i w terminalu wklepuję st-flash write main.bin 0x08000000 i po 3h mordowania się z tym i usunięciu gcc, g++, javy itd bo sobie jak leci wkleiłem bez sprawdzania to sudo apt-get remove gcc-arm-none-eabi binutils z innego tutoriala o tym jak zainstalować arm-none-eabi na ubuntu http://marksolters.com/progra[...]6/22/arm-toolchain-16-04.html ech, masakra.

Ale teraz jak dam st-flash write main.bin 0x08000000 to niby się coś wgrało. Podpiąłem spacjalnie pod USB 2.0 a nie do 1.0. Ale nie widzę efektów, chyba za mały delay do migania tą diodą. Ale coś niby wgrało bo mam takie komunikaty

[email protected]:~/Documents/Nucleo$ st-flash write main.bin 0x08000000
st-flash 1.5.1-31-g625f4cd
2019-07-15T11:16:16 INFO common.c: Loading device parameters....
2019-07-15T11:16:16 INFO common.c: Device connected is: F0 small device, id 0x10006444
2019-07-15T11:16:16 INFO common.c: SRAM size: 0x1000 bytes (4 KiB), Flash: 0x8000 bytes (32 KiB) in pages of 1024 bytes
2019-07-15T11:16:16 INFO common.c: Attempting to write 3008 (0xbc0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000800 erased
2019-07-15T11:16:16 INFO common.c: Finished erasing 3 pages of 1024 (0x400) bytes
2019-07-15T11:16:16 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-07-15T11:16:16 INFO flash_loader.c: Successfully loaded flash loader in sram
  3/3 pages written
2019-07-15T11:16:17 INFO common.c: Starting verification of write complete
2019-07-15T11:16:17 INFO common.c: Flash written and verified! jolly good!

No nic, trudno, jakoś to będę musiał ogarnać chyba sam póki co...

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 0, botów: 1

Robot: CCBot