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

1

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/tools-and-software/open-source-software/developer-tools/gnu-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

2

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

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

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 :)

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ę. ;)

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.

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/08/23/bare-metal-stm32-programming-part-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/min_freertos_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/min_freertos_blink/blob/master/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...

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.

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.

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/question/0D50X00009XkfH6SAJ/relocation-truncated-to-fit-rarmthmjump11

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/pyVision/software%20installation/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/programming/2016/06/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

xxxx@xxxx:~/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...

0

Weź Ty sobie człowieku klasykę polskiego internetu którą każdy zna i wie jak z nią sobie radzić a nie wymyślasz :P
http://www.freddiechopin.info/

0
alagner napisał(a):

Weź Ty sobie człowieku klasykę polskiego internetu którą każdy zna i wie jak z nią sobie radzić a nie wymyślasz :P
http://www.freddiechopin.info/

Dzięki za link. Jest przygotowany kod pod NUCLEO-F042K6 które parametrami jest prawie identyczne z F031K6 ale ma 6 kb ramu, a to co ja mam ma 4 kb ramu. Ale może aż tyle nie jest potrzebne żeby to uruchomić. I jest jakiś system plików a takiego czegoś szukałem. Więc ciekawe ;) Dzięki.

0

Jak liczysz, że bez skryptu linkera gdzieś daleko zajedziesz to źle liczysz ;)

0

Co jest nie tak w tym kodzie że GDB zamiast skoczyć do linii

SUBS	R2, #1 

zatrzymuje się na

Program received signal SIGINT, Interrupt.
_start () at demo2.S:30
30      LDR             R0, =RCC

Moja modyfikacja wygląda tak. Ogólnie chodzi o to że mam podpiętą diodę led na płytce stykowej. Z pinu GND na nucleo mam podpięte do minus na płytce stykowej, a zasilanie idzie z PA6, i program ma migać diodą tylko zamiast tą wbudowaną na płytce pod PB3 która jest opisana przez Rafała Kozika to sobie zacząłem eksperymentować na płytce stykowej. Tylko co jest tutaj nie tak. Jakieś przerwania mam jeszcze obsługiwać? Nie bardzo wiem dlaczego po wgraniu tego programu potem nie mogę już nic na nią wgrać bo ją po prostu odcina i openOCD nie mogę się połączyć z nią. A st-info na ubuntu w ogóle nie wykrywa sram, chipid, itd. Po prostu ją odcina, bo widać po debugerze że coś jest nie tak. Normalnie ten kod Rafała skacze do linii 41 do instrukcji SUBS R2, #1 i mogę to zatrzymać, potem kontynuować a tutaj w mojej modyfikacji jest halt płytki i koniec. Dopiero wgranie czystego programu przez System Workbench for STM32 która ma tylko bliblioteke .h dla tej płytki i pustą funkcje main resetuje coś, że mogę znowu połączyć się openOCD albo st-flash write wgrać program. Ale coś jest chyba nie tak w tym moim kodzie. Mimo wszystko działa, dioda miga tak jak zaprogramowałem, tylko potem już nie mogę przeprogramować tą samą drogą, tylko dopiero czyszczenie przez Sstem Workbench for STM32... ech.

/*-
 * SPDX-License-Identifier: BSD-3-Clause
 *
 * Copyright (c) 2018 Rafal Kozik
 * All rights reserved.
 */

.syntax unified
.thumb
.cpu cortex-m0

/* Vector table */
.long	0
.long	_start + 1

.set	RCC, 0x40021000
.set	RCC_AHBENR, 0x14
.set	IOPAEN, (1<<17)

.set	PORTA, 0x48000000
.set	GPIOx_MODER, 0x00
.set	GPIOx_ODR, 0x14
.set	GPIOx_MODER_OUT, 0x01

.set	LED, 0x06
.set	WAIT, 500000

/* Main program */
_start:
LDR		R0, =RCC
LDR		R1, =IOPAEN
STR		R1, [R0, #RCC_AHBENR]

LDR		R0, =PORTA
LDR		R1, =(GPIOx_MODER_OUT << (LED * 2))
STR		R1, [R0, #GPIOx_MODER]

init_loop:
LDR		R2, =WAIT
loop:
SUBS	R2, #1
BNE		loop
MVNS	R3, R3
STR		R3, [R0, #GPIOx_ODR]
B		init_loop

.global _start

Tutaj jest oryginalny kod i to co wywala mi w GDB

nulsadlasjfkajfklajsflkasf.png

0
goose_ napisał(a):

Co jest nie tak w tym kodzie że GDB zamiast skoczyć do linii

SUBS	R2, #1 

zatrzymuje się na

Program received signal SIGINT, Interrupt.
_start () at demo2.S:30
30      LDR             R0, =RCC

Wygląda na to, że masz gdzieś breakpointa wstawionego na _start w gdb. Może masz go w pliku ~/.gdbinit czy jak go tam nazwali w nomenklaturze Windows.
Polecenie "i break" w gdb prawdę ci powie w tej materii.

Moja modyfikacja wygląda tak. Ogólnie chodzi o to że mam podpiętą diodę led na płytce stykowej. Z pinu GND na nucleo mam podpięte do minus na płytce stykowej, a zasilanie idzie z PA6, i program ma migać diodą tylko zamiast tą wbudowaną na płytce pod PB3 która jest opisana przez Rafała Kozika to sobie zacząłem eksperymentować na płytce stykowej. Tylko co jest tutaj nie tak. Jakieś przerwania mam jeszcze obsługiwać? Nie bardzo wiem dlaczego po wgraniu tego programu potem nie mogę już nic na nią wgrać bo ją po prostu odcina i openOCD nie mogę się połączyć z nią. A st-info na ubuntu w ogóle nie wykrywa sram, chipid, itd. Po prostu ją odcina, bo widać po debugerze że coś jest nie tak. Normalnie ten kod Rafała skacze do linii 41 do instrukcji SUBS R2, #1 i mogę to zatrzymać, potem kontynuować a tutaj w mojej modyfikacji jest halt płytki i koniec. Dopiero wgranie czystego programu przez System Workbench for STM32 która ma tylko bliblioteke .h dla tej płytki i pustą funkcje main resetuje coś, że mogę znowu połączyć się openOCD albo st-flash write wgrać program. Ale coś jest chyba nie tak w tym moim kodzie. Mimo wszystko działa, dioda miga tak jak zaprogramowałem, tylko potem już nie mogę przeprogramować tą samą drogą, tylko dopiero czyszczenie przez Sstem Workbench for STM32... ech.

Ogólnie to jeśli zmieniasz pin GPIO, do którego podpinasz diodkę to musisz przekonfigurować to GPIO na wyjście, wybrać pullup/pulldown albo push-pull, czasami trzeba enablować zegar dla tego portu GPIO (zależnie od MCU), wyprowadzić go z resetu, etc. Trochę elektroniki trzeba znać tutaj w embedded.

Dodatkowo chciałbym ostrzec, żeby uważać z eksperymentowaniem, szczególnie ze skryptem linkera - bo jeśli wpiszesz sobie jakieś śmieci w nieodpowiedni obszar flasha to może to byc ostatni zapis jakikolwiek, bo zablokujesz MCU. Ale to tylko tak piszę ku przestrodze, nie żeby cię zniechęcać. Po prostu trzeba znać mapę pamięci zanim cokolwiek będziesz eksperymentować.

0
vtx napisał(a):

Dodatkowo chciałbym ostrzec, żeby uważać z eksperymentowaniem, szczególnie ze skryptem linkera - bo jeśli wpiszesz sobie jakieś śmieci w nieodpowiedni obszar flasha to może to byc ostatni zapis jakikolwiek, bo zablokujesz MCU. Ale to tylko tak piszę ku przestrodze, nie żeby cię zniechęcać. Po prostu trzeba znać mapę pamięci zanim cokolwiek będziesz eksperymentować.

Właśnie nie wiem czy czegoś nie spartoliłem, bo przeszedłem na st-link pod Ubuntu i wgrywałem pliki bin, wcześniej z używałem openOCD i listingów z programistymag do wgrywania plików elf. st-flash tylko ładuje pliki binarne i jak wpisałem coś takiego to zaczęły się problemy. Ale taki adres pokazywało mi w st-info --flash.

st-flash write led.bin 0x8000 // dałem chyba zły adres do pamięci bo powinno być 0x8000000

Ten kod jest praktycznie taki sam jak z przykładów Rafała, tyle że dałem inne porty ale dioda miga na płytce stykowej. Jak wgrywam jego kod to wszystko jest ok, potem wgrywam swój to mi wywala właśnie w tym miejscu. Nie wiem...

0
goose_ napisał(a):
vtx napisał(a):

Dodatkowo chciałbym ostrzec, żeby uważać z eksperymentowaniem, szczególnie ze skryptem linkera - bo jeśli wpiszesz sobie jakieś śmieci w nieodpowiedni obszar flasha to może to byc ostatni zapis jakikolwiek, bo zablokujesz MCU. Ale to tylko tak piszę ku przestrodze, nie żeby cię zniechęcać. Po prostu trzeba znać mapę pamięci zanim cokolwiek będziesz eksperymentować.

Właśnie nie wiem czy czegoś nie spartoliłem, bo przeszedłem na st-link pod Ubuntu i wgrywałem pliki bin, wcześniej z używałem openOCD i listingów z programistymag do wgrywania plików elf. st-flash tylko ładuje pliki binarne i jak wpisałem coś takiego to zaczęły się problemy. Ale taki adres pokazywało mi w st-info --flash.

st-flash write led.bin 0x8000 // dałem chyba zły adres do pamięci bo powinno być 0x8000000

Ten kod jest praktycznie taki sam jak z przykładów Rafała, tyle że dałem inne porty ale dioda miga na płytce stykowej. Jak wgrywam jego kod to wszystko jest ok, potem wgrywam swój to mi wywala właśnie w tym miejscu. Nie wiem...

Ja używam openocd+gdb do flashowania STM-a i nie podaję adresu wpalania - dzięki temu trudniej zrobić coś nie tak. Wszystkie odpowiednie adresy są w pliku .elf a gdb robi resztę. Co do adresu - to faktycznie 0x8000 jest złym adresem.

0

To jeszcze narysuj schemat jak tę diodkę wpinasz, bo może puszczasz tam jakiś za duży prąd i coś fizycznie nawala (wątpię, ale też tak bywa).
Prosto to sprawdzić: odepnij zewnętrzną diodę.

0
alagner napisał(a):

To jeszcze narysuj schemat jak tę diodkę wpinasz, bo może puszczasz tam jakiś za duży prąd i coś fizycznie nawala (wątpię, ale też tak bywa).
Prosto to sprawdzić: odepnij zewnętrzną diodę.

Nie mam dobrego aparatu teraz, tak to wygląda . Sprawdzałem miernikiem napięcia, jest przed rezystorem 3,3v, za rezystorem na diodzie 1,8v. Raczej prąd jest ok. Tylko wcześniej miałem jeszcze ten zielony kabel wpięty do + na płytce stykowej z pinu 3v3, ale to tylko daje napięcie do płytki, nie robi żadnego problemu raczej.

Bez tyssssstułu.png

0

ok. A co się dzieje w gdb jak odepniesz diodę i puścisz ten kod bez podpięcia do niczego?

0

Wgranie tego kończy się failem. Wywala mnie z gdb i nie może połączyć się ponownie przez openocd. Ale dioda miga. Tylko już nie mogę połączyć się przez openocd, dopiero wgranie czyste programu przez System Workbench for STM32 resetuje coś i mogę znowu się połączyć przez openocd i gdb...

#include "stm32f0xx.h"

int main() {}

program fail.png

0

Spróbuj podłączyć się z wciśniętym resetem.

0
alagner napisał(a):

Spróbuj podłączyć się z wciśniętym resetem.

Połączyło :) ale jak puszę reset to znowu ...

Error: jtag status contains invalid mode value - communication failure
Polling target stm32f0x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f0x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 300ms
Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f0x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 700ms
Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f0x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 1500ms
Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure

Ale jak mam wciśnięty reset to się łączy przez openocd

0

Jak wgrałeś soft pod ten zły adres nie zmieniłeś na trwałe ustawień pinów swd/jtag?
EDIT: i spróbuj spod linuxa. Ale jak musisz spod Win...
openocd
arm-none-eabi-gdb plik.elf
Podłączasz się z wciśniętym resetem.
W gdb coś w tym stylu potem:
monitor reset halt
load

EDIT2:
mogłem kolejność pomylić, piszę z pamięci.
Ale ogólnie idea jest taka, że puszczasz knefel reset po tym jak load zakończy się sukcesem.

0
alagner napisał(a):

ok. A co się dzieje w gdb jak odepniesz diodę i puścisz ten kod bez podpięcia do niczego?

Najpierw poprzedni post. Wyjęcie diody nic nie zmienia.

alagner napisał(a):

Jak wgrałeś soft pod ten zły adres nie zmieniłeś na trwałe ustawień pinów swd/jtag?
EDIT: i spróbuj spod linuxa. Ale jak musisz spod Win...
openocd
arm-none-eabi-gdb plik.elf
Podłączasz się z wciśniętym resetem.
W gdb coś w tym stylu potem:
monitor reset halt
load

EDIT2:
mogłem kolejność pomylić, piszę z pamięci.
Ale ogólnie idea jest taka, że puszczasz knefel reset po tym jak load zakończy się sukcesem.

Trzymam reset, łącze się z opencocd, jest połączenie, ale jak wchodzę w arm-none-eabi-gdb i próbuję się połączyć wpisując w gdb target remote :3333 to wywala że komputer docelowy aktywnie go odmawia. A w openocd to co zaznaczylem w czerwonej ramce, potem puszczam reset i dalej leci listing z błędem jtag.

sad214125125125125125.png

monitor reset halt coś tam ładuje ale potem dalej to samo... bo nie połączy się z wciśniętym resetem przez target remote :3333 w gdb

h2ih12o5h12oh51o25125.png

Będę musiał się jeszcze temu lepiej przyjrzeć na spokojnie.

0

Jak go aktywnie odmawia to możesz równie dobrze mieć coś pomotlane z firewallem.
Spróbuj w OOCD inny port ustawić? Podłącz się putty do localhost:4444 i patrz co samo openocd tam pluje?
Spróbuj target remote localhost:3333 zamiast pustego hostname'a?

0

Ok, chyba do czegoś doszedłem... Jeszcze raz pomierzyłem napięcia przed i za diodą itd. Potem spojrzałem jeszcze raz do datasheet RM0091Reference manual https://www.st.com/content/ccc/resource/technical/document/reference_manual/c2/f8/8a/f2/18/e6/43/96/DM00031936.pdf/files/DM00031936.pdf/jcr:content/translations/en.DM00031936.pdf . Okazuje się że port A ma jeszcze dodatkowy adres resetu, reszta portów tego nie ma. Więc ustawiłem znowu na port B, tylko inny pin, akurat dałem 6 pin jako wyjście do leda (ten sam kod co Rafała tylko pin 6 zamiast 3, reszta bez zmian). I jest :) Nie wywala mi z gdb, mogę się potem połączyć do openocd.

O tym resecie portu A jest w seckcji 8.4.1 GPIO port mode register (GPIOx_MODER) (x =A..F)
Reset values: • 0x2800 0000 for port A • 0x0000 0000 for other ports

Więc pewnie tutaj jakiś bubel zrobiłem że nie dałem tego resetu tylko jeszcze nie ogarniam o co chodzi z tym resetem. Ale na porcie B nie mam takich problemów.
Już jest OK :]

0

To by wiele tłumaczyło. Na porcie A masz chyba SWD/JTAG. Spróuj moder inicjować tak, żeby zostawić najstarsze bity nieruszone; możliwe że po prostu piny debugowe wyłączasz.

0
alagner napisał(a):

To by wiele tłumaczyło. Na porcie A masz chyba SWD/JTAG. Spróuj moder inicjować tak, żeby zostawić najstarsze bity nieruszone; możliwe że po prostu piny debugowe wyłączasz.

Ok, ale na razie... to tylko trochę GPIO i UART rozkminiłem. Dopiero przede mną jest ADC, DCA, I2C, SPI, DMA, NVIC i różne konfiguracje tego. Akurat chyba ten port A i te 8 pinów PA0 - PA7 to właśnie dla ADC jest. Dałem schemat na poprzedniej stronie. Pewnie za niedługo jak będę próbował robić coś bardziej konkretnego niż miganie diodą to dojdę do tego.

*btw. Kupiłem sobie jeszcze mały zestawik z Arduino Uno z tym wszystkimi przyciskami, wyświetlaczem itd za 60 zeta. Na razie to muszę ogarnąć podstawowe tutoriale o tym np kurs stm32 na forbot. Żeby to wszystko co tam jest uruchomić na tej płytce Nucleo. Poza tym mam ciekawe moduły 4 x ublox TOBY L210 (LTE/HSPA+/GSM module for Europe/Asia; Cat 4; B1, B3, B5, B7, B8, B20) i kilka mikrokontrolerów TMS320F28033PAGO, 1 x STM32f446 (Cortex-M4) i jakieś inne małe chipy ST, SMSC np do USB2.0, jeszcze jakieś cFeon itp . Więc w planie jest też zabawa z tym. Póki co ledwo ogarniam jak sterować GPIO na tym nucleo... Może za jakiś czas uda się osiągnąć ten cel czyli zrobić jakiś mały RTOS i ciekawy projekt z tego ;p I jeszcze raspberry pi chce się pobawić. Na początek wystarczy ten raspberry pi zero za 30 zeta, ta najtańsza wersja. Więc za kilka miesięcy powinienem lepiej ogarniać temat. *

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