Przykładowe projekty dla ARMów

Question

Na swojej stronie ( www.freddiechopin.info ) w dziale Download > ARM > Przykłady umieszczone zostały dwa przykładowe projekty pod Eclipse - jeden dla ...

Freddie Chopin · Answer

Przykładowe projekty dla procesorów NXP LPC2103 i ST STM32F103RB umieszczone na mojej stronie w dziale Download > ARM > Przykłady, doczekały się nowej wersji. Zmiany wprowadzone do przykładów dotyczą głównie tych elementów, o istnieniu których łatwo zapomnieć - tablicy wektorów, skryptu linkera, pliku Makefile, pliku startup.Lista najważniejszych zmian:- wsparcie dla C++ w skrypcie linkera, pliku Makefile i pliku startup (włączane w pliku Makefile zmienną USES_CPP),- zmiana w pliku Makefile i / lub w skrypcie linkera powoduje ponowną kompilację źródeł i / lub linkowanie obiektów,- tablica wektorów i funkcja __Default_Handler() w C, a nie w assemblerze,- zmiana skrótu do OpenOCD na odpowiedni dla aktualnej wersji 0.2.0,- pomniejsze zmiany w nazwach, formatowaniu, itp.,- (LPC2103) skróty do GDB zawierają opcje, dzięki którym debuggowanie jest bardziej niezawodne,- (STM32) pliki nagłówkowe zawarte w folderze inc/ pochodzą z stm32f10x_stdperiph_lib v.3.1.0 (najnowsza wersja).Wyjaśnienia może wymagać kwestia zwiększenia niezawodności debuggowania LPC2103. Sprawa jest skomplikowana, więc przedstawię ideę jedynie w skrócie. Ze względu na mechanizmy zastosowane przez producenta układów z serii LPC2xxx procesor rozpoczynający sesję debuggowania wykonał już pewną część wgranego kodu. Nie jest możliwe pełne zresetowanie układu i natychmiastowe zatrzymanie rdzenia. Jeśli w kodzie włączany jest MAM lub PLL, to na początku sesji debuggowania na 99% będą one już włączone (rdzeń zdążył już wykonać kod odpowiedzialny za uruchomienie tych peryferiów). Z tego względu podczas debuggowania mogą występować nieoczekiwane i bezsensowne błędy, a procesor może zachowywać się w sposób nieprzewidywalny. Skróty do GDB, które zawarte są obecnie w przykładach, za pomocą komend OpenOCD wyłączają zarówno MAM jak i PLL przed rozpoczęciem sesji (co oczywiście nie wyklucza możliwości ponownego ich włączenia w kodzie), dzięki czemu problemy te nie powinny występować.4\/3!!

Anonymous · Answer

Mogę wiedzieć skąd wziąłeś te liczby:?Chciałem to przerobić dla LPC2478 bo może przez to nie działają mi przerwania, ale najpierw chciałem się upewnić że wiem o co chodzi i sprawdziłem czy te adresy zgadzają się z tym co pisze w nocie katalogowej LPC210x.No i niestety trochę zwątpiłem, bo tam jest tak:Jeszcze obstawiałem na to że adresy są przesunięte do RAMu, ale tez nie, bo RAM jest od 0x40000000.Chyba jeszcze czegoś brakuje mi w startupie do uruchomienia przerwań, ale to zostawiam na później.Z góry dziękuję za pomoc.

Freddie Chopin · Answer

To nie są adresy, tylko skompilowana postać instrukcji assemblerowych z tabelki powyżej. To jedyny sposób (który znam), aby zrobić dla ARM7 tabelę wektorów w C.

Przerwania nie działają Ci z dwóch powodów:

1. W skrypcie linkera standardowo ustawione są zerowe rozmiary stosu dla innych trybów niż User

2. W LPC2478 adres rejestru VicVectAddr jest inny niż dla LPC2103. W LPC2103 jest to 0xFFFF F030, w LPC2478 - 0xFFFF FF00.

Aby rozwiązać sprawę z punktu 2. musisz podstawić za instrukcję "ldr pc, [pc, #-0xFF0]" postawić odpowiednik dla LPC2478 - "ldr pc, [pc, #-0x120]". Innymi słowy - zastąp "0xe51ffff0" wartością "e51ff120". Jeśli chcesz sam to sprawdzić to wpisz sobie gdzieś w main:

asm volatile ("ldr pc, [pc, #-0x120]");

Swoją drogą chętnie poznam opinię na temat tak trickowej realizacji tablicy wektorów [;

4\/3!!

See also:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM

Anonymous · Answer

Ja pierniczę. Nawet przeszło mi to przez myśl, ale od razu to odrzuciłem bo nie sądziłem że ktoś inny niż ja jest w stanie coś takiego zrobić. A co dopiero Ty, zwolennik uniwersalności i ułatwiania sobie życia ;pPoza tym nie sądziłem że liczba 4-ro bajtowa zmieści się w 4-ro bajtowym rozkazie ;p Ale teraz się domyślam że jest tam tylko młodsza połówka albo coś jeszcze krótszego.Tylko nie rozumiem dlaczego 5 pierwszych wektorów jest takich samych. Chyba powinny być inne. No chyba że po prostu nie ma dedykowanej obsługi tych wektorów i dlatego są przekierowane do jednego miejsca.No i dopiero się zczaiłem że te adresy podane w nocie katalogowej to są adresy umieszczenia wektorów, a nie adresy wektorów ;pNie nie. To już dawno zmieniłem.Ten VicVectAddr to ten uniwersalny rejestr do którego trzeba wpisać dowolną wartość podczas wychodzenia przerwania? Nie wiedziałem że on jeszcze do czegoś służy. No to zaraz sprawdzę.A jak wyliczyłeś te liczby? Bo nie widzę związku pomiędzy 0xFFFFF030 a -0x0FF0 i pomiędzy 0xFFFFFF00 a -0x0120. Ani to przesunięcie (bo różne w obydwu przypadkach) ani zapis liczby ujemnej (bo też się nie zgadza).No na moje oko trochę naciągany ten sposób. Czy ma to jakieś specjalne zalety poza małą wadą że jest trochę ciężej zedytować adres?A nie dało się jakoś umieścić stałych w pamięci programu pod określonym adresem?Przy okazji: zawsze jak się ktoś o to pyta to słyszy odpowiedz że to podstawa C i jak ktoś tego nie wie to powinien się podszkolić a nie pytać o to na forum. No ale podszkalam się i podszkalam a nadal tego nie wiem. Mianowicie jak umieścić tablice stałych w pamięci programu? Najlepiej pod określonym adresem. Oczywiście stałe mają być w określonej kolejności. Na przykład jakaś tablica RGB, czyli jakiś obrazek.

Freddie Chopin · Answer

Po pierwsze - WSZYSTKO jest w komentarzu powyżej tej tabeli, tam jest podana postać assemblerowa - jak sobie ją skompilujesz, to otrzymasz DOKŁADNIE taki sam efekt.Ułatwiłem sobie życie, bo plik jest w C <: Pozatym dla Cortex-M3 już jest to normalnie, bez takich cudów - jedynie ARMv4 wymaga takich akrobacji.Tam jest tylko offset, bo zastosowane jest adresowanie pośrednie z offsetem.Takie same są rozkazy "załaduj do PC adres znajdujący się X bajtów dalej. Logicznym jest, że rozkaz taki umieszczony pod adresem 0 załaduje wartość znajdującą się pod 0 + X, natomiast rozkaz pod adresem 4 załaduje do PC adres z komórki 4 + X. Wszystko jest w najlepszym porządku.W architekturze ARMv4 w zasadzie nie są to typowe "wektory", czyli adres funkcji obsługi, tylko są to rozkazy które wykona rdzeń po wystapieniu wyjątku.Wszystko jest w datasheecie...To jest przesunięcie względem aktualnej wartości PC (z tym że lekko większej, bo pipeline):0xFFFFFF00 + 0x0120 = 0x200xFFFFF030 + 0x0FF0 = 0x20Podstawowe pytanie brzmi - po co edytować adres? Ta tabela nie wymaga żadnych zmian, nigdy i pod żadnym pozorem... Jeśli chcesz obsłużyć przerwanie, to po prostu piszesz w kodzie funkcję o odpowiedniej nazwie - np:void Data_Abort_Handler(void) __attribute__ ((interrupt("ABORT")));void Data_Abort_Handler(void){...}Są umieszczone w pamięci pod określonym adresem.Nie wiem jakie ma zastosowanie ustawienie danych pod konkretnym adresem. Ustawienie ich "po prostu" w pamięci programu jest za pomocą "const" - to chyba oczywiste.Ustawienie pod konkretnym adresem jest bardziej skomplikowane, ale z grubsza podobne do metody jaka zastosowana jest dla tablicy wektorów.4\/3!!

Anonymous · Answer

Acha. Czyli po to są później podane te elementy:Code: text Expand Select all Copy to clipboard
		Reset_Handler
		Undefined_Handler
		SWI_Handler
		Prefetch_Abort_Handler
		Data_Abort_Handler
		FIQ_Handler
Chyba zaczynam rozumieć o co w tym chodzi. Dzięki.Co do edytowania adresu to myślałem że tam jest adres obsługi (i przy okazji dziwiłem sie że jest stały). Ale to tylko przekierowanie na (zmienny) adres umieszczony później więc oczywiście nic nie trzeba edytować.C samo w sobie nie jest jak dla mnie zaletą, ale niech będzie ;pUstawianie danych pod konkretnym adresem może ułatwić adresowanie. ale to jak sie pisze w assemblerze. na AVRach mocno przyspieszało działanie różnych wyżyłowanych algorytmów.A to z const to mnie zaskoczyłeś. Zwykle takie stałe (w Delphi czy BASCOMie) nie są nigdzie umieszczane, lecz sobie po prostu są w kodzie źródłowym. A do pamięci programu trafiają w rozkazy assemblera a nie bezpośrednio jako bajt w pamięć programu.Np:Code: text Expand Select all Copy to clipboard
const a = 10;
If a < b Then
…
A mi chodziło o coś takiego raczej:Code: text Expand Select all Copy to clipboard
db 10;
…
Ale jeżeli w C const załatwia te dwie rzeczy na raz to tym lepiej ;p

Freddie Chopin · Answer

W C może być dokładnie tak samo, bo dla podanego przez ciebie przykładu umieszczanie danych w pamięci, a nie bezpośrednio w rozkazie, nie ma najmniejszego sensu z punktu widzenia optymalizacji - używasz jedynie wartości, więc użycie tej wartości, a nie konkretnej komórki pamięci (którą trzeba adresować, odczytywać itp.), jest szybsze, mniejsze i wygodniejsze.Jeśli wg kompilatora będzie potrzeba wstawienia zmiennej fizycznie w pamięć (gdy np gdzieś używasz ich adresu, albo odwołanie znajduje się w innej jednostce kompilacji niż definicja), to kompilator zrobi to co trzeba...4\/3!!

Anonymous · Answer

No mam nadzieję że umieści. Bo ja najprędzej nigdzie w kodzie nie użyję tego tak normalnie.
Jedynie pobiorę adres takiej tablicy i będę ją kopiował do RAMu (a i to pewnie w assemblerze a nie wiem czy to może nie zmyli kompilatora).
Na szczęście nie zamierzam korzystać z jakiejkolwiek optymalizacji więc może kompilator się zlituje nademną i to umieści.

Freddie Chopin · Answer

Dobra, zrozumiałem swój błąd <:Może taka tablica wektorów - też jest w C <:Code: text Expand Select all Copy to clipboard
static void __vectors(void) __attribute__ ((used, naked, section(".vectors")));
static void __vectors(void)
{
	asm volatile(
		" ldr	pc, Reset_Vector			
"	// "Reset" vector
		" ldr	pc, Undefined_Vector		
"	// "Undefined instruction" vector
		" ldr	pc, SWI_Vector				
"	// "Software interrupt (SWI)" vector
		" ldr	pc, Prefetch_Abort_Vector	
"	// "Prefetch Abort (instruction fetch memory abort)" vector
		" ldr	pc, Data_Abort_Vector		
"	// "Data Abort (data access memory abort)" vector
		"	.word 	0						
"	// Reserved vector (code signature)
		" ldr	pc, [pc, #-0xFF0]			
"	// "IRQ" vector
		" ldr	pc, FIQ_Vector				
"	// "FIQ (fast interrupt)" vector

		" Reset_Vector:						"
		"	.word	Reset_Handler			
"	// Reset
		" Undefined_Vector:					"
		"	.word	Undefined_Handler		
"	// Undefined instruction
		" SWI_Vector:						"
		"	.word	SWI_Handler				
"	// Software interrupt (SWI)
		" Prefetch_Abort_Vector:			"
		"	.word	Prefetch_Abort_Handler	
"	// Prefetch Abort (instruction fetch memory abort)
		" Data_Abort_Vector:				"
		"	.word	Data_Abort_Handler		
"	// Data Abort (data access memory abort)
		" FIQ_Vector:						"
		"	.word	FIQ_Handler				
"	// FIQ (fast interrupt)
	);
}
Wszystko widać, łatwo zmienić, żadnych kosmosów, działa na każdym poziomie optymalizacji itp.__________________________________Zaktualizowaną wersję przykładu dla LPC2103 wrzuciłem na stronę. Zmieniłem tablicę wektorów na taką jak widać wyżej, dodałem komentarz z wektorem IRQ dla dwóch różnych typów LPC (nowych i starych), oraz drobne kosmetyczne poprawki w funkcji __Default_Handler(), która obecnie jest z atrybutem "noreturn".4/3!!

Anonymous · Answer

A, o to Ci chodziło. O to żeby plik miał rozszerzenie „c” a nie „s”. NO to w takim razie to już ma sens, bo słyszałem że z plikami „s” czasami są problemy w C. A może to chodziło o pliki „asm”?

Zmiana tego jednego adresu (rejestru VicVectAddr) rozwiązała problem przerwań. Wielkie dzięki. Jak byś pomagał dla punktów to być Ci chyba przekazał wszystkie ;p
Miałem pewne problemy, nawet duże, ale na szczęście pojawiły się po poprzednim uruchomieniu przerwań czyli przynajmniej miałem pewność że przerwania już wiem jak uruchomić. A winne było jak zwykle PLL. Nie wiem co jest nie tak. Znowu nie działa. Procesor się zatrzymuje na pętli oczekującej na załapanie PLL. To znaczy raczej nie tyle się zatrzymuje, co chodzi dalej, ale PLL nie załapuje.

Freddie Chopin: piszesz trochę w assemblerze ARM? To znaczy tak więcej, bo jakieś tam małe ilości to na pewno, bo masz to choćby w startupie. Chodzi mi na przykład o jakieś algorytmy do obróbki obrazu (od razu mówię że nie chcę gotowców ;p).

Freddie Chopin · Answer

używasz skrótów do GDB które są w najnowszym przykładzie? Komendy do OpenOCD wyłączają profilaktycznie PLL i MAM po resecie. Bez tego miałem dokładnie taki sam problem jak opisujesz (oraz kilka innych, jeszcze bardziej kosmicznych).

Assemblera znam niezbyt wiele, zwykle nie ma się po co go uczyć, bo nikłe szanse abyś był lepszy niż kompilator w 99% przypadków. Im bardziej procesor skomplikowany, tym kompilator lepszy (bo potrafi uwzględnić czynniki, o których nawet nie śniło się zwykłym ludziom).

4\/3!!

See also:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM

Anonymous · Answer

Nie. Wciąż jadę na starych przykładach i zmieniłem w nich tylko ten adres.
Dodatkowo kilkanaście razy przekompilowywałem kod i wgrywałem go do procesora i działał. Po którymś przeprogramowaniu raptem przestał. I teraz jak już wiem o co chodzi to jadę na kodzie bez PLL.

Po za tym to zawsze muszę dwa razy przeprogramować. Po pierwszym przeprogramowaniu procesor nie wstaje (tzn. nie uruchamia programu - programowanie działa). Odłączam kabel od programatora, zwieram VCC do GND na kilka sekund żeby mieć pewność że procesor się zresetuje (oczywiście po wcześniejszym odłączeniu zasilania). Nie, muszę przeprogramować drugi raz (nawet mogę bez odłączania zasilania. Po prostu dwa razy i dopiero odłączyć zasilanie) i dopiero wstaje. I tak było jak jeszcze PLL działało i teraz jest tak samo.
Tak samo mam ze wszystkimi procesorami LPC2478. Zawsze kilkadziesiąt programowań przechodzi gładko, a później trzeba po dwa. A może po prostu programowanie nie idzie bezbłędnie i dlatego trzeba „poprawiać”? Tylko że przed każdym programowaniem jest kasowanie więc taka naprawa zawartości pamięci i tak by nic nie dała.

Co do assemblera. Trzeba strasznie znać się na C żeby napisać taki kod który potem zostanie mocno zoptymalizowany przez kompilator.
Mi chodzi na przykład o szybką konwersję RGB-->YCrCb.
Coś czuję że szybciej wyjdzie mi to w assemblerze.
Oczywiście będzie ciężko, bo w ARMach na czas wykonywania się programu wpływa też sekwencja rozkazów a nie osobne czasy wykonywania się każdego rozkazu. Gdzieś wyczytałem że na przykład rozkaz NOP może w ogóle nie zająć żadnego cyklu, bo zostanie wchłonięty pomiędzy jakieś dwie dłuższe instrukcje i zginie gdzieś w środku potoku.
Ale specjalnie na assemblera się nie porywam. Jak na razie faktycznie w C pisze się mi dość wygodnie. Ma problemy ze zrozumieniem pewnych rzeczy (szczególnie jak analizuje nie swój kod), ale jeszcze nie trafiłem na coś czego nie można zrobić. A w innych językach to owszem. A jeszcze jak stopień optymalizacji faktycznie będzie taki wysoki to już na pewno assemblerem się nie zajmę ;p

Freddie Chopin · Answer

Brzmi kosmicznie, więc może to być efekt MAM albo PLL - spróbuj skrótów do GDB z najnowszej wersji przykładów - powinno pomóc, jeśli nie całkiem, to choć częściowo. Jednym z efektów tych "cudów" było to, że procek pracuje źle, tak jakby wykonywał jakieś złe rozkazy, więc znów brzmi jak Twój opis. Z PLL nie warto rezygnować, tak samo z MAM, ale warto po resecie upewnić się, że faktycznie są wyłączone [;Nie jest tak źle - wbrew pozorom jak starasz się optymalizować kod w C na siłę, to potem:a. nie wiadomo o co chodzi,b. kompilator nie potrafi tego zoptymalizować bardziej.Prosty i przejrzysty kod zwykle jest zoptymalizowany wystarczająco [;"Premature optimization is the root of all evil" - warto poczytać w necie o tej frazie, bo można spojrzeć na sprawę z innej perspektywy [;4\/3!!

Anonymous · Answer

Ta nowa wersja jest lepsza, ale przejście na C miałoby w/g mnie sens wtedy, gdybyś poszedł za ciosem i wyeliminował startup.s. Inaczej to sztuka dla sztuki.Albert

Freddie Chopin · Answer

Chyba nikt nie lubi skompilowanej postaci assemblera <: Niezły kosmos stworzyłem <: Dobrze że dla STM32 nie trzeba takich kombinacji...To jest w planie dla kolejnej wersji - 1.2.0 <;4\/3!!

markosik20 · Answer

No widzę że nie tylko ja tak mam .. Z braku czasu i trochę lenistwa nie drążyłem tematu i nie szukałem przyczyny takiego zachowania.

Freddie Chopin · Answer

No to spróbujcie skrótów do GDB które są w najnowszej wersji przykładu do LPC2103 - myślę, że powinny naprawdę pomóc choć trochę! Aktualnie nawet na liście OpenOCD ten temat jest "na tapecie", więc im więcej doświadczeń tym lepiej.

4\/3!!

Anonymous · Answer

No to zaraz spróbuję.
Niestety widzę na zagranicznych forach że nie tylko ja mam problemy z tym procesorem. Czyli potwierdza się moja teza że jednak jakieś błędy w krzemie procesor ma.

CO do podwójnego programowania to może chodzi o to że podczas pierwszego programowania PLL jest włączone i się nie do końca programuje?
Potem się zawiesza bo wykonuje jakieś krzaki.. Ale da się zaprogramować (już bez PLL bo procesor krzakami PLL nie uruchomi)i drugie programowanie działa.
Ale dlaczego taki efekt występuje każe gdy nie korzystam z PLL?

Z PLL nie tylko nie warto korzystać. ja nie mogę sobie na to pozwolić. Jak nie wyciągnę co najmniej 40...50MHz to nie mam po co zabierać się za tego ARMa.
Na razie jadę bez PLL, ale tylko dlatego że uruchamiam co się da. A na koniec i tak obowiązkowo będę chciał uruchomić PLL.

Dobra, to odezwę się za chwilę jak przetestuję nowe GDB.

Dodano po 26 [minuty]:

Nie wierzę! Działa!!! To znaczy jednokrotne programowanie. Podmieniłem tylko dwa pliki. Ten trzeci dla jtagkey nic mi nie dał bo u mnie już był taki od wigglera.

Markosik20: a Ty też jedziesz na LPC2478?

Freddie Chopin · Answer

Didn't I tell so? <:4\/3!!

Anonymous · Answer

I PLL też działa. Czyli częściowo cofam te słowa o błędach w krzemie ;pStrasznie dziwne to zachowanie procesora ale dobrze że w końcy działa.

markosik20 · Answer

Moje Eclipse + reszta załogi (LPC2364) chyba toporne jest .Pomysł z plikami .lunch do bezpośredniego wgrania u mnie nie funkcjonuje, więc musiałem "ręcznie" przeczytać tego xml.Mam nadzieje że o to chodziłoCode: text Expand Select all Copy to clipboardtarget remote localhost:3333
monitor reset
monitor soft_reset_halt
monitor mwb 0xE01FC040 0x01
monitor mwb 0xE01FC000 0
monitor mwb 0xE01FC080 0
monitor mwb 0xE01FC08C 0xAA
monitor mwb 0xE01FC08C 0x55
loadNiestety rdzeń się "wykłada":U siebie muszę zrobić Code: text Expand Select all Copy to clipboardmonitor reset halt żeby w ogóle mówić o programowaniu

Freddie Chopin · Answer

No i zgadza się, bo w pliku właśnie tak jest - bez soft_reset_halt. Zrobiłeś jakąś wariację na temat tych dwóch, a ich zawartość MUSI być różna.Do programowania powinno być tak:Code: text Expand Select all Copy to clipboard
monitor reset halt
monitor mwb 0xE01FC040 0x01
monitor mwb 0xE01FC000 0
monitor mwb 0xE01FC080 0
monitor mwb 0xE01FC08C 0xAA
monitor mwb 0xE01FC08C 0x55
load
Anyway - zasadnicze pytanie jest takie, czy tego typu uruchomienie programowania pomaga?P.S.podaje od razu wartość dla "debuggowania bez programowania":Code: text Expand Select all Copy to clipboard
monitor reset
monitor soft_reset_halt
monitor mwb 0xE01FC040 0x01
monitor mwb 0xE01FC000 0
monitor mwb 0xE01FC080 0
monitor mwb 0xE01FC08C 0xAA
monitor mwb 0xE01FC08C 0x55
4\/3!!

markosik20 · Answer

U mnie w zasadzie niestety nie.W przypadku LPC2144 wystarczyCode: text Expand Select all Copy to clipboardmonitor reset halt
load gdzie konfiguracja MAM, PLL itd. jest zrobiona w startup.s.W LPC2364 (gdzie PLL już jest w main.c) w sumie też działa.....ale muszę dwa razy to wykonać żeby "się dobrze wgrało" .______________________________________________________No i się wyjaśniło....w pliku .cfg przy odpalaniu OpenOCD zamiastCode: text Expand Select all Copy to clipboard
.....
.....lpc2000_v2 4000 calc_checksum
...trzeba było zmienić naCode: text Expand Select all Copy to clipboard
.....
.....lpc2000_v2 14765 calc_checksum
...Mała zmiana i problemy znikneły jak ręką odjął.

Freddie Chopin · Answer

1. U mnie samo "reset halt" i "load" w większości przypadków działało... do czasu gdy działać nagle przestało [; A kod różnił się jedynie tym, że main i Reset_Handler były 4 adresy dalej... Czasem działało, czasem nie, z wyłączaniem PLL i MAM przy rozpoczęciu sesji (na razie) działa zawsze.

2. Nie wiem czy zmiana którą zrobiłeś jest dobra - w końcu po resecie procesor działa na wewnętrznym oscylatorze 4MHz właśnie...

4\/3!!

See also:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM

markosik20 · Answer

Ważne że działa prawidłowo , wszak po resecie nie następuje automatyczne zerowanie wszystkiego i rdzeń sobie dalej hula na PLL....wykonywany jest tylko kod od początku.Sprawdziłem to wszystko z PLL i bez PLL....bez problemu się z targetem można łączyć.

Freddie Chopin · Answer

Powód jest inny. Podczas resetu wszystkie rejestry są zerowane. Tyle że jak chcesz debuggować, to JTAG resetuje procka, czeka chwile, zatrzymuje go i ustawia reejstr PC na 0 (software'owy reset). Do momentu zatrzymania rdzenia procek już włączył sobie PLL i MAM - stąd większość problemów.4\/3!!

markosik20 · Answer

Ale tylko te podstawowe r0->r14 ? Bo jeżeli tak to przecież rejestry od PLL są w przestrzeni peryferii więc PLL działa.

Freddie Chopin · Answer

Wszystkie rejestry peryferyjne przyjmują wartości opisane w datasheecie przez "reset value" - zwykle zero. Zarówno rejestry PLL jak i MAM mają jako "reset value" wpisane zero.Za przykład niech posłuży jakiś inny rejestr, choćby ADCR (rejestr ten NIE jest modyfikowany w kodzie wgranym do pamięci):Code: text Expand Select all Copy to clipboard
Open On-Chip Debugger
> reset run
JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ve
r: 0x4)
JTAG Tap/device matched
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: User
cpsr: 0x80000010 pc: 0x00000138
> mdw 0xE0034000 1
0xe0034000: 00000000
> mww 0xE0034000 0xFFFFFFFF
> mdw 0xE0034000 1
0xe0034000: 0fefffff
> reset halt
JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ve
r: 0x4)
JTAG Tap/device matched
srst pulls trst - can not reset into halted mode. Issuing halt after reset.
target state: halted
target halted in ARM state due to debug-request, current mode: User
cpsr: 0x80000010 pc: 0x0000012c
> mdw 0xE0034000 1
0xe0034000: 00000000
>
Domyślny stan PLLa i MAM po resecie to "wyłączony" - często są włączone z powodu opisanego w drugim poście (ostatni akapit), co powoduje problemy.4\/3!!

Anonymous · Answer

Polecam http://www.arm.com/documentation/books/4975.htmlZwłaszcza rozdział 5. Efficient C ProgrammingAlbert