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

OpenOCD v0.1.0 - uruchamianie komend ze skryptów

02 Mar 2009 22:01 2563 18
  • Poziom 27  
    Witam.

    Mam pewnien problem z nową wersją OpenOCD 0.1.0.
    Chodzi o uruchamianie komend ze skryptów, przykładowo chcę uzyc komendy zapisu do flasha :
    Code:
    flash write_bank 0 main.bin 0

    komenda znajduje się w pliku .script dołączanego do pliku konfiguracyjnego stm32.cfg który z kolei wywoływany jest jako argument przy uruchamianiu OpenOCD.
    Niestety OpenOCD zwraca komunikat,ze nie rozpoznaje komendy.
    Jedyną komendą rozpoznawaną jest
    flash bank
    Komendy działają, ale tylko wydawane z poziomu telnetu.
    Oczywiscie działało to w starszych wersjach OpenOCD.
  • Poziom 14  
    Miałem podobny problem, ale z wersją SVN 7xx. Przeszukałem dokumentację, próbowałem różnych wariantów (flash write_bank oraz flash write_image), ale nie przyniosło to rezultatu. Co ciekawe, flash write_bank wydawał się działać (open-ocd dawał komunikaty, że zapisuje, ale zapisu w rzeczywistości nie przeprowadzał), natomiast flash write_image wyrzucał błąd adresu flasha (mimo że poprawnie skonfigurowałem flash bank w pliku cfg).

    Ostatnio ściągnąłem wersję 0.1.0 licząc, że coś się zmieni, ale po Twoim poście widzę, że niekoniecznie musi tak być. Póki co polecam Ci sprawdzenie komendy flash write_image, a ja postaram się (choć pewnie dopiero w weekend) sam powalczyć z 0.1.0. Na tą chwilę działam na jakiejś archaicznej wersji :)
  • Pomocny post
    Specjalista - Mikrokontrolery
    rozwiazanie jest proste, ale niezbyt dobrze udokumentowane

    chodzi o to, ze openocd po przetworzeniu wszystkich plikow ktore mial podane w wywolaniu automatycznie przechodzi do ich wykonania. dopiero wtedy mozna wydawac mu komendy takie jak przez telnet. aby go zmusic do inicjalizacji wczesniej, nalezy wywolac komende init

    mozna to zrobic tak:

    openocd -f interface/...cfg -f target/...cfg -c init -f skrypt.cfg

    albo PRZED komendami 'telnetowymi' trzeba dodac linijke init. wazne jest, aby linijka owa byla PO wszystkich konfiguracjach (typu co z czym sie bedzie komunikowalo i po jakiemu).

    4\/3!!
  • Poziom 27  
    Dzieki za pomoca.
    To moze jeszcze jedno z innej beczki, nie zakładając nowego wątku:
    Czy udało się komuś debugować procesory STM32 przez debugger Eclipse z gdb Codesourcery?
    Jakie komendy powinny być wpisane w ustawieniach debuggera w eclipse?
  • Specjalista - Mikrokontrolery
    pisalem o tym w innym watku - gdb w najnowszego i poprzedniego (2008q3 - obydwie wersje) jest lekko zwalony i nie chce smigac z najnowszym eclipse.

    niemniej jednak gdb to gdb i cortex nie ma tu nic do rzeczy - mozna uzywac zarowno gdb z dowolnej starszej wersji CS, jak i gdb z - na przyklad - yagarto.

    co do ustawien dla cortexa, to w sumie nic nie trzeba wpisywac. zakladajac typowe GDB Hardware Debugging, jedyne co trzeba zrobic 'inaczej' to dokonac resetu komendami:

    mon reset halt

    bo zaptaszkowanie opcji resetu dla tego typu debuggowania cos nie chcialo mi dzialac. pozatym normalnie zaznaczasz ponizej, zeby program po resecie zostal odpalony i zatrzymal sie na main.

    zadnych cudow i zadnych kosmosow.

    testowalem to z primerem, zarowno dla gdb z Ride7 (CS z 2007 roku) jak i dla tego z yagarto.

    4\/3!!
  • Poziom 14  
    Freddie Chopin napisał:
    rozwiazanie jest proste, ale niezbyt dobrze udokumentowane (...)
    4\/3!!


    Dzisiaj pierwszy raz zabrałem się za OpenOCD 0.1.0 i w porównaniu z przeklętą przeze mnie wersją SVN 7xx jest wyśmienicie. W końcu dostarczono porządną dokumentację (widocznie poprzednio natrafiłem na nieaktualną) i stworzenie poprawnych plików konfiguracyjnych zajęło mi ok. 20min. Zresztą na dobrą sprawę nie trzeba samemu tych plików tworzyć - są dołączone 'by default' do instalatora. Dzięki Freddie za nakłonienie mnie do spojrzenia na 'świeższy' release.

    W tym momencie za pomocą Eclipse Ganymede, Yagarto (2.18) i OpenOCD 0.1.0 bezproblemowo kasuję i programuję flash procków STR71x oraz debuguję poprzez GDB w RAMie. Debug we flashu coś się krzaczy, ale sądzę, że to wina bardziej mojego braku czasu na analizę problemu, niż bug'ów software'owych. Swoją drogą mógłbyś mi Freddie streścić/dać link do opisu błędów dot. współpracy Ganymede z GDB, o których wspominałeś wyżej?

    Z góry dziękuję
  • Specjalista - Mikrokontrolery
    jesli uzywasz yagarto to problem nie istnieje. blad wystepuje jedynie przy GDB pochadzacym z codesourcery w wersji 2008q3 (dowolnej z dwoch dostepnych).

    http://www.codesourcery.com/archives/arm-gnu/msg02351.html

    4\/3!!
  • Poziom 28  
    Pozwolę sobie podczepić się pod temat. Otóż mam następujący 'problem'. Programuję sobie STM32 za pomocą OpenOCD i JTAG-lock-pick i zawsze po zaprogramowaniu pamięci procesor nie startuje a OpenOCD zwraca :
    Code:
    target state: halted
    
    target halted due to breakpoint, current mode: Thread
    xPSR: 0x01000000 pc: 0x0800018c


    Skrypt programujący (zaczerpnięty z dema FreeRTOSa) :
    Code:
    init
    
    reset init
    verify_ircapture disable

    halt
    wait halt
    poll
    stm32x mass_erase 0
    flash write_image flash.bin 0x8000000 bin
    reset run
    shutdown

    Programowanie przebiega oczywiście bezproblemowo, tylko program nie chce wystartować i wymaga ręcznego resetu. Da się to jakoś zmienić, aby automatycznie po zaprogramowaniu procesor startował?
  • Poziom 27  
    po komendzie "reset run" spróbuj dodać "resume".
    U mnie działa:)

    Pozdrawiam
  • Poziom 28  
    Faktycznie, działa :) Dzięki!
  • Specjalista - Mikrokontrolery
    Nie prościej tak:

    openocd -f interface/twoj_jtag.cfg -f target/twoj_procek.cfg -c "init" -c "reset halt" -c "flash write_image erase twoj_wsad.bin 0 bin"

    i później ewentualnie dalsze komendy poprzez -c "komenda" ?

    Szczególnie doczepiam się do dwóch rzeczy:

    1. Kasowania całej pamięci, skoro wystarczy skasowac tam gdzie będzie nowy soft

    2. Ładowania przesuniętego obrazu. Czyżby soft był skompilowany bez właściwej mapy pamięci w skrypcie linkera? Po takim przesunięciu wszystkie absolutne odniesienia do pamięci przestają działać, bo openocd ich nie poprawi.

    4\/3!!
  • Poziom 28  
    Ad1. OK.

    Ad 2 :
    Cytat:
    Error: No flash at address 0x00000000

    Skrypty linkera wzięte z Ride, z resztą programy działają, problemem był tylko ten dziwny breakpoint.
  • Specjalista - Mikrokontrolery
    Jakieś dziwne te skrypty [;

    Wrzuć go może tutaj, bo nie mam ride zainstalowanego, a ciekawy jestem co tam jest namieszane.

    4\/3!!
  • Poziom 28  
    Code:
    /*
    
    Linker subscript for STM32F103 definitions with 128K Flash and 20K RAM
    Copyright RAISONANCE 2007
    !!! This file is automatically generated by RIDE !!!
    Do not modify it, as it will be erased at every link.
    You can use, copy and distribute this file freely, but without any waranty.
    */

    /* Memory Spaces Definitions */

    MEMORY
    {
      RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 20K
      FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 128K
      FLASHB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0
      EXTMEMB0 (rx) : ORIGIN = 0x00000000, LENGTH = 0
      EXTMEMB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0
      EXTMEMB2 (rx) : ORIGIN = 0x00000000, LENGTH = 0
      EXTMEMB3 (rx) : ORIGIN = 0x00000000, LENGTH = 0
    }

    /* higher address of the user mode stack */
    _estack = 0x20005000;


    Ale przecież pod adresem 0 jest tylko alias flashu spod 0x08000000 więc niezależnie od skryptów powinno działać.
  • Specjalista - Mikrokontrolery
    już wiem czemu działa [; myślałem, że w STM32 jest tak jak w ARM7 - że jedynie kawałek pamięci jest remapowany w obszar wektorów przerwań. Doczytałem właśnie, że jednak cały FLASH jest dostępny zarówno pod adresem 0 jak i adresem 0x8000000. Właśnie dlatego całość działa.

    Cofam więc to co powiedziałem - układ będzie działał poprawnie, bo inicjalizacją pamięci RAM zajmie się tak czy siak kod.

    Co do skryptu - zapewne ładuje on wszystko do FLASHB1. Jeśli załadujesz całość do FLASH, to przesunięcie nie będzie potrzebne. Swoją drogą - ciekawe czemu nie wywala błędu, że sekcja o rozmiarze 0 jest przepełniona?

    4\/3!!
  • Poziom 28  
    Ładuje raczej do FLASH :
    Code:
    SECTIONS
    
    {
        /* for Cortex devices, the beginning of the startup code is stored in the .isr_vector section, which goes to FLASH */
        .isr_vector :
        {
       . = ALIGN(4);
            KEEP(*(.isr_vector))            /* Startup code */
       . = ALIGN(4);
        } >FLASH
     
        /* for some STRx devices, the beginning of the startup code is stored in the .flashtext section, which goes to FLASH */
        .flashtext :
        {
       . = ALIGN(4);
            *(.flashtext)            /* Startup code */
       . = ALIGN(4);
        } >FLASH
     
       
        /* the program code is stored in the .text section, which goes to Flash */
        .text :
        {
           . = ALIGN(4);
          
            *(.text)                   /* remaining code */
            *(.text.*)                   /* remaining code */
            *(.rodata)                 /* read-only data (constants) */
            *(.rodata*)
            *(.glue_7)
            *(.glue_7t)

           . = ALIGN(4);
           _etext = .;
           /* This is used by the startup in order to initialize the .data secion */
           _sidata = _etext;
        } >FLASH
       
  • Specjalista - Mikrokontrolery
  • Poziom 28  
    Ten błąd wyskoczył jak zrobiłem to co sugerowałeś : flash write_image erase flash.bin 0 bin
    W "mojej" wersji jest wszystko OK.