Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Wszystko o ARM (LPCxxxx) i programowaniu w asm i C.

atom1477 24 Wrz 2009 17:07 15937 141
  • #1 24 Wrz 2009 17:07
    atom1477
    Poziom 43  

    Witam.
    Mam problem z uruchomieniem SDRAMu K4S641632 do współpracy z LPC2478.
    A problem jest dość nietypowy.
    Aby przetestować SDRAM napisałem sobie program na PC.
    Po RS232 komunikuje się on z LPC2478. Z poziomu PC mogę zapisywać komórki pamięci. No może nie bezpośrednio, ale za pomocą tablicy elementów 32-bitowych.

    No i gdy tablicę umieszczę w RAMie LPC2478 to wszystko działa dobrze. Zapisuję i odczytuję komórki i działa. Zapisuję i odczytuję całe pliki, i działa (program na PC ma opcję wysyłania i odbierania całych plików).

    Problem zaczyna się gdy tablicę przerzucę do SDRAMu.
    Zapis i odczyt działa. Czasami mam jakieś błędy, ale to pewnie przez niekoniecznie optymalne skonfigurowanie układu EMC.
    Problem jest inny. Procesor LPC2478 całkowicie olewa sobie stan linii D0…D15
    Mogę zapisać na przykład 256B jakichś danych, i podczas zapisu widzę że na liniach D0…D15 coś się dzieje. Robię odczyt i na kompie widzę że wartości komórek są takie jak poprzednio zapisałem. Ale linie D0…D15 milczą. Myślałem że może impulsy są krótkie i oscyloskop nie łapie, ale nie.
    Mogę zewrzeć linie D0…D15 do masy czy do VCC a mimo to odczyt daje poprawne wartości! Oczywiście resetowałem program na PC żeby wykluczyć że to on pamięta wartości komórek pamięci. Mogę nawet całego kompa zresetować a dalej odczyt będzie poprawny.
    Wszystko wskazuje na to że procesor tylko udaje zapis do SDRAMu a dane i tak zapisuje do swojego wewnętrznego RAMu i potem stąd dokonuje odczytu. Może kompilator tak to kompiluje (żeby zapisywać w RAMie)?
    W załączniku schemat i cały projekt spod Eclipse. Może ktoś będzie wiedział o co tutach chodzi bo mi już ręce opadają.

    0 29
  • Pomocny post
    #2 25 Wrz 2009 09:03
    94075
    Użytkownik usunął konto  
  • #3 25 Wrz 2009 15:49
    atom1477
    Poziom 43  

    Właśnie widziałem że zmienna trafia pod adres SDRAMu (w pliku map zobaczyłem) ale myślałem że kompilator może później coś pierdzieli i przerzuca spowrotem do RAMu.
    No więc dzięki za sprawdzenie (U mnie podgląd assemblera nie działa. Eclipse się zawiesza).

    Z tym plikiem 1MB to niestety musimy poczekać (wiem co dał by taki test ale na razie nie da). Bo niestety jest jeszcze jeden problem.
    Wcześniej o nim nie wspomniałem bo post stał by się strasznie długi i nikomu nie chciało by się czytać a więc i pomagać ;p No więc:
    Dla małych plików (powiedzmy 256B) zapis idzie dość dobrze. Występuje dość dziwna rzecz, bo pierwszy zapis jest trochę błędny. Odczyt daje dane "powielone" dane. Młodsze 16b jest powielane do starszych 16b.
    Na przykład jak zapisze wartość 0x03020100 to odczytuję 0x01000100.

    Najczęściej dotyczy to danych po 192-gim bajcie.
    Robię kolejny zapis i potem odczyty są dobre.
    Dla większych plików błędów jest coraz więcej i co ciekawe zaczynają dotyczyć też tych pierwszych 192 bajtów.
    A to jest dziwne, bo zapis plików mam zrealizowany jako zapis pojedynczych słów 32b, tyle że w pętli.
    Jak sobie ręcznie zapisuję i odczytuje pojedyncze wartości, to mam poprawne wartości już od pierwszego zapisu. Tak jak by zapis za dużej ilości danych po sobie powodował błędy.
    No i właśnie dlatego chcę naprawić działanie pamięci SDRAM bo coś mi ona nie działa. Jak by działała to nawet bym się nie zastanawiał dlaczego linie D0...D15 są olewane. Może nawet bym tego nie zauważył.
    A jak bym zauważył bo może i bym się zastanawiał, ale przynajmniej mógł bym iść dalej z projektem, a zastanawianie zostawił bym sobie na później (choć to niemożliwe żeby SDRAM działał mimo niedziałania linii danych ;p).

    No więc ostatecznie: nie bardzo mam po co zapisywać tam plik 1MB, bo potem będą tam same krzaki.
    Zrobiłem tylko test: Zapis około 2kB do SDRAM. Odczyt całych 64MB RAMu i sprawdzenie czy siedzi tam ten plik 2kB. I nie siedzi. Odczyt SDRAMu – jest (ale już bardzo mocno zakrzakowany).
    No w zasadzie odczytałem tylko jakieś 65400B, bo potem procesor się zawiesił (Procesor ARM – pewnie wszedłem na stos. Tylko dlaczego zaszkodził mu ODCZYT. Może to jakieś mechanizmy ochrony stosu).
    Zrobiłem też taki test, że zmniejszyłem odświeżanie pamięci SDRAM do najmniejszej możliwej wartości (kilka minut by wyszło). A dane dalej dobre...
    Dlatego na razie kompletnie nie obchodzi mnie to czy dane będą dobre czy złe. Ja tylko chce żeby procesor próbując korzystać z pamięci SDRAM robił to tak jak trzeba, czyli korzystając z linii D0…D15. Przecież to podstawa.
    Coś mi sie zdaje że układ EMC przekierowuje adresy od 0xA0000000 gdzieś indziej.
    Bo gdyby ten układ nie działał to nie miał bym przecież poprawnych wartości.

    Zadziwiające że nikt na elektrodzie nie podłączał pamięci SDRAM do procesora LPCxxxx (pomijam tych którzy korzystają z gotowców (zestawów startowych).

    PS. Czy to:

    Code:

    .ext_mem (NOLOAD) : { *(.ext_mem .ext_mem.*) } > sdram0


    Sprawi że plik bin będzie miał mniej niż 1GB? ;p

    A nie może być:
    Code:

    .ext_mem (NOLOAD) : { *(.ext_mem .ext_mem.*) } > sdram0 AT > sdram0


    Chodzi mi oczywiście o „> sdram0 AT”.
    Nie wiem co to daje, ale tak proponował Freddie Chopin.

    0
  • Pomocny post
    #4 25 Wrz 2009 16:48
    94075
    Użytkownik usunął konto  
  • #5 25 Wrz 2009 17:53
    atom1477
    Poziom 43  

    Raczej User Manuala wezmę ;p, bo w Datasheecie to nic nie ma.
    User manual to moja książka do poduszki.

    Ale objawów niestety to nie tłumaczy, bo bufory nie są w stanie przetrzymać aż 256B danych.
    W dodatku próbowałem zapisywać i odczytywać w różnej kolejności a dane dalej dobre.

    Ale problem częściowo rozwiązałem (to znaczy sam się rozwiązał).

    Nie jestem tego do końca pewny, ale na 90% tak jest.
    Mianowicie tak:
    Jak przyspieszyłem odczyt, to zwieranie linii D0...D15 do masy daje efekty.
    Obstawiam że winna jest indykacyjność kabelka którym zwierałem linie do masy (z 10cm). Możliwe że przez jego indukcyjność impulsy o czasie trwania kilkunastu ns na liniach D0...D15 występują. Po prostu linie nie widzą zwarcia do masy.
    Mam też swoją teorię na temat odświeżania SDRAMu. Układ wytrzymuje kilkusekundowe odłączenie od zasilania (SDRAM pamięta zawartość). Obstawiam więc że podany w Datasheecie czas odświeżenia (64ms) to gwarantowany czas podczas którego żaden egzemplarz pamięci nie zgubi zawartości żadnej komórki.
    Większość egzemplarzy ma na pewno o wiele lepsze parametry (powiedzmy kilkaset ms). A i to dla wszystkich komórek.
    Większa zwłoka w odświeżaniu powoduje stratę zawartości niektórych komórek, ale prawdopodobnie stosunek ilości komórek zachowanych do traconych jest wciąż bardzo duży. Więc obstawiam że dlatego układ działał dla śmiesznie małego odświeżania jak i dla odłączania zasilania na kilka sekund.
    A już myślałem że procesor zapisuje dane do FLASHa ;p

    Czyli rozwiązanie problemu, jak zwykle u mnie, jest nietypowe.
    I jak zwykle zachodzi to zaraz po spytaniu o to na elektrodzie ;p

    Wciąż występuje jednak problem błędnego zapisu.
    Ale to już pewnie wina błędnego skonfigurowania układu EMC.

    Dodano po 17 [minuty]:

    Z tą podpowiedzią to chodziło Ci o to że jeżeli zapis się uda to znaczy że to jest SDRAM? Bo w RAM nie wejdzie 1MB? Jeżeli tak to załapałem.

    Zmiana tej linii co podałeś nic nie zmienia. BIN ma nadal ze 2.5GB. Oczywiście w Makefile włączyłem tworzenie pliku BIN.


    Co do w.cz. to trochę się zgodzę. Ale 36MHz to chyba jeszcze nie tak dużo. Ścieżki mają po 5cm i niestety różne długości.
    Ale na firmowych płytkach pod LPC2478 większe cuda widziałem. Co innego że oni mogli zrobić jakieś testy a ja nie zrobiłem.

    0
  • Pomocny post
    #6 25 Wrz 2009 18:50
    94075
    Użytkownik usunął konto  
  • #7 25 Wrz 2009 20:19
    atom1477
    Poziom 43  

    No nareszcie znalazłem. Rozumiem że 128B? 4 x 16Word.

    No to faktycznie, jak zapisywałem sobie kilka wartości na zmianę to odczyt nie był dokonywany z SDRAMu.
    Na śmierć zapomniałem o tych buforach.
    Szkoda że nie można używać SDRAMu bez użycia tych buforów. Łatwiej by mi się to uruchamiało bo od razu miał bym podgląd każdej komórki.
    Dzięki.

    Co do w.cz. to teoretycznie problem może być, ale układ testuję też na o wiele mniejszych częstotliwościach, a nie zmienia się absolutnie nic.

    Próbowałem na 72, 36 i 12MHz.

    Zapisuję do SDRAMu plik 0.txt.
    Odczytuję z SDRAMu do 1.txt
    Ponownie zapisuję i odczytuję do 2.txt (2.txt jest taki sam jak 0.txt więc go nie umieszczam).

    Próbowałem dwukrotnego i wielokrotnego zapisu ale nic to nie daje.
    Potrzebny jest zapis, odczyt, zapis i odczyt, i dopiero ten drugi odczyt da dobre wyniki (może też być odczyt, zapis, odczyt).
    Objawy są raczej kosmiczne i nie sądzę żeby komuś chciało się to analizować.
    No chyba że ktoś widzi jakiś poważny błąd w konfiguracji EMC.

    0
  • #9 25 Wrz 2009 21:09
    atom1477
    Poziom 43  

    Ale tam są Word a nie DWord.
    4 x 16 x 16 = 128 x 8

    Tak, AN10771 oczywiście widziałem. Stamtąd pochodzi kod do EMC.

    0
  • Pomocny post
    #10 25 Wrz 2009 21:12
    94075
    Użytkownik usunął konto  
  • #11 25 Wrz 2009 21:29
    atom1477
    Poziom 43  

    Nie no. Ja jako Word uznaję szerokość 16bitów (Zgodnie z podziałem Byte/Word/DWord).
    Jaki rdzeń by nie był.
    W takim razie User Manual jest do dupy bo nie precyzuje tego.
    No ale dobra.

    Więc muszę zapisywać więcej.
    Jak by nie było, te bufory dziwnie się zachowują bo zwracają dziwne wartości dopóki nie dokona się pierwszego odczytu. Poniżej 256B wszystko chyba powinno owszem wyjść do SDRAMu, ale odczyt powinien jeszcze iść z buforów więc odczyty powinny być dobre.

    PS. U mnie nie ma rozdziału 5.3.13 ;)

    EDIT.
    Próba 512B ;) Pierwsza rzecz która się rzuca w oczy to powielanie młodszych 16bitów na starsze 16bitów. Reszta to coś jak zwarte linie adresowe. Tylko że multimetr zwarć ostatnio nie pokazywał. Ale jeszcze się upewnię.


    Widzę że brak mi jeszcze ustawiania rejestru MODE w SDRAM. A to chyba ważna sprawa. Dodam to i napiszę co z tego wyszło.

    0
  • Pomocny post
    #12 26 Wrz 2009 00:12
    zbigel
    Poziom 12  

    Witam.
    Też męczę się z obsługą pamięci SDRAM przez LPC2478. Używam pamięci innego producenta, ale o dokładnie takiej samej strukturze (1Mx16Bitx4banki). U mnie problem jest innego typu. Jak zapisuje całą pamięć (8MB) to okazuje się, że dane zapisują się tylko pod adresami 0-0x1FFFFF i 0x400000-0x5FFFFF. Natomiast komórki 0x200000-0x3FFFFF i 0x600000-0x7FFFFF pozostają nie zapisane. Tak się dzieje jak skonfiguruje EMC jako LowPower. A w przypadku trybu HighPerformance dane są zapisywane pod wszystkimi adresami, ale za to są przekłamane. A co do ustawienia "Mode Register" dla SDRAMu to jest to bardzo ważna sprawa. I wydaje mi się, ze Twoje problemy mogą wynika właśnie z niezgodności ustawienia "CAS latency".
    Pozdrawiam
    Zbigel

    Dodano po 7 [minuty]:

    Pod tym linkiem są informacje niezbędne do poprawnej konfiguracji tego rejestru Konfiguracja

    0
  • #13 26 Wrz 2009 11:00
    atom1477
    Poziom 43  

    Niezgodności ustawienia "CAS latency"? Chyba z całkowitego braku ustawiania tego ;p

    Kompletnie o tym zapomniałem. Kilka miesięcy temu gdy zaczynałem zabawę z EMC wiedziałem że coś ma tam być. Tylko kompletnie nie rozumiem po co jest dokonywany jakiś dziwny odczyt (dziwny bo jakieś wskaźniki tam są) i to do zmiennej lokalnej która nawet we wnętrzu funkcji inicjalizującej EMC nie jest już więcej używana.
    Wczoraj załapałem o co chodzi.
    Ale nie miałem siły się tym zająć z dwóch powodów:
    1. U mnie linie adresowe są przemieszane i trzeba będzie trochę zakombinować żeby ustawić odpowiednią komendę.
    2. Występuje przesunięcie którego nie rozumiem.
    Np. Mam pamięć o 13 kolumnach i 9 wierszach. A dla takiej pamięci mam komendę 0x00023000 (dla burst = 8 i CAS latency = 2). Czyli przesunięcie wynosi 12.
    Wiec:
    9 wierszy + 2linie do adresowania banków + 1(bo adres jest mnożony przez 2 bo pamięć jest 16-to bitowa) = 12.
    Czyli zgadza się.

    Ale w przykładowym kodzie od NXP mam taką sama pamięć, a przesunięcie wynosi 10.
    I to mi się nie zgadzało.
    Zastosuję 11 (u mnie będzie 8+ 2+ 1 = 11) i zobaczę co z tego wyjdzie.
    Strasznie dzięki za pomoc.

    zbigel: może spróbuj zmniejszyć prędkość trochę (spowolnij rdzeń ze dwa razy).
    na czym polegają przekłamania?



    PS. A ten temat na embeddedrelated widziałem już wcześniej. Tylko nie wiedziałem o czym oni gadają w ogóle ;p

    0
  • Pomocny post
    #14 26 Wrz 2009 12:11
    zbigel
    Poziom 12  

    Witam
    Wydaje mi się, że to przesuniecie powinno być 9. Bo dla konfiguracji w tryb LowPower do przesunięcia nie dolicza się linii adresowania banków. Tak jest napisane na stronie w linku który Ci podałem. Moja pamięć też ma 8 wierszy i stosuje przesunięcie równe (8+1=9). A jeśli ustawię inną wartość to nie odczyt i zapis nie działają poprawnie. A co do mojego problemu to faktycznie spróbuje zmniejszyć prędkość rdzenia, ale to dopiero w poniedziałek.
    Pozdrawiam
    Zbigel

    0
  • #15 26 Wrz 2009 13:19
    atom1477
    Poziom 43  

    Ale ja uruchamiam w normalnym trybie, a nie Low Power.
    I chyba mam mały progress.
    Już coś zapisuje i odczytuje. Ale jedynie jakieś 256B co kilka kB.
    Czyli jak zapiszę jakiś duży plik, to poprawnych jest tylko trochę danych.
    Tak z 10%. Co kilka kB jest poprawny pakiet 256B, reszta to krzaki.
    Ale może to faktycznie przez złe przesunięcie. Spróbuję. Co innego mi pozostało.
    Dzięki z pomoc.

    0
  • Pomocny post
    #16 26 Wrz 2009 13:36
    zbigel
    Poziom 12  

    Te tryby pracy wybiera się konfigurując rejestr EMCDynamicConfig. Jest taka tabela Address Mapping. Masz to wyboru "16 bit external bus high-performance address mapping" "16 bit external bus low-power SDRAM address mapping" i odpowiedniki 32bitowe. Ale teraz faktycznie widzę, że korzystasz z high-performance, czyli przesuniecie będzie wtedy wynosiło 12, tak jak liczyłeś.
    Pozdrawiam
    Zbigel

    0
  • #17 26 Wrz 2009 14:26
    atom1477
    Poziom 43  

    Wiem wiem :D Tą tabelkę przeglądałem już ze 100 razy.
    Te Twoje błędy dla trybu Low Power dowodzą że nie działają dwa banki.
    Jest taki rejestr gdzie ustawia sie opóźnienie zmiany banku (EMCDynamic RRD). Może masz tam wpisane za małe opóźnienie?

    Dodano po 21 [minuty]:

    Ustawiłem tryb Low Power, i mam kolejny Progress.
    Jest już o wiele więcej poprawnych danych.
    Mam 256B krzaków i 256B poprawnych danych, znowu 256B krzaków i znowu 256B poprawnych danych itd.
    Te krzaki to w zasadzie nie krzaki, lecz przesunięta o dwa bajty kopia kolejnego obszaru 256B.
    Domyślam się że może niezbyt jasno się wyrażam, ale nie wiem jak to inaczej krótko opisać. Jak ktoś chce to mogę dać rysunek.

    Wygląda na to że zaczynamy jechać na tym samym wózku. Może też wrzuć plik, o ile te dane które zapisujesz i odczytujesz możesz jakoś przenieść na kompa.

    0
  • #18 26 Wrz 2009 16:50
    zbigel
    Poziom 12  

    Możesz mieć rację z tym opóźnieniem przełączania banków. Niestety mogę to sprawdzić dopiero w poniedziałek. Teraz nie mam dostępu do sprzętu. Napiszę więcej w poniedziałek.
    Pozdrawiam
    Zbigel

    0
  • #19 26 Wrz 2009 21:29
    atom1477
    Poziom 43  

    A masz chociaż dostęp do programu?
    W czym piszesz w ogóle?
    Ja zaczynam wątpić w sens pisania w Eclipse, bo prawie wszystko w internecie na LPCxxxx jest pod Keil-a. A jak dla mnie to duża różnica.
    Domyślam się że uruchamiasz program Standalone. Tak jest?
    A sprzęt? Masz jakąś fabryczną płytkę czy samoróbka? A może pająk?
    Nie nie, to nie żart. Pytam na poważnie. Ja pierwsze programy na ARMa uruchamiałem na pająku (a był to jak zwykle LPC2478 a nie coś mniejszego).

    0
  • Pomocny post
    #20 26 Wrz 2009 22:53
    zbigel
    Poziom 12  

    Do programu też nie ma mam dostępu. Pisze i debuguje w Keilu właśnie. A płytka jest zaprojektowana i wykonana profesjonalnie (nie przeze mnie) chociaż to nie jest żaden StarterKit. Raczej nie ma mowy o błędach w sprzęcie. W poniedziałek spróbuje pozmieniać opóźnienia, może to coś zmieni. Dam znać co z tego wyszło.
    Zbigel

    0
  • Pomocny post
    #21 27 Wrz 2009 00:17
    Freddie Chopin
    Specjalista - Mikrokontrolery

    atom1477 napisał:
    Ja zaczynam wątpić w sens pisania w Eclipse, bo prawie wszystko w internecie na LPCxxxx jest pod Keil-a. A jak dla mnie to duża różnica.

    A co to za różnica czy:
    Code:

    REG1 = 0x12345678;
    REG2 = 0;
    REG3 = 0xFFFFFFFF;

    jest napisane pod Keila czy pod Eclipse? błagam...

    4\/3!!

    0
  • #22 27 Wrz 2009 15:27
    atom1477
    Poziom 43  

    A to:

    Code:

    ctl_global_interrupts_enable();

    ?

    Nie mów że nie ma różnicy.
    Keil ma jakieś tam swoje biblioteki i już.
    A zrobienie tego pod Eclipse wymaga zrobienia tego samemu, albo znalezienia bibliotek do Keila, co jak się przekonałem łatwe nie jest.
    Ileż się naszukałem w User Manualu co odpowiada za globalne włączenie przerwań w LPC2478. I okazało się że chyba nic. Po prostu to wymysł Keila ta funkcja.
    A taki przykładów jest więcej. Znajduję przykładowy kod do obsługi czegoś tam, ale pod Ecpisle nie mogę go po prostu wkleić i skompilować bo brakuje miliona bibliotek z Keila.
    Znalazłem nawet stronę gdzie są opisane funkcje z tych bibliotek, ale opis tam zawarty mi nie odpowiada. Tutaj nawet nie chodzi o opis. Może on być źle napisany, czy napisany po arabsku. Największym problemem jest brak kodu. Co mi po opisie. Ja potrzebuję kod żeby to przemieść pod Eclipse.
    Na przykład wyjaśnienie powyższej funkcji było mniej więcej takie, że jest to główny włącznik przerwań. Co chyba nie jest prawdą, bo w ARMach nie ma czegoś takiego jak globalne zezwolenie na przerwania. No chyba że się mylę, ale pod Eclipse nic takiego nie włączałem a przerwania już mi działają. A chyba nie chodzi o włącznik zasilania układu VIC.
    Nie mówię że Eclipse złe. Nawet podoba mi się że wszystko trzeba zrobić samemu. Ale utrudnieniem jest to, że bardzo trudno znaleźć normalny „niskopoziomowy” kod pod Eclipse. Może nie tyle pod Eclipse, co w ogóle „niskopoziomowy” nie korzystający z tych BASCOMowych bibliotek Keila ;p

    Dodano po 4 [godziny] 36 [minuty]:

    Problem częściowo rozwiązany. Problemem były przemieszane linie adresowe.
    Najpierw miałem przemieszane wszystkie linie. Potem się zgapłem że linie A12 i A13 trzeba podłączyć do linii zmiany banków. No więc podłączyłem.
    Potem że linie A0…A7 koniecznie muszą trafiać do linii A0…A7, bo inaczej nie da się poprawnie zaadresować wierszy które to zawsze korzystają z tych linii, a nie z tych wyższych (A8… A11).
    Potem linia A10/AP. Też miałem źle podłączoną (zamienioną z A11). Zamieniłem.
    Już myślałem że to wszystko, ale zapis nadal nie działał.
    I w końcu wpadłem na to że może SDRAM obsługuje zapis i odczyt sekwencyjny (jednokrotne podanie adresu i potem automatyczną inkrementację adresu co zapis/odczyt).
    No więc i przemieszanie linii A0…A7 musiałem usunąć.
    Bez tego adresy były by inaczej inkrementowane w procesorze i w SDRAMie.
    No i działa! Siekę maiłem niemiłosierną (tylko linia A5 została tam gdzie jest ;p) ale już działa!
    Niezły pająk wyszedł na PCB, ale mimo to działa. Nawet na 72MHz.
    Czyli w.cz. tutaj problemem raczej nie jest. Zresztą tego się spodziewałem bo już wielokrotnie czytałem na elektrodzie że poniżej 100MHz naprawdę trudno o problemy.
    Ostateczny wniosek:
    W SDRAM nie mieszaj żadnych linii adresowych.
    W zasadzie to teraz będę się wystrzegał mieszania jakichkolwiek linii :D

    Test zrobiłem na totalnych krzakach (plik RAR) dla trybu Low Power. Plik ze 300kB.
    Co ciekawe, dla trybu High Performance wciąż mam krzaki (To znaczy niepoprawne dane. Dla Low Power krzaki też są, ale zgodne z tymi wcześniej zapisanymi).
    Możliwe że tak jak u zbigela też nie będą mi działały dwa banki ;p
    Ale to sprawdzę później, bo zapis i odczyt trwa bardzo długo a teraz muszę wyjść. A nie zostawię tego podłączonego do prądu ;p

    0
  • Pomocny post
    #23 27 Wrz 2009 19:52
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Cytat:
    Ileż się naszukałem w User Manualu co odpowiada za globalne włączenie przerwań w LPC2478. I okazało się że chyba nic. Po prostu to wymysł Keila ta funkcja.

    W User Manualu tego nie znajdziesz, tak samo jak szczegółów dotyczących przerwań, instrukcji assemblera itp. Dlaczego? Dlatego, że to są rzeczy specyficzne dla RDZENIA tego mikrokontrolera - rdznia ARM7TDMI-S, do którego dokumentację można znaleźć na stronie... pomysłodawców tego rdzenia - firmy ARM.

    atom1477 napisał:
    A to:
    Code:

    ctl_global_interrupts_enable();

    ?
    [...]
    Na przykład wyjaśnienie powyższej funkcji było mniej więcej takie, że jest to główny włącznik przerwań. Co chyba nie jest prawdą, bo w ARMach nie ma czegoś takiego jak globalne zezwolenie na przerwania. No chyba że się mylę, ale pod Eclipse nic takiego nie włączałem a przerwania już mi działają. A chyba nie chodzi o włącznik zasilania układu VIC.

    Wystarczyłoby rzucić okiem na startup, aby się domyślić co odpowiada za globalne przerwania... Nikt nie powiedział, że C dla ARMów jest prostsze niż Bascom. Odrobina inwencji...

    Cytat:
    Znalazłem nawet stronę gdzie są opisane funkcje z tych bibliotek, ale opis tam zawarty mi nie odpowiada. Tutaj nawet nie chodzi o opis. Może on być źle napisany, czy napisany po arabsku. Największym problemem jest brak kodu. Co mi po opisie. Ja potrzebuję kod żeby to przemieść pod Eclipse.

    Nie rozumiem czemu się dziwisz. Keil kosztuje 3000$ i nie jest to przypadek. Jeśli brak Ci miliona głupawych funkcji wymyślonych tylko po to, żeby uwiązać ludzi przy komercyjnym środowisku, to sobie je napisz, albo zapłać. Byznes ys byznes.

    Cytat:
    Nie mówię że Eclipse złe. Nawet podoba mi się że wszystko trzeba zrobić samemu. Ale utrudnieniem jest to, że bardzo trudno znaleźć normalny „niskopoziomowy” kod pod Eclipse. Może nie tyle pod Eclipse, co w ogóle „niskopoziomowy” nie korzystający z tych BASCOMowych bibliotek Keila ;p

    Nie chcę się czepiać, ale postępowanie zgodnie z datasheetem pozwala uniknąć 99% problemów - co chyba już zauważyłeś. W magistrali piny nazywają się A0 do A23 (przykładowo), co ma oznaczać kolejność - gdyby nie było różnicy, to każdy nazywałby się Axx.

    4\/3!!

    0
  • #24 27 Wrz 2009 21:43
    atom1477
    Poziom 43  

    Freddie Chopin napisał:
    Cytat:
    Ileż się naszukałem w User Manualu co odpowiada za globalne włączenie przerwań w LPC2478. I okazało się że chyba nic. Po prostu to wymysł Keila ta funkcja.

    W User Manualu tego nie znajdziesz, tak samo jak szczegółów dotyczących przerwań, instrukcji assemblera itp. Dlaczego? Dlatego, że to są rzeczy specyficzne dla RDZENIA tego mikrokontrolera - rdznia ARM7TDMI-S, do którego dokumentację można znaleźć na stronie... pomysłodawców tego rdzenia - firmy ARM.

    atom1477 napisał:
    A to:
    Code:

    ctl_global_interrupts_enable();

    ?
    [...]
    Na przykład wyjaśnienie powyższej funkcji było mniej więcej takie, że jest to główny włącznik przerwań. Co chyba nie jest prawdą, bo w ARMach nie ma czegoś takiego jak globalne zezwolenie na przerwania. No chyba że się mylę, ale pod Eclipse nic takiego nie włączałem a przerwania już mi działają. A chyba nie chodzi o włącznik zasilania układu VIC.

    Wystarczyłoby rzucić okiem na startup, aby się domyślić co odpowiada za globalne przerwania... Nikt nie powiedział, że C dla ARMów jest prostsze niż Bascom. Odrobina inwencji...




    Co do opisu rdzenia to się zgodzę. Faktycznie dużo tam jest.
    Co do inwencji to niekoniecznie. Skąd ktoś początkujący ma wiedzieć że taka rzecz będzie pisała w opisie rdzenia a nie w opisie konkretnego procesora? Opis VIC w końcu był w opisie procesora
    Inwencja niestety nie wystarczy.


    Freddie Chopin napisał:
    Cytat:
    Znalazłem nawet stronę gdzie są opisane funkcje z tych bibliotek, ale opis tam zawarty mi nie odpowiada. Tutaj nawet nie chodzi o opis. Może on być źle napisany, czy napisany po arabsku. Największym problemem jest brak kodu. Co mi po opisie. Ja potrzebuję kod żeby to przemieść pod Eclipse.

    Nie rozumiem czemu się dziwisz. Keil kosztuje 3000$ i nie jest to przypadek. Jeśli brak Ci miliona głupawych funkcji wymyślonych tylko po to, żeby uwiązać ludzi przy komercyjnym środowisku, to sobie je napisz, albo zapłać. Byznes ys byznes.


    Nie dziwię się. I to mi akurat nie przeszkadza. Jak ludzie chcą się uzależniać od Keila to niech się uzależniają. Przeszkadza mi tylko to że robią to prawie wszyscy i ciężko mi potem uzyskać pomoc w jakiejś sprawie bo wszyscy robią w Keilu i takiego problemu nie mają bo wszystko za nich załatwia właśnie Keil.


    Freddie Chopin napisał:
    Cytat:
    Nie mówię że Eclipse złe. Nawet podoba mi się że wszystko trzeba zrobić samemu. Ale utrudnieniem jest to, że bardzo trudno znaleźć normalny „niskopoziomowy” kod pod Eclipse. Może nie tyle pod Eclipse, co w ogóle „niskopoziomowy” nie korzystający z tych BASCOMowych bibliotek Keila ;p





    Nie chcę się czepiać, ale postępowanie zgodnie z datasheetem pozwala uniknąć 99% problemów - co chyba już zauważyłeś. W magistrali piny nazywają się A0 do A23 (przykładowo), co ma oznaczać kolejność - gdyby nie było różnicy, to każdy nazywałby się Axx.

    4\/3!!


    Nie do końca. Piny mają różne nazwy żeby nie zostały zwarte podczas automatycznego projektowania druku. I dla samej przejrzystości schematu.
    Linie D0…D7 i D8…D15 też mają różne nazwy, a ich mieszanie już problemów nie robi (byle nie mieszać młodszych ze starszymi).
    Akurat datasheet nie nakazuje podłączania linii w linię (A0 do A0, A1 do A1, itd.)
    Po prostu jest schemat, ale konkretnego nakazu oczywiście nie ma.
    Widocznie to tak oczywiste jest :D
    Problem był zupełnie inny. Mieszać można, trzeba to tylko przemyśleć. A w tym przypadku nie zrobiłem tego. Przemieszałem linie (na schemacie) i miałem później się zastanowić czy tak można. Ale potem o tym zapomniałem. Zerknąłem tylko na schemat i widząc że wszystko jest podłączone zaprojektowałem druk i zamówiłem płytki.
    A już wiele rzeczy zrobiłem mieszając linie. Najczęściej nawet nie trzeba było nic w kodzie zmieniać (jak SRAM). Ewentualnie jakieś małe zmiany (jako to coś innego, np. przetwornik DAC/ADC o wejściu/wyjściu równoległym). Tyle że wtedy o przemyśleniu nie zapomniałem.

    Dodatkowo przyznam się, że taki burdel na PCB zrobiłem celowo (akurat nie widać bo nie zamieściłem widoki PCB). Mam do zrealizowania o wiele poważniejszy projekt, i chciałem sprawdzić czy to może działać. Nie chciałem się martwić czy aby układ nie działa na granicy zawieszania się/gubienia danych. Ale jeżeli takie nie wiadomo co działa, to kolejny układ na normalnie zrobionej płytce na pewno zadziała (Chodzi mi o długie ścieżki, bardzo duże różnice w długości ścieżek i pająka nad SDRAMem. Przemieszania linii nie liczę, bo jego już wiem że nie może tutaj być.)

    0
  • Pomocny post
    #25 27 Wrz 2009 21:52
    Freddie Chopin
    Specjalista - Mikrokontrolery

    atom1477 napisał:
    Co do opisu rdzenia to się zgodzę. Faktycznie dużo tam jest.
    Co do inwencji to niekoniecznie. Skąd ktoś początkujący ma wiedzieć że taka rzecz będzie pisała w opisie rdzenia a nie w opisie konkretnego procesora? Opis VIC w końcu był w opisie procesora

    Wciąż źle na to patrzysz. LPC2xxx to mikrokontroler. Składa się on z "fabrycznego" rdzenia ARM7TDMI-S oraz peryferiów, produkcji i pomysłu NXP. Peryferia opisane są w manualu do LPC2xxx. Rdzeń i to co jest specyficzne dla niego - w dokumentacji rdzenia. VIC nie jest częścią rdzenia, bo dla rdzenia istnieje tylko 7 przerwań - reset, data abort, prefetch abort, swi, fiq, irq, undefined instruction - VIC jest układem peryferyjnym, który multiplexuje więcej źródeł sprzętowych do jednej linii - IRQ. Początkujący nie powinni się brać za ARMy [;

    Cytat:
    Nie dziwię się. I to mi akurat nie przeszkadza. Jak ludzie chcą się uzależniać od Keila to niech się uzależniają. Przeszkadza mi tylko to że robią to prawie wszyscy i ciężko mi potem uzyskać pomoc w jakiejś sprawie bo wszyscy robią w Keilu i takiego problemu nie mają bo wszystko za nich załatwia właśnie Keil.

    Nie mają problemu, jeśli ich projekty zaczynają się i kończą w sferze hobby - jeśli ktoś chce używać ARMów zawodowo, to raczej nikła szansa na zakup tak drogiego pakietu, chyba że mówimy tu o naprawdę dużej firmie.

    Cytat:
    Nie do końca. Piny mają różne nazwy żeby nie zostały zwarte podczas automatycznego projektowania druku. I dla samej przejrzystości schematu.
    Linie D0…D7 i D8…D15 też mają różne nazwy, a ich mieszanie już problemów nie robi (byle nie mieszać młodszych ze starszymi).
    Akurat datasheet nie nakazuje podłączania linii w linię (A0 do A0, A1 do A1, itd.)
    Po prostu jest schemat, ale konkretnego nakazu oczywiście nie ma.
    Widocznie to tak oczywiste jest :D
    Problem był zupełnie inny. Mieszać można, trzeba to tylko przemyśleć. A w tym przypadku nie zrobiłem tego. Przemieszałem linie (na schemacie) i miałem później się zastanowić czy tak można. Ale potem o tym zapomniałem. Zerknąłem tylko na schemat i widząc że wszystko jest podłączone zaprojektowałem druk i zamówiłem płytki.
    A już wiele rzeczy zrobiłem mieszając linie. Najczęściej nawet nie trzeba było nic w kodzie zmieniać (jak SRAM). Ewentualnie jakieś małe zmiany (jako to coś innego, np. przetwornik DAC/ADC o wejściu/wyjściu równoległym). Tyle że wtedy o przemyśleniu nie zapomniałem.

    Wystarczy ich nie mieszać nigdy, projekt płytki zajmie trochę dłużej, będzie miała 10 otworów więcej, ale nie będzie problemu. Kombinowanie zawsze źle się kończy.

    4\/3!!

    0
  • #26 27 Wrz 2009 22:09
    atom1477
    Poziom 43  

    Cytat:

    VIC jest układem peryferyjnym, który multiplexuje więcej źródeł sprzętowych do jednej linii - IRQ. Początkujący nie powinni się brać za ARMy [;


    No to dobrze wiedzieć (to o VIC). Co do początkujących to miałem raczej na myśli początkujących w dziedzinie ARMów :D
    Ja jakim typem początkującego bym nie był, ARMem raczej muszę się zając bo potrzebuję kontrolera LCD, żaden inny wynalazek nie spełnia moich oczekiwań do końca (CPLD+SRAM, S1D137xx czy inne cuda).

    Cytat:

    Nie mają problemu, jeśli ich projekty zaczynają się i kończą w sferze hobby - jeśli ktoś chce używać ARMów zawodowo, to raczej nikła szansa na zakup tak drogiego pakietu, chyba że mówimy tu o naprawdę dużej firmie.


    I to jest jeden z powodów dla którego mimo problemów nie przerzucam się na Keila :D

    Cytat:

    Wystarczy ich nie mieszać nigdy, projekt płytki zajmie trochę dłużej, będzie miała 10 otworów więcej, ale nie będzie problemu.

    No najlepiej nie mieszać, ale nie można powiedzieć że:
    Cytat:

    Kombinowanie zawsze źle się kończy.

    Mi się to zdarzyło pierwszy raz. A do tej pory same plusy miałem z takiego kombinowania.
    Moje zdanie jest takie że trzeba MYŚLEĆ.
    Oczywiście można uważać inaczej.
    Ale to już raczej pytanie filozoficzne (wyższość kombinowania nad nie kombinowaniem lub odwrotnie) więc chyba nie będziemy tutaj na forum pisali kilometrowych postów na ten temat :D

    W każdym razie ja już nieprędko znowu gdziekolwiek przemieszam linie adresowe :D
    W tym przypadku faktycznie się nie popisałem bo nigdzie nie mogłem znaleźć opisu adresowania pamięci SDRAM i już to powinno mnie zniechęcić do przemieszania linii a jak widać nie zniechęciło.

    Oczywiści wiem że ARM to tylko rodzaj rdzenia, a NXP t tylko jeden producentów (już całych procesorów a nie tylko rdzeni :D).
    Tylko że połączenie rdzenia z peryferiami to nie jest jakaś dziecinnie prosta sprawa więc myślałem że jednak jakaś mała ilość informacji w User Manualu na temat rdzenia się znajdzie.


    Teraz tylko czekam na zbiel-a żeby usunąć ten problem z EMC podczas pracy w trybie High Performance.

    0
  • Pomocny post
    #27 28 Wrz 2009 07:34
    94075
    Użytkownik usunął konto  
  • Pomocny post
    #28 28 Wrz 2009 07:43
    Freddie Chopin
    Specjalista - Mikrokontrolery
  • Pomocny post
    #29 28 Wrz 2009 09:07
    zbigel
    Poziom 12  

    Witam.
    Przetestowałem tą pamięć jeszcze raz i po wprowadzeniu zmian np. z tym opóźnieniem przełączania banków wszystko jest tak jak było wcześniej. Zmniejszałem też zegar 2razy, 4 razy i nic. W trybie LowPower dalej w pod połową adresów są same zera. Nie pisałem wcześniej, ale w tym trybie zawartość pamięci jest jakby powielona pod adresem 0xa0800000, 0xa1000000, 0xa1800000,... Nie wiem z czego to może wynikać. Natomiast w trybie HighPerformance dzieją się jeszcze dziwniejsze rzeczy. Jeśli zapisuje cały czas tą samą wartość to jest ok. Cała pamięć jest zapisaywana poprawnie, ale kiedy zapisuje np. zmienną indeksującą pętlę to już zapisują się krzaki, chociaż nie wszędzie. Zamieszczam obrazek na którym jest pokazana zwartość początku pamięci.
    Wszystko o ARM (LPCxxxx) i programowaniu w asm i C.
    Powinny być kolejno wartości 1,2,3,4,5,... zaczynając od adresu 0xa0000001. A pod adresem 0xa0000000 zapisywana jest liczba poprawnie zapisanych słów 32bitowych licząc od początku (pierwszy błąd przerywał zliczanie).
    Atom1477: Chyba jednak te nasze błędy różnią się. U Ciebie jest jakaś większa regularność wstawiania tych krzaków.

    0
  • #30 28 Wrz 2009 09:18
    atom1477
    Poziom 43  

    Widzocznie coś mi się pomyliło. W każdym razie na pewno jest to z jakiejś biblioteki.

    0