Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

FreeRtos na LPC2368 i problem z uruchomieniem dema

Rgatek 13 Nov 2009 01:50 3031 16
Computer Controls
  • #1
    Rgatek
    Level 10  
    Witam!
    Od jakiegoś czasu zajmuje się uruchamianiem poszczególnych peryferiów na tym procku i ostatnio postanowiłem ściągnąć FreeRtos-a ver.6.0 aby go uruchomić. Posiadam Eclipse +Yagarto+OpenOCD wiec ponieważ dla tego procka jest demo do Eclipse to myslałem że wszytko pójdzie gładko tymbardziej że wyprowadzenia wyświetlacza LCD zgadzały się z tymi użytymi w demie. Pierwszy problem pojawił się przy kompilacji. Wyskoczył błąd zwiazany z tą linijką w makefilu :
    Code:
    -fno-dwarf2-cfi-asm \ 

    Po wykasowaniu tej linijki wszystko poszło gładko i się skompilowało. Niestety po wgraniu nic się niepojawiło na wyświetlaczu. Po uruchomieniu Debugera otrzymuje:
    Code:
    No symbol "new" in current context.
    
    Current language:  auto; currently asm
    target remote:3333
    ?? () at boot.s:139
    139      b     _start                  /* reset - _start         */
    monitor sleep 500
    monitor arm7_9 force_hw_bkpts enable
    monitor sleep 500
    monitor soft_reset_halt
    delete
    monitor sleep 500
    b main
    Breakpoint 1 at 0x46c: file main.c, line 151.
    monitor sleep 500
    c
    Warning:
    Cannot insert breakpoint 1.
    Error accessing memory address 0x46c: (undocumented errno -1).

    monitor sleep 500
    delete
    No source file named RTOSDemo.elf.

    W GDB w Threat otrzymuje <sysmbol is not available>0x00000
    Gdb wywołuje
    Code:
    target remote:3333
    
    monitor sleep 500
    monitor arm7_9 force_hw_bkpts enable
    monitor sleep 500
    monitor soft_reset_halt
    delete
    monitor sleep 500
    b main
    monitor sleep 500
    c
    monitor sleep 500
    delete

    Próbowałem różnych możliwości co do wywołań GDB ale było tylko gorzej...
    Co do scriptu zapisu do flash w OpenOCD mam następujący:
    Code:
    set _file C:\\E\\Dev\\FreeRTOS\\Demo\\ARM7_LPC2368_Eclipse\\RTOSDemo\\RTOSDemo.bin
    
    echo "Script"
    arm7_9 dcc_downloads enable
    init
    reset halt
    wait_halt
    sleep 10
    poll
    flash probe 0
    #flash protect 0 0 26 'off'
    flash erase_sector 0 0 26
    flash write_bank 0 $_file 0x0
    reset run
    sleep 10
    shutdown

    i zapis chyba ok:
    Code:
    Open On-Chip Debugger 0.2.0 (2009-07-18-09:50) Release
    
    $URL: http://svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.2.0/src/openocd.c $
    For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
    parport port = 888
    jtag_speed: 0
    RCLK - adaptive
    jtag_nsrst_delay: 200
    jtag_ntrst_delay: 200
    Script
    dcc downloads are enabled
    Error: Translation from khz to jtag_speed not implemented
    Info : JTAG tap: lpc2368.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
    Info : JTAG Tap/device matched
    Warn : EmbeddedICE version 7 detected, EmbeddedICE handling might be broken
    Info : JTAG tap: lpc2368.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
    Info : JTAG Tap/device matched
    Warn : 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: Supervisor
    cpsr: 0x200000d3 pc: 0x00008a5c
    background polling: on
    TAP: lpc2368.cpu (enabled)
    target state: halted
    target halted in ARM state due to debug-request, current mode: Supervisor
    cpsr: 0x200000d3 pc: 0x00008a5c
    flash 'lpc2000' found at 0x00000000
    erased sectors 0 through 26 on flash bank 0 in 1.301872s
    Warn : Verification will fail since checksum in image(0xe1a00000) written to flash was different from calculated vector checksum(0xb4c03c0a).
    Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.
    wrote  68604 byte from file C:\E\Dev\FreeRTOS\Demo\ARM7_LPC2368_Eclipse\RTOSDemo\RTOSDemo.bin to flash bank 0 at offset 0x00000000 in 6.248986s (10.721114 kb/s)
    Info : JTAG tap: lpc2368.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
    Info : JTAG Tap/device matched

    Prosze o pomoc lub jakieś sugestie bo już kilka dni z tym walcze i kończą mi się już nerwy...

    Jeszcze mam pytanie czy może ktoś nie mógłby mi przesłać na poczte instalki OpenOCD 0.1.0? Ja mam 0.2.0 i jest strasznie niekompatybilne a na sieci niema starszej...mail gatkowski86(małpa)o2.pl napewno oszczędziłoby mi to sporo czasu.
  • Computer Controls
  • #2
    Freddie Chopin
    MCUs specialist
    Jest niekompatybilna, tylko po co chcesz używać starych i totalnie zbędnych poleceń? Na przykład "monitor arm7_9 force_hw_bkpts enable" jest tak czy siak wartością domyślną, więc po co jeszcze raz podawać?

    Wejdź tu https://www.elektroda.pl/rtvforum/topic1313509.html i spróbuj zrobić tak jak jest napisane tam... Włącznie z pluginem i konkretnymi poleceniami dla GDB/OpenOCD.

    4\/3!!
  • #3
    Rgatek
    Level 10  
    Wykasowałem tą instrukcje ale niewiele się zmieniło. Spróbowałem jeszcze innej opci - włączyłem H-JTAG-a i przy wykrywaniu pokazało się okienko:

    FreeRtos na LPC2368 i problem z uruchomieniem dema

    Po kilku próbach z resetowaniem udało mi się wyczyścić pamięć - Eraze i wgrałem soft H-JTAG-iem. Tym razem normalnie wykrywał kostke. Po uruchomieniu debugera otrzymałem:
    Code:
    Open On-Chip Debugger 0.2.0 (2009-07-18-09:50) Release
    
    $URL: http://svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.2.0/src/openocd.c $
    For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
    parport port = 888
    jtag_speed: 0
    RCLK - adaptive
    jtag_nsrst_delay: 200
    jtag_ntrst_delay: 200
    Error: Translation from khz to jtag_speed not implemented
    Info : JTAG tap: lpc2368.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
    Info : JTAG Tap/device matched
    Warn : EmbeddedICE version 7 detected, EmbeddedICE handling might be broken
    Info : JTAG tap: lpc2368.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
    Info : JTAG Tap/device matched
    Info : accepting 'gdb' connection from 0
    target state: halted
    target halted in Thumb state due to debug-request, current mode: Supervisor
    cpsr: 0x000000f3 pc: 0x7fffe158
    Warn : acknowledgment received, but no packet pending
    Info : Flash Manufacturer/Device: 0x0000 0x0000
    Error: Could not probe bank: no QRY
    Error: auto_probe failed -900

    Info : dropped 'gdb' connection - error -400
    Info : accepting 'gdb' connection from 0
    Warn : acknowledgment received, but no packet pending
    Info : Flash Manufacturer/Device: 0x0000 0x0000
    Error: Could not probe bank: no QRY
    Error: auto_probe failed -900

    requesting target halt and executing a soft reset
    target state: halted
    target halted in ARM state due to debug-request, current mode: Supervisor
    cpsr: 0x000000d3 pc: 0x00000000
    Warn : memory write caused data abort (address: 0x0000046c, size: 0x2, count: 0x1)
    Warn : memory write caused data abort (address: 0x0000046c, size: 0x2, count: 0x1)

    I debuger stanął...powtórzyłem wiec i ciągle było 27%. Postanowiłem wgrać spowrotem przez openocd. I teraz debuger się uruchamia do końca ale efekt jest taki sam jak na samym początku:
    Code:
    Open On-Chip Debugger 0.2.0 (2009-07-18-09:50) Release
    
    $URL: http://svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.2.0/src/openocd.c $
    For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
    parport port = 888
    jtag_speed: 0
    RCLK - adaptive
    jtag_nsrst_delay: 200
    jtag_ntrst_delay: 200
    Error: Translation from khz to jtag_speed not implemented
    Info : JTAG tap: lpc2368.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
    Info : JTAG Tap/device matched
    Warn : EmbeddedICE version 7 detected, EmbeddedICE handling might be broken
    Info : JTAG tap: lpc2368.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
    Info : JTAG Tap/device matched
    Info : accepting 'gdb' connection from 0
    Error: timed out while waiting for target halted
    Warn : acknowledgment received, but no packet pending
    Error: Target not halted
    Error: auto_probe failed -304

    Warn : target not halted
    Info : dropped 'gdb' connection - error -400
    Info : accepting 'gdb' connection from 0
    Error: timed out while waiting for target halted
    Warn : acknowledgment received, but no packet pending
    Error: Target not halted
    Error: auto_probe failed -304

    Warn : target not halted
    requesting target halt and executing a soft reset
    Error: Failed to halt CPU after 1 sec
    Warn : target not halted
    Info : can't add breakpoint while target is running (BPID: 0)
    Warn : target not halted
    Warn : target not halted
    Warn : target not halted
    Warn : target not halted
    Warn : target not halted

    Co to może być?
  • Computer Controls
  • #5
    you-zek
    Level 15  
    Moje kłopoty z debugowaniem i programowaniem przy pomocy jtag wiązały się z nieprawidłowym połączeniem resetów. Mam interfejs freddiego dwa osobne resety - dla jtaga i dla procka. Polecam sprawdzić. Nie przejrzałem dokładnie not aplikacyjnych i połączyłem na czuja. Kompletnie źle. Cuda wianki się działy a sąsiadom uszy więdły.
  • #6
    Rgatek
    Level 10  
    Niewiem czy to będzie przyczyna ale jeżeli projekt jest dobrze skompilowany to być może coś ważnego nie dodałem lub wpisałem za dużo w pliku *.cfg gdyż oryginalny był pod OpenOCD 0.1.0 a jak mam OpenOCD 0.2.0.
    Oto mój:
    Code:
    #daemon configuration
    
    telnet_port 4444
    gdb_port 3333

    #interface
    interface parport
    parport_port 0x378
    parport_cable wiggler
    jtag_speed 5


    #delays on reset lines
    jtag_nsrst_delay 200
    jtag_ntrst_delay 200

    # LPC2000 -> SRST causes TRST
    reset_config trst_and_srst srst_pulls_trst


    if { [info exists CHIPNAME] } {
       set  _CHIPNAME $CHIPNAME
    } else {
       set  _CHIPNAME lpc2368
    }
    if { [info exists ENDIAN] } {
       set  _ENDIAN $ENDIAN
    } else {
       set  _ENDIAN little
    }
    if { [info exists CPUTAPID ] } {
       set _CPUTAPID $CPUTAPID
    } else {
       set _CPUTAPID 0x4f1f0f0f
    }
    #jtag scan chain
    #format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
    jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID

    #target configuration
    set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
    target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm7tdmi-s_r4

    $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x40000000 -work-area-size 0x40000 -work-area-backup 0
    $_TARGETNAME configure -event reset-init {   
       # Force target into ARM state
       soft_reset_halt   
       #do not remap 0x0000-0x0020 to anything but the flash
       #mwb 0xE01FC040 0x01
    }
    #flash configuration
    flash bank lpc2000 0x0 0x80000 0 0 0 lpc2000_v2 12000 calc_checksum
    flash bank cfi 0x80000000 0x400000 2 2 0

    a to orginał z RTOSDemo pod openocd 0.1.0:

    Code:
    #daemon configuration
    
    telnet_port 4444
    gdb_port 3333

    #interface
    interface parport
    parport_port 0x378
    parport_cable wiggler
    jtag_speed 2

    #use combined on interfaces or targets that can't set TRST/SRST separately
    reset_config trst_and_srst srst_pulls_trst

    #jtag scan chain
    #format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
    jtag_device 4 0x1 0xf 0xe

    #target configuration
    daemon_startup reset

    #target <type> <startup mode>
    #target arm7tdmi <reset mode> <chainpos> <endianness> <variant>
    target arm7tdmi little run_and_init 0 arm7tdmi-s_r4
    run_and_halt_time 0 30

    working_area 0 0x40000000 0x40000 nobackup

    #flash configuration
    flash bank lpc2000 0x0 0x80000 0 0 0 lpc2000_v2 12000 calc_checksum
    flash bank cfi 0x80000000 0x400000 2 2 0

    Fakt że dwóch poleceń niewykorzystuje ale niewiem czy są one potrzebne bo inny projekt bezproblemu się wgrywa i chula jak trzeba.
    Co o tym myślicie?
    Opcje zmiany prędkości na niewiele się zdały chociaż rzeczywiście <jtag_speed 2> będzie lepiej. Ciagle wyświetla się ten sam błąd co wcześniej a jeżeli jakieś komendy wytne to jedynie gdb uruchamia się do końca i mam <sysmbol is not available>0x000000
  • #7
    you-zek
    Level 15  
    Ponawiam propozycję sprawdzenia poprawności połączenia sprzętu. Miałem identyczne objawy jak ty.
  • #8
    Rgatek
    Level 10  
    Ok ale debugowanie ogólnie działa dla innych projektów tylko dla FreeRtos coś nie idzie i mi sie wydaje że dlatego że coś przegapiłem w konfiguracji openocd. Mam wersje 0.2.0 i nie wszystkie komendy z openocd 0.1.0 udało mi się przetłumaczyć na 0.2.0...jesli nie to wychodziłoby że coś źle kompiluje ale to raczej niemożliwe...
  • #9
    you-zek
    Level 15  
    U mnie też ogólnie działało dopóki nie odpaliłem jednego z peryferiów. Jeżeli JTAG nie może zatrzymać procka - to coś jest nie tak ze sprzętem. JTAG - jak na mój stan wiedzy - ma władzę absolutną. Więc nie ma możliwości aby program miał jakiś wpływ na sprzętowy kontroler JTAG. No chyba że przez jakieś rejestry czy przez komendy... Najczęściej przyczyna problemów jest prozaiczna. Wątpię aby twój procek został opętany przez niewiadomego złego ducha procka którego ktoś kiedyś zabił zbyt wysokim napięciem ;) Z tego co opisujesz - wymiana danych przebiega prawidłowo. Stawiam na to, że debugger próbuje ustawić procka lub interfejs w stan domyślny (reset) ale nie udaje mu się to. Sprawdź resety. Zerknij na schematy płyt ewaluacyjnych. Ja tego nie zrobiłem - połączyłem resety byle jak - debugger działał bez zarzutu aż do momentu... Korzystamy z innej rodziny uC innego producenta. Dlatego nie napiszę co to spowodowało. W Twoim wypadku taki stan rzeczy może powodować inna część sprzętu. Przyczyna problemów - stawiam na to samo co u mnie.

    Aha. Ciekawostka - w rodzinie STM32 zatrzymując tok programu debuggerem - no teoretycznie powinniśmy zatrzymywać cały procek. JEdnak nie - na wyjściu PWM nadal mamy prawidłowy sygnał - timer kontynuuje pracę. Działa też DMA. Cuda wianki. Nie wszystko jest tak jak nam się wydaje. Jedyną pewność absolutnej kontroli nad prockiem daje RESET. Ale to też nie do końca bo backup domain nie jest resetowane tym sygnałem ;P
  • #10
    Freddie Chopin
    MCUs specialist
    you-zek wrote:
    Aha. Ciekawostka - w rodzinie STM32 zatrzymując tok programu debuggerem - no teoretycznie powinniśmy zatrzymywać cały procek. JEdnak nie - na wyjściu PWM nadal mamy prawidłowy sygnał - timer kontynuuje pracę. Działa też DMA. Cuda wianki.

    Jeśli jeszcze o tym nie wiesz, to zainteresuj się rejestrem DBGMCU->CR

    4\/3!!
  • #11
    you-zek
    Level 15  
    Teraz już wiem. Dzięki. To potwierdza to co mówiłem.
    you-zek wrote:
    Nie wszystko jest tak jak nam się wydaje.

    Wydaje się, że procek się zatrzymuje. Guzik prawda. Wydaje się że reset resetuje. Guzik prawda. Wydaje się koledze Rgatek (jest on nawet pewny), że dobrze połączył interfejs. To się okaże jak przyłoży się do sprawdzenia.
    Jestem pewny że mam rację ... hihih

    Chłopie po prostu to sprawdź. Porównaj z tym jak zrobiono to w płytach producenta scalaków. Ci ludzie najlepiej wiedzą co mają i jak to obsłużyć.
  • #12
    Rgatek
    Level 10  
    Witam! Po długich męczarniach udało się Uruchomić FreeRtos-a:) Postanowiłem nie męczyć się z wersją Demo tylko samemu utworzyć prostą obsługę - jedno zadanie - miganie diody. Bazując na wcześniejszym moim skrypcie do OpenOCD 2.0 po skompilowaniu udało się wgrać i dioda od razu ruszyła i zaczęła mrugać:) No dumny jestem z siebie bo naprawde sporo nerwów mi to zabrało. W załączniku przesyłam moją wersje na LPC2368. Teraz zabieram się za uruchomienie 3 diodek :)
    Attachments:
  • #13
    Rgatek
    Level 10  
    Diodki świecą :) Dodatkowo udało mi się uruchomić wyświetlacz i zrobić prostą komunikacje wyświetlacza z diodką na bazie kolejki. Wszystko fajnie działa. Teraz chciałbym spróbować przerwań, tylko wyczytałem że tu trzeba trochę pokombinować...mógłby ktoś na jakimś prostym przykładzie zademonstrować jak we FreeRtos-ie działają przerwania? Może jakiś kawałek listingu żeby mi to sprawniej poszło bo na sieci jakoś nie mogę znaleźć żadnych informacji...z góry dzięki!
  • #14
    arrevalk
    Level 25  
    Rgatek wrote:
    Może jakiś kawałek listingu żeby mi to sprawniej poszło bo na sieci jakoś nie mogę znaleźć żadnych informacji...z góry dzięki!


    Słabo szukasz, w przykładach do freeRTOS np ARM7_LPC2138_ROWLEY masz bardzo prosty przykład wykorzystania przerwania zewnętrznego. Kod jest jasny. Przerwanie vButtonISR*() jest powiązane z taskiem vButtonHandlerTask() i w nim jest rejestrowane. W funckji main() jest rejestrowany semafor binarny którym task jest budzony z przerwania. A powód dla którego jedna z funkcji korzysta z atrybutu "naked" jest Tu.
  • #15
    Rgatek
    Level 10  
    Witam!
    Ostatnio opanowywałem przerwania i komunikacje między nimi. Wszystko fajnie działa :)
    Teraz chciałem się nauczyć jak tworzyć dynamiczne tablice pod FreeRtosem. Próbował może ktoś tego i mógłby się podzielić?
    Ja tylko wiem że jest taka funkcja:
    Code:
    void *pvPortMalloc( size_t xWantedSize )
    ale czy mam jej urzywać tak jak funkcje malloc? Czy może tu jest jakiś inny mechanizm..Prosze o pomoc
  • #16
    arrevalk
    Level 25  
    Rgatek wrote:

    Code:
    void *pvPortMalloc( size_t xWantedSize )
    [...]czy mam jej używać tak jak funkcje malloc? Czy może tu jest jakiś inny mechanizm..Prosze o pomoc

    Korzystasz z niej dokładnie tak samo jak z funkcji malloc() z bibliotek standardowych czyli:
    Code:

        int *dynamiczna_tablica =(int *) pvPortMalloc(20 *sizeof(int));
        pvPortFree(dynamiczna_tablica);
        dynamiczna_tablica = 0;
        dynamiczna_tablica = (int *) pvPortMalloc(40 * sizeof(int));
        //itd...

    Upewnij się jaki schemat przydzielania pamięci wykorzystuje twój port freeRTOS (który z plików jest załączony: heap_1.c, heap_2.c czy heap_3.c).
    Pierwszy to najprostszy i nie pozwala na zwolnienie przydzielonej pamięci(AVR,8051,PIC).
    Drugi nieco bardziej skomplikowany pozwala na zwalnianie pamięci, ale nie pozwala na łączenie sąsiadującyh bloków pamięci (ARM7)
    I ostatni to po prostu wywołanie malloc() (x86).
    Proponuje poczytać artykuł ze strony freeRTOS w dziale More Advanced... -> Memory Management. W nim są wyjaśnione wszelkie plusy i minusy poszczególnych metod.
  • #17
    Rgatek
    Level 10  
    Dzieki za odpowiedz! Zaraz zabieram sie za testowanie:) Ja narazie koszystam ze schematu heap_2. Pozdrawiam!