logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[Tms320C6720][CCS3v3]Efekt dźwiękowy - nieprawidłowa kompilacja kodu

h0nza 26 Lut 2012 16:51 1576 3
  • #1 10602118
    h0nza
    Poziom 15  
    Witam wszystkich
    Jestem w trakcie konstruowania ogólnie pojętego efektu dźwiękowego służącego do samokształcenia się w rodzinie procesorów DSP texasa ;-) , w skład którego wchodzi procesor DSP TMS320c6720 współpracujący z pamięcią 16MB (A43L3616AV) oraz zespołem przetworników analogowo cyfrowych i cyfrowo analogowych CS4271 pracujących w trybie master, dodatkowo wyposażonym w kilka filtrów podyktowanych notami katalogowymi układu A/D D/A, wzmacniaczem słuchawkowym oraz układem zasilania.
    Pod pojęciem ogólno pojętego efektu dźwiękowego rozumiem różnego rodzaju filtry, zniekształcenia sygnału, FFT i IFFT itp.

    Układ programuję za pomocą złącza JTAG kopią programatora TDS510
    kompiluję w Code Composer Studio 3.3.38.2 z wersją generowania kodu v6.0.8
    W chwili obecnej wygląda to tak:

    https://obrazki.elektroda.pl/3229738100_1330269750.jpg
    https://obrazki.elektroda.pl/3863263100_1330269751.jpg


    Problem jest następujący:
    chcę skompilować banalnie prosty program który zapali 3 diody połączone bezpośrednio do nóg procesora za pomocą rejestru McASP (program łącznie z całym projektem jak i skompilowanym wyjściem w zalączniku) ustawiam PFUNC, PDIR i kasuję PDOUT (uzupełniając te 3 rejestry ręcznie, diody się zapalają)

    Po skompilowaniu (poprawnym wg kompilatora) i wgraniu pliku do układu, okazuje się że fragment pamięci RAM (wewnętrznej) w którym powinna znajdować się skompilowana funkcja main nie jest zmieniany (zmienianych jest kilka pojedyńczych bajtów różnych sekcji oraz cała sekcja .cinit)
    w dołączonym pliku jest cały projekt z skompilowanym wyjściem oraz pliki 1.dat(dane z pamięci po wlączeniu zasilania) i 2.dat(dane po wgraniu programu)

    pytanie: Co mi umkneło ? (kompilator nie do końca legalny więc może ogranicza kod, zła współpraca z JTAG'iem - chociaż wielokrotne zgrywanie danych nie pokazuje różnic w tych danych)

    sprzętowo chodzi ok (reset działa, na wejściu kwarcu są oscylacje, zasilanie jest zbocznikowane mnóstwem kondensatorów 100nF i 1uF)

    Dziękuję za pomocne odpowiedzi
    Honza
  • #2 10604587
    nibbit
    Poziom 20  
    Używam CCSv4 i jedynie TMS320F28xxx i u mnie wygląda to tak, że najpierw muszę samemu skopiować sekcje z pamięci ROM do pamięci RAM w ten sposób:
    /* Copy ramfuncs to RAM	*/	
    MemCopy(&RamfuncsLoadStart, &RamfuncsLoadEnd, &RamfuncsRunStart);
  • #3 10607344
    h0nza
    Poziom 15  
    Witaj Nibbit
    rodzina Tms320c672x nie posiada falsha tak jak twój procesor, po zrestartowaniu procesora bios w nim zawarty sprawdza ustawienia wybranych pinów żeby sprawdzić skąd ma ściągnąć program (po I2C, równolegle, SPI) i go ściąga oraz zaczyna wykonywać - ja korzystam z JTAG'a który potrafi kontrolować procesor czyli wgrać program skoczyć do jego początku i zacząć wykonywać, jednak pomimo braku błędów kompilatora programu nie ma w wyznaczonym przez kompilator obszarze.
    więc cokolwiek nie wpiszę do funkcji main i tak się nie wykona

    Wygląda to tak:
    powinno być (tak zwraca kompilator w pliku asemblerowym):
    _main:
    SUB .L2 SP,8,SP ; |9|
    PFUNC0=65535;
    MVKL .S2 0x44000010,B4
    || ZERO .L1 A3 ; |12|
    MVKH .S2 0x44000010,B4
    || SET .S1 A3,0x0,0xf,A3 ; |12|
    STW .D2T1 A3,*B4 ; |12|
    NOP 2
    PDIR0=65535
    ADD .L2 4,B4,B5
    || ZERO .S2 B4 ; |13|

    SET .S2 B4,0x0,0xf,B4 ; |13|
    STW .D2T2 B4,*B5 ; |13|
    NOP 2

    itd....

    a jest tak:
    https://obrazki.elektroda.pl/6372267500_1330366262.jpg

    jest to po prostu niezmieniony obszar pamięci ram (było tam dokładnie to samo po resecie) nie nadpisany przez program, który powinien tam po wgraniu się znaleźć, co ciekawe sekcję .cinit wgrywa całą (wg pliku *.map cinit jest pod adresem 10002cd8 a main który nie jest wgrywany 10002760 - czyli bardzo blisko siebie)

    było by dla mnie bardzo pomocne gdyby ktoś kto dysponuje podobnym sprzętem wgrał program na swój procesor i sprawdził czy zadziała (powinien ustawić stan niski na 16 liniach sygnałowych audio McASP0), lub skompilował go i mi podesłał,
    wyeliminowałbym w ten sposób albo błąd w konfiguracji kompilatora, albo wadliwe działanie JTAG'a albo naprowadziło by mnie to bardziej na inne możliwe rozwiązanie problemu

    Dzięki
    Honza
  • #4 10652742
    h0nza
    Poziom 15  
    Kolejny fragment łamigłówki
    po wrzuceniu wyżej wymienionego kodu do pliku *.gel powoduje prawidłowe wykonanie go podczas nawiązywania komunikacji pomiędzy CSS a zlutowanym układem
    oraz próba zapisania danych do układu za pomocą file/data/load ładuje tylko pierwszą linijkę (4 bajty) zgłaszając błąd ładowania danych od kolejnej linii (która nie jest modyfikowana), tak samo edit/memory/fill powoduje wypełnienie tylko 4 bajtów (ale już bez zgłoszenia błędu)

    ktoś się z tym już spotkał ?

    pozdrawiam
    Honza
REKLAMA