| Author |
Message
|
atom1477
Poziom 25
Joined: 14 Jul 2005
Posts: 6596
|
 #31
 14 Mar 2010 14:43 Re: Funkcja w RAMie nie działa. Ręce opadają. |
|
|
|
Ok. Dzięki. Teraz idzie.
Ale teraz z kolei atrybut jest olewany. Rozumiem że optymalizacja.
Ale po pierwsze jest O0, a po drugi chyba po to jest atrybut żeby coś wymusić.
Nie po to podaje się całą linijkę atrybutów żeby kompilator i tak robił po swojemu i jeszcze warnigni wywalał.
Co ciekawe zużycie sekcji data wzrosło. Czyli wygląda to tak jak by jednak to trafiało do RAMu. No ale skąd w takim razie warning?
No i w pliku lss adresy wskazują że to jednak Flash.
Zedytowałem pliki na górze.
|
|
| Back to top |
|
 |
Freddie Chopin
Poziom 25
Joined: 12 Dec 2005
Posts: 7300
Location: Zawiercie
|
#32
14 Mar 2010 14:46 Re: Funkcja w RAMie nie działa. Ręce opadają. |
|
|
|
No dobra, ale jakie atrybuty masz olewane? U mnie funkcja jest w RAM, więc gdzie tu "olewactwo"? Popatrz dobrze na ten plik *.lss - wywoływana jest pewnie specjalna funkcja POŚREDNICZĄCA (z przyrostkiem _veneer) (w przypadku opcji bez "long_call") i dopiero ona wywołuje to co jest w RAM.
4\/3!!
|
|
| Back to top |
|
|
Google
|
| #
14 Mar 2010 14:46 |
|
|
|
|
|
| Back to top |
|
|
atom1477
Poziom 25
Joined: 14 Jul 2005
Posts: 6596
|
#33
14 Mar 2010 14:52 Re: Funkcja w RAMie nie działa. Ręce opadają. |
|
|
|
| Code: |
Warning: ignoring changed section attributes for .data
|
no więc na moje oko olewana jest zmiana sekcji.
Ale faktycznie funkcja zniknęła z pliku lss.
|
|
| Back to top |
|
|
Freddie Chopin
Poziom 25
Joined: 12 Dec 2005
Posts: 7300
Location: Zawiercie
|
#34
14 Mar 2010 15:11 Re: Funkcja w RAMie nie działa. Ręce opadają. |
|
|
|
Nie o to chodzi, że olewane są twoje atrybuty, tylko o to, że sekcja .data (zgodnie z nazwą) służy do zmiennych (odczyt, zapis), a nie funkcji (wykonywanie) i to kompilatorowi się nie podoba. Dlatego "właściwym" rozwiązaniem jest dodanie nowej sekcji (może być wewnątrz tego ogólnego .data) do skryptu linkera.
4\/3!!
|
|
| Back to top |
|
|
albertb
Poziom 22
Joined: 04 May 2004
Posts: 2073
Location: Nowy Targ
|
#35
14 Mar 2010 15:37 Re: Funkcja w RAMie nie działa. Ręce opadają. |
|
|
|
| Freddie Chopin wrote: |
Niemniej jednak, BEZ "long_call" funkcja też zostanie wywołana prawidłowo, przez tzw. veneer, więc problem nie leży tutaj.
|
Problem nie leży tutaj, tym niemniej u mnie na pliku testowym bez atrybutu long calls:
| Code: |
void ram(void) __attribute__ ((section(".data"))) ;
void ram(void)
{
FIO0DIR = 6;
}
int main()
{
ram();
return 0;
}
|
Mam:
| Code: |
gcc -c -Wall -O1 -fno-builtin-printf -mcpu=arm7tdmi -I. -I.. -ggdb -gdwarf-2 main.c -o main.o
/tmp/ccCk4g3r.s: Assembler messages:
/tmp/ccCk4g3r.s:10: Warning: ignoring changed section attributes for .data
gcc --gc-sections -nostartfiles --warn-common -T LPC2364.ld crt0.o main.o startup.o -o main.elf -Wl,-Map=main.map
main.o: In function `main':
main.c:11: relocation truncated to fit: R_ARM_PC24 against symbol `ram' defined in .data section in main.o
collect2: ld returned 1 exit status
|
Jeśli u Ciebie się skompiluje, czy mógłbyś podesłać wyniki?
No wtedy pytanie co jest właściwą reakcją kompilatora. ;-)
Albert
|
|
| Back to top |
|
|
Freddie Chopin
Poziom 25
Joined: 12 Dec 2005
Posts: 7300
Location: Zawiercie
|
#36
14 Mar 2010 16:08 Re: Funkcja w RAMie nie działa. Ręce opadają. |
|
|
|
Wkleiłem to co pokazałeś do mojego przykładu dla lpc2103 (wywaliłem całą zawartość pliku main.c), dorzuciłem stosownego #include dla rejestru i mam:
| Code: |
000000dc <main>:
{
FIO0DIR = 6;
}
int main(void)
{
dc: e92d4800 push {fp, lr}
e0: e28db004 add fp, sp, #4
ram();
e4: eb000005 bl 100 <__ram_veneer>
return 0;
e8: e3a03000 mov r3, #0
}
ec: e1a00003 mov r0, r3
f0: e24bd004 sub sp, fp, #4
f4: e8bd4800 pop {fp, lr}
f8: e12fff1e bx lr
fc: 00000000 andeq r0, r0, r0
00000100 <__ram_veneer>:
100: e51ff004 ldr pc, [pc, #-4] ; 104 <__ram_veneer+0x4>
104: 40000000 .word 0x40000000 |
| Code: |
[...]
Compiling file: main.c
arm-none-eabi-gcc -c -mcpu=arm7tdmi-s -O0 -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes -Wextra -g -ggdb3 -fverbose-asm -Wa,-ahlms=./out/main.lst -MD -MP -MF ./out/main.d -I . main.c -o out/main.o
C:\DOCUME~1\FREDDI~1\USTAWI~1\Temp\ccFqJrfV.s: Assembler messages:
C:\DOCUME~1\FREDDI~1\USTAWI~1\Temp\ccFqJrfV.s:1625: Warning: ignoring changed section attributes for .data
Linking target: lpc2103_blink_led.elf
arm-none-eabi-g++ -mcpu=arm7tdmi-s -Tlpc2103_rom.ld -g -Wl,-Map=./out/lpc2103_blink_led.map,--cref,--no-warn-mismatch -Wl,--gc-sections -nostartfiles ./out/startup.o ./out/vectors.o ./out/load.o ./out/main.o -o out/lpc2103_blink_led.elf
[...] |
Mam wrzucić coś więcej?
4\/3!!
|
|
| Back to top |
|
|
atom1477
Poziom 25
Joined: 14 Jul 2005
Posts: 6596
|
#37
14 Mar 2010 21:37 Re: Funkcja w RAMie nie działa. Ręce opadają. |
|
|
|
Sorki że dopiero teraz. Nie miałem internetu.
Dodałem sekcję fastrun.
I w końcu funkcja się pojawiła:
| Code: |
40000000: e52db004 push {fp} ; (str fp, [sp, #-4]!)
40000004: e28db000 add fp, sp, #0 ; 0x0
PLLFEED=PLLFEED_FIRST;
40000008: e3a0320e mov r3, #-536870912 ; 0xe0000000
4000000c: e283397f add r3, r3, #2080768 ; 0x1fc000
40000010: e283308c add r3, r3, #140 ; 0x8c
40000014: e3a020aa mov r2, #170 ; 0xaa
40000018: e5832000 str r2, [r3]
PLLFEED=PLLFEED_SECOND;
4000001c: e3a0320e mov r3, #-536870912 ; 0xe0000000
40000020: e283397f add r3, r3, #2080768 ; 0x1fc000
40000024: e283308c add r3, r3, #140 ; 0x8c
40000028: e3a02055 mov r2, #85 ; 0x55
4000002c: e5832000 str r2, [r3]
}
40000030: e28bd000 add sp, fp, #0 ; 0x0
40000034: e8bd0800 pop {fp}
40000038: e12fff1e bx lr
4000003c: e1a00000 nop (mov r0,r0)
|
:D
Ale dlaczego zużycie sekcji data spadło do zera (skoro sekcja fastrun jest zawarta w data)?
Po za tym to ten program z biblioteką FatFs też zaczął działać.
Problemem było:
Brak podwójnego podania atrybutu co mnie strasznie dziwi.
Brak dodatkowej sekcji fastrun.
Obie wersje próbowałem ale nigdy obydwie na raz i dlatego mi to nie działało.
Prawie już działa.
Dzięki wszystkim za pomoc.
Dodano po 4 [godziny] 39 [minuty]:
Ok. Już działa o wiele więcej (512000-64B są programowene) ale wciąż nie wszystko.
Zatrzymałem się na programowaniu pierwszych 64-rech bajtów.
| Freddie Chopin wrote: |
Kolejną ważną sprawą jest słynny w ARM7 nieużywany wektor przerwań, który służy do zabezpieczania przez wykonywaniem syfu. Jeśli nie znajdzie się tam poprawna wartość (szczegóły w manualu), to po resecie taki program nie będzie działać - po prostu bootloader (ten oryginalny) go nie uruchomi. Żaden kompilator nie generuje automatycznie tej wartości...
|
No ale właśnie. Kompilując kod otrzymuję BINa zawierającego również te pierwsze 64B kodu. Zresztą po zaprogramowaniu i ponownym odczytaniu programu odczytane pierwsze 64B są takie same jakie były te 64B którymi był procesor zapisywany. Czyli jednak kompilator wie co robi. Procesor nie przelicza tej sumy i nie przeprogramowuje fragmentu Flasha gdzie powinna ona się znaleźć. Albo może i przelicza, ale wartość która mu wychodzi jest taka sama jak ta wyliczona przez kompilator.
Po drugie. Kompilator to tworzy czy też nie, w każdym razie trzeba tą wartość skądś wsiąść i nią zaprogramować te 64B Flasha.
No i tutaj pojawia się problem bo funkcja kasująca nie kasuje pierwszych 64B Flasha. Tak jak zresztą pisze w manualu. A w zasadzie to trudno powiedzieć bo zawartość tych 64B zmienia się, ale nie za FF tylko na jakieś inne wartości. Na krzaki. Czyli coś jednak się z nią dzieje.
No więc pytanie: jak to skasować i jak to później zapisać?
Mam gotowego BINa 512000B łącznie z tymi pierwszymi 64-ma bajtami ale programowanie na nic mi się nie przyda skoro te pierwsze 64B się nie programują i później bootloader nie uruchamia kodu bo mu suma kontrona się nie zgadza.
PS.
Do odczytu używam takiej komendy:
| Code: |
openocd -f interface/parport.cfg -f target/lpc2478.cfg -c "init" -c "reset
halt" -c "dump_image XXXX.bin 0 512000"
|
Niestety podanie ścieżki nie pozwala na pracę tego. Więc na razie wywołuję to bez ścieżki. I wyniki trafiają mi do katalogi Eclipse. Może ktoś wie jak trzeba podać ścieżkę żeby to działało?
|
|
| Back to top |
|
|
Freddie Chopin
Poziom 25
Joined: 12 Dec 2005
Posts: 7300
Location: Zawiercie
|
#38
14 Mar 2010 23:35 Re: Funkcja w RAMie nie działa. Ręce opadają. |
|
|
|
Jeśli remapujesz wektory przerwań (MEMMAP), albo robią to funkcje zapisujące flash, to właśnie powoduje zmianę fragmentu widocznego pod adresami 0 - 63.
4\/3!!
|
|
| Back to top |
|
|
atom1477
Poziom 25
Joined: 14 Jul 2005
Posts: 6596
|
#39
15 Mar 2010 00:17 Re: Funkcja w RAMie nie działa. Ręce opadają. |
|
|
|
W MEMMAP mam wartość 01. Czyli nie remapuję tego.
To po pierwsze.
Po drugie w manualu pisze że komanda erase nie kasuje tych pierwszych 64B Flasha.
A przecież jakoś musowo je skasować żeby je zaprogramować.
Teraz trochę zaczynam rozumieć. Może to co widzę to są wektory z Boot Loadera. Domyślna wartość MEMMAP po resecie to 00 czyli Boot Loader Mode.
No ale powinna być ona poprawna (poprawna suma kontrolna) więc po pierwsze: BootLoader nigdy nie wykrył by błędów w kodzie bo zawsze po resecie widział by własne (poprawne) wektory.
I po drugie z tego właśnie powodu kod powinien mi się uruchamiać.
Chyba że dalej czegoś nie rozumiem. Tak jest najprędzej.
Tak więc czekam na dalsze wyjaśnienia krowie na miedzy ;)
|
|
| Back to top |
|
|
michalko12
Poziom 22
Joined: 20 Nov 2004
Posts: 1661
Location: Gdzieś koło wawy
|
#40
15 Mar 2010 02:10 Re: Funkcja w RAMie nie działa. Ręce opadają. |
|
|
|
Bootloader nie sprawdza sumy kontrolnej własnych wektorów, bo nie ma takiej potrzeby tylko sumę kontrolną wektorów kodu użytkownika i nie robi tego poprzez bezpośredni odczyt obszaru od 0x00000000 tylko poprzez kontroler flasha. Nie wiem gdzie wyczytałeś, że pierwszych 64B nie da się wykasować.
Kompilator nie liczy sumy kontrolnej, musisz sam ją policzyć i podmienić wektor pod adresem 0x00000014. Weź pod uwagę, że ten przypadek z sumą kontrolną wektorów przerwań dotyczy się tylko procesorów od NXP, a kompilatorowi nie podajesz konkretnego typu układu tylko typ rdzenia, który też jest wykorzystywany przez innych producentów.
|
|
| Back to top |
|
|
atom1477
Poziom 25
Joined: 14 Jul 2005
Posts: 6596
|
#41
15 Mar 2010 14:33 Re: Funkcja w RAMie nie działa. Ręce opadają. |
|
|
|
| michalko12 wrote: |
| Bootloader nie sprawdza sumy kontrolnej własnych wektorów, bo nie ma takiej potrzeby |
Wiem, ale manual nie precyzował tego.
| michalko12 wrote: |
| Kompilator nie liczy sumy kontrolnej, musisz sam ją policzyć i podmienić wektor pod adresem 0x00000014. |
Kto zatem liczy tą sumę podczas programowania procesora? OpenOCD?
| michalko12 wrote: |
| Weź pod uwagę, że ten przypadek z sumą kontrolną wektorów przerwań dotyczy się tylko procesorów od NXP, a kompilatorowi nie podajesz konkretnego typu układu tylko typ rdzenia, który też jest wykorzystywany przez innych producentów. |
Tak, ale podaję różne inne rzeczy więc i algorytm na liczenie tej sumy też mógł by być podawany. Po prostu jest jakiś niepisany standard żeby nie zlecać liczenia tego kompilatorowi.
|
|
| Back to top |
|
|
michalko12
Poziom 22
Joined: 20 Nov 2004
Posts: 1661
Location: Gdzieś koło wawy
|
#42
15 Mar 2010 14:49 Re: Funkcja w RAMie nie działa. Ręce opadają. |
|
|
|
| atom1477 wrote: |
| michalko12 wrote: |
| Bootloader nie sprawdza sumy kontrolnej własnych wektorów, bo nie ma takiej potrzeby |
Wiem, ale manual nie precyzował tego.
| michalko12 wrote: |
| Kompilator nie liczy sumy kontrolnej, musisz sam ją policzyć i podmienić wektor pod adresem 0x00000014. |
Kto zatem liczy tą sumę podczas programowania procesora? OpenOCD?
| michalko12 wrote: |
| Weź pod uwagę, że ten przypadek z sumą kontrolną wektorów przerwań dotyczy się tylko procesorów od NXP, a kompilatorowi nie podajesz konkretnego typu układu tylko typ rdzenia, który też jest wykorzystywany przez innych producentów. |
Tak, ale podaję różne inne rzeczy więc i algorytm na liczenie tej sumy też mógł by być podawany. Po prostu jest jakiś niepisany standard żeby nie zlecać liczenia tego kompilatorowi. |
Tak, OpenOCD liczy tą sumę, algorytm jest podany w manualu i jest bardzo prosty. Pod adresem 0x000000014 ma być taka wartość, aby po zsumowaniu wszystkich wektorów przerwań łacznie z tym pod 0x14 wynik był równy 0.
| Quote: |
Criterion for valid user code: The reserved ARM interrupt vector location (0x0000 0014)
should contain the 2’s complement of the check-sum of the remaining interrupt vectors.
This causes the checksum of all of the vectors together to be 0. |
|
|
| Back to top |
|
|
atom1477
Poziom 25
Joined: 14 Jul 2005
Posts: 6596
|
#43
15 Mar 2010 15:05 Re: Funkcja w RAMie nie działa. Ręce opadają. |
|
|
|
Oczywiście widziałem to. Tylko myślałem że BIN generowany przez kompilator już ma tą sumę.
Skoro rozmieszczenie wektorów przerwań można kompilatorowi podać, rozmieszczenie rejestrów można podać, ilość FLASHa i RAMu można podać, to i algorytm liczenia tej sumy można by podać więc myślałem że jest to już zrobione.
Swoją drogą to kompilator pewnie też nie ma pojęcia o tym że pod adresem 0x01FC ma być LockBit?
Czyli pisząc program zawierający jakieś stałe o wartości 0x43218765 można sobie zablokować procesor?
A co do tej sumy to nie zamierzam jej liczyć ;) Zaprogramuję procesor. Odczytam procesor. I dopiero tym odczytanym BINem będę za pomocą mojego Uploadera programował kolejne procesory ;)
|
|
| Back to top |
|
|
Google
|
| #
15 Mar 2010 15:05 |
|
|
|
|
|
| Back to top |
|
|
michalko12
Poziom 22
Joined: 20 Nov 2004
Posts: 1661
Location: Gdzieś koło wawy
|
#44
15 Mar 2010 15:25 Re: Funkcja w RAMie nie działa. Ręce opadają. |
|
|
|
| atom1477 wrote: |
Tak widziałem to oczywiście. Tylko myślałem że BIN generowany przez kompilator już to ma.
Skoro rozmieszczenie wektorów przerwań można kompilatorowi podać, rozmieszczenie rejestrów można podać, ilość FLASHa i RAMu można podać, to i algorytm liczenia tej musy można by podać więc myślałem że jest to już zrobione. |
Jeśli jest jakaś funkcja w linkerze która potrafi dostarczyć do kodu zawartość pamięci spod konkretnego adresu, to byłoby możliwe zautomatyzowanie liczenia tej sumy kontrolnej.
| atom1477 wrote: |
| Swoją drogą to kompilator pewnie też nie ma pojęcia o tym że pod adresem 0x01FC ma być LockBit? |
No niestety nie ma bo to też jest wymysł NXP.
| atom1477 wrote: |
| Czyli pisząc program zawierający jakieś stałe o wartości 0x43218765 można sobie zablokować procesor? |
No cóż, rachunek prawdopodobieństwa, a z drugiej strony można poświęcić cały ten sektor na jakieś konkretne dane łącznie z wektorami przerwań, a kod zaalokować dopiero od sektora[1];
| atom1477 wrote: |
| A co do tej sumy to nie zamierzam jej liczyć ;) Zaprogramuję procesor. Odczytam procesor. I dopiero tym odczytanym BINem będę za pomocą mojego Uploadera programował kolejne procesory ;) |
Twoja sprawa, ale przecież skoro piszesz własny bootloader to nie jest problem napisać kilka linijek kodu w swoim bootloaderze podstawiających właściwą wartość.
|
|
| Back to top |
|
|
Google
|
| #
15 Mar 2010 15:25 |
|
|
|
|
|
| Back to top |
|
|
atom1477
Poziom 25
Joined: 14 Jul 2005
Posts: 6596
|
#45
15 Mar 2010 16:00 Re: Funkcja w RAMie nie działa. Ręce opadają. |
|
|
|
O kurcza, Działa. :D
Wielkie dzięki wszystkim za pomoc!
PS.
| michalko12 wrote: |
| No niestety nie ma bo to też jest wymysł NXP. |
No ale jak zwykle mi chodziło o to czy jakoś nie da się poinformować kompilatora o tym.
| michalko12 wrote: |
| Twoja sprawa, ale przecież skoro piszesz własny bootloader to nie jest problem napisać kilka linijek kodu w swoim bootloaderze podstawiających właściwą wartość. |
A to jest bez sensu. Lepiej zrobić program na PC który to policzy i podstawi do BINa niż robić to w bootloaderze marnując pamięć Flash.
Tylko jeszcze jedna rzecz mnie zastanawia.
Jak zaznaczam sektory do zapisania to po zapisie zaznaczenie jest usuwane ze wszystkich sektorów? Bo jak na razie gdy naznaczę sektory od 0 do 27 to zapisuje mi tylko pierwsze 256B Flasha (zapisuję w pętli po 256B).
Więc zrobiłem tak że za każdym razem w tej samej pętli zaznaczam za każdym razem wszystkie sektory od 0 do 27 i zapisuję kolejne 256B. Trochę to dziwne ale mam sens, bo dzięki temu nie muszę wyliczać który sektor mam zaznaczyć.
Tylko że gdzieś w międzyczasie któraś funkcja IAP wywala mi błąd (mimo że wszystko przebiega OK bo program później działa).
|
|
| Back to top |
|
|
