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

[OpenOCD][LPC1754]Problem z wgraniem programu do flash.

29 Gru 2010 15:13 4305 22
  • Poziom 33  
    Od jakiegoś czasu próbuje wgrać program przez JTAG'a używając OpenOCD i GDB.
    Niestety program albo nie trafia gdzie powinien albo w ogóle się nie wgrywa.
    Przy zaprogramowaniu uC przez FlashMagic debugowanie kodu działa bezproblemowo.
    GDB jest z wersji CodeSourcery 2010q1 (najnowsza w ogóle nie działa).

    Dane z OpenOCD
    Code:
    Open On-Chip Debugger 0.4.0 (2010-12-28-14:49)
    
    Licensed under GNU GPL v2
    For bug reports, read
       http://openocd.berlios.de/doc/doxygen/bugs.html
    jtag_nsrst_delay: 400
    jtag_ntrst_delay: 400
    trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
    400 kHz
    Info : device: 4 "2232C"
    Info : deviceID: 67330064
    Info : SerialNumber: FTSMOUFWA
    Info : Description: Amontec JTAGkey A
    Info : clock speed 400 kHz
    Info : JTAG tap: lpc1754.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
    Info : lpc1754.cpu: hardware has 6 breakpoints, 4 watchpoints
    Info : accepting 'gdb' connection from 0
    Warn : acknowledgment received, but no packet pending
    undefined debug reason 6 - target needs reset
    Info : JTAG tap: lpc1754.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
    target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0x61000000 pc: 0x0000019e msp: 0x10000c50


    GDB (po wgraniu programu przez bootloader)
    Code:
    target remote localhost: 3333
    
    0x00000000 in g_pfnVectors ()
    monitor reset
    JTAG tap: lpc1754.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
    monitor halt
    target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0x61000000 pc: 0x0000019e msp: 0x10000c50
    load
    Loading section .text, size 0x9be8 lma 0x0
    Loading section .data, size 0x8 lma 0x9be8
    Start address 0x0, load size 39920
    Transfer rate: 5 KB/sec, 9980 bytes/write.


    Z komendą flash write image
    Code:
    target remote localhost: 3333
    
    0x00000000 in g_pfnVectors ()
    monitor reset
    JTAG tap: lpc1754.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
    monitor halt
    target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0xa1000000 pc: 0x1fff0ba2 msp: 0x10003fb8
    monitor flash write_image erase unlock main.hex 0 ihex
    auto erase enabled
    auto unlock enabled
    Ignoring packet error, continuing...
    Reply contains invalid hex digit 116


    Gdzieś wyczytałem że ostatni komunikat związany jest m.in z set remotetimeout
    Code:
    target remote localhost: 3333
    
    0x00000000 in g_pfnVectors ()
    set remotetimeout 20
    monitor reset
    JTAG tap: lpc1754.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
    monitor halt
    target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0xa1000000 pc: 0x1fff0ba2 msp: 0x10003fb8
    monitor flash write_image erase unlock main.hex 0 ihex
    auto erase enabled
    auto unlock enabled
    wrote 40960 bytes from file main.hex in 7.189000s (5.564 kb/s)


    Nie mam już pomysłów co może być nie tak.
    Przełączanie za każdym razem uC w tryb bootloadera jest dosyć uciążliwe.
    :|. Może ktoś odpalił wgrywanie programu przez OpenOCD do tej rodziny uC i działa mu bez problemu?
  • Computer Controls
  • Pomocny post
    Specjalista - Mikrokontrolery
    Nie bardzo rozumiem po co masz układ w trybie bootloadera podczas programowania. No i chyba nigdy nie zrozumiem po co rozdzielać komendę "halt" od komendy "reset", skoro jest "reset halt"...

    Najnowsze GDB działa z OpenOCD i Eclipse bezproblemowo, wystarczy tylko ściągnąć NOWE Eclipse i NOWE wtyczki przeznaczone do tej właśnie wersji Eclipse.
    https://www.elektroda.pl/rtvforum/viewtopic.php?p=8653959#8653959

    Nie pokazałeś jak uruchamiasz OpenOCD, z jakimi plikami konfiguracyjnymi, co w nich zmieniałeś itd.

    No i w sumie to nie wiem na czym polega problem, bo w temacie jest problem z wgraniem programu, a potem pokazujesz 2 przykłady, że się wgrywa...

    W pliku konfiguracyjnym dla LPC1768 należy wstawić prawidłową częstotliwość dla tego układu. Proponuję zrobić tak w pliku konfiguracyjnym lpc1768.cfg:
    1. reset_config ustaw na "reset_config trst_and_srst separate"
    2. na końcu częstotliwość układu ustawiasz na 4MHz
    flash bank $_FLASHNAME lpc2000 0x0 0x80000 0 0 $_TARGETNAME lpc1700 4000 calc_checksum
    3. włączasz OpenOCD
    4. przez telnet (aby wyeliminować problemy z GDB) wydajesz dwie komendy: "reset halt", a następnie "flash write_image ..."

    Skoro masz inny układ niż LPC1768 to jeszcze musisz ustawić właściwą wielkość pamięci flash:
    flash bank $_FLASHNAME lpc2000 0x0 0x80000 0 0 $_TARGETNAME lpc1700 4000 calc_checksum
    i RAMu:
    $_TARGETNAME configure -work-area-phys 0x10000000 -work-area-size 0x8000 -work-area-backup 0

    4\/3!!
  • Poziom 33  
    Freddie Chopin napisał:
    Nie bardzo rozumiem po co masz układ w trybie bootloadera podczas programowania.


    Nie jest, po prostu tam lądował "PC".

    Freddie Chopin napisał:
    No i chyba nigdy nie zrozumiem po co rozdzielać komendę "halt" od komendy "reset", skoro jest "reset halt"...


    Ponieważ dla "reset_config trst_and_srst srst_pulls_trst" tylko w taki sposób można było zresetować i zatrzymać rdzeń. Niestety w pliku lpc1768.cfg (na którym się wzorowałem) tak to jest ustawione.....jak i dla chyba całej rodziny LPC2000.

    Generalnie po ściągniąciu eclipse Helios oraz pluginu GDB do niego, ładowanie programu działa poprawnie (choć błędy są podobne jak wcześniej).
    Przedtem korzystałem z wersji Genymade i Zylin'a.

    Freddie Chopin napisał:

    No i w sumie to nie wiem na czym polega problem, bo w temacie jest problem z wgraniem programu, a potem pokazujesz 2 przykłady, że się wgrywa...


    No właśnie, pokazywał że ok a w rzeczywistości programu we flash'u nie było.

    Freddie Chopin napisał:

    W pliku konfiguracyjnym dla LPC1768 należy wstawić prawidłową częstotliwość dla tego układu. Proponuję zrobić tak w pliku konfiguracyjnym lpc1768.cfg:
    1. reset_config ustaw na "reset_config trst_and_srst separate" .


    I generalnie to należało zmienić.

    Jeszcze sprawdzę czy z Zylin'em działa poprawnie i dam znać.
    _____________________________

    Z Zylin'em również jest wszystko w porządku.
    Okazało się że w likwidowaniu błędów m.in.

    Code:
    Warn : Verification will fail since checksum in image (0x00000000) to be written to flash is different from calculated vector checksum (0xefff59ba).
    
    Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.

    wykasowałem "calc_checksum" w
    Code:
    set _FLASHNAME $_CHIPNAME.flash
    
    flash bank $_FLASHNAME lpc2000 0x0 0x20000 0 0 $_TARGETNAME lpc1700 8000 calc_checksum
    .
    a jest to potrzebne :D.....jak się okazuje.
  • Computer Controls
  • Specjalista - Mikrokontrolery
    Ponieważ to jest dosyć istotne, czy mógłbyś potwierdzić, że gdy jest "reset_config separate" (gdy nie ma "srst_pulls_trst") to wszystko działa jak należy? Częściowo dzięki mojej inicjatywie opcja ta została usunięta w kodzie dla LPC2xxx, ale że nie mam LPC17xx, to tam nie ruszałem, więc jakbyś mógł sprawdzić to byłbym wdzięczny. Jeśli i tutaj wszystko jest OK bez tej opcji, to się ją wywali (;

    4\/3!!
  • Poziom 33  
    Mogę jedynie potwierdzić że z opcją "srst_pulls_trst" nie można w ogóle uC zaprogramować.
    Gdy zmienimy na "separate" uC ładnie się "programuje".
  • Specjalista - Mikrokontrolery
    Jeśli Twój kod ustawia PLLa (a pewnie ustawia), to jeśli masz srst_pulls_trst rdzeń zdąży wykonać trochę kodu zanim się zatrzyma i dojdzie do programowania. W takim wypadku częstotliwość rdzenia podawana do OpenOCD jest inna niż ta rzeczywista, więc programowanie Flasha może się nie udać.

    Rozwiązać to można na dwa sposoby:
    1. Podać do OpenOCD prędkość rdzenia jaką będzie miał podczas programowania
    2. W programie na samym początku (początek startupa) dodać prostą pętlę która zatrzyma układ na jakiś czas, tak aby OpenOCD mogło go zatrzymać.

    Oczywiście jak nie ma srst_pulls_trst to nie ma takiej potrzeby, ale chciałbym wiedzieć jaka jest podstawowa przyczyna problemu...

    4\/3!!
  • Poziom 33  
    Jak zwykle masz rację.

    Przy ustawieniu odpowiedniej prędkości flash'a w
    Code:
    flash bank $_FLASHNAME lpc2000 0x0 0x20000 0 0 $_TARGETNAME lpc1700 60000 calc_checksum

    przy opcji "srst_pulls_trst"
    udaje się poprawnie zaprogramować uC lecz PC ląduje w HardFault i trzeba na nowo odpalać GDB.
    Następny problem z w.w ustawieniami to taki że po odpaleniu GDB nie udaje się zatrzymać go w "main", zgodnie z ustawieniami.
    Drugi sposób (dodanie pętli opóźniającej w startup'ie) też działa ale również rdzeń ląduje w HardFault.

    Zastanawia mnie jeszcze dlaczego PC zatrzymuje się pod tym dziwnym adresem
    Code:
    Info : JTAG tap: lpc1754.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
    
    target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
    Warn : Invalid ACK 0x6 in JTAG-DP transaction


    Nie wpływa to jednak na funkcjonowanie debugowania.
  • Specjalista - Mikrokontrolery
    markosik20 napisał:
    Przy ustawieniu odpowiedniej prędkości flash'a w
    Code:
    flash bank $_FLASHNAME lpc2000 0x0 0x20000 0 0 $_TARGETNAME lpc1700 60000 calc_checksum

    przy opcji "srst_pulls_trst"
    udaje się poprawnie zaprogramować uC lecz PC ląduje w HardFault i trzeba na nowo odpalać GDB.
    Następny problem z w.w ustawieniami to taki że po odpaleniu GDB nie udaje się zatrzymać go w "main", zgodnie z ustawieniami.
    Drugi sposób (dodanie pętli opóźniającej w startup'ie) też działa ale również rdzeń ląduje w HardFault.

    To lądowanie w hard-fault może być niezwiązane. Na STM32 też się tak czasem dzieje (powiedzmy że w 5% przypadków) - zwłaszcza w sytuacji wgrywania kodu innego niż był poprzednio.

    Tak jeszcze dla pewności - jeśli nie ma "srst_pulls_trst" to wskakiwanie w hard-fault po programowaniu nie następuje?

    Cytat:
    Zastanawia mnie jeszcze dlaczego PC zatrzymuje się pod tym dziwnym adresem
    Code:
    Info : JTAG tap: lpc1754.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
    
    target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
    Warn : Invalid ACK 0x6 in JTAG-DP transaction


    Nie wpływa to jednak na funkcjonowanie debugowania.

    Ten adres wygląda mi na obszar bootloadera, który - jak wiadomo - na LPC jest uruchamiany zawsze na początku, przed kodem użytkownika. LPC to bardzo zagadkowe układy [;

    4\/3!!
  • Poziom 33  
    Freddie Chopin napisał:
    Tak jeszcze dla pewności - jeśli nie ma "srst_pulls_trst" to wskakiwanie w hard-fault po programowaniu nie następuje?

    Dokładnie, nie następuje, po zaprogramowaniu PC ustawia się tam gdzie powinien zgodnie z ustawieniami.

    Z tym bootloaderem to rzeczywiście dziwna sprawa, gdyż jeżeli przestawię zworę to wgrany program w ogóle się nie wykonuje (włącza się bootloader) co jest właściwą oznaką. Przy prawidłowym ustawieniu zwory, podczas startu GDB po resecie rdzenia, PC ma wartość wskazującą na bootloader (ciekawe jest to że czasami ta wartość jest prawidłowa) a pomimo tego program debugowany startuje prawidłowo.
  • Poziom 24  
    Podepnę się pod temat. Staram się zaprogramować LPC1756 takim programem
    Code:
    #include"lpc17xx.h"
    

    #define LED_P 30

    int
    main()
    {
       //SystemInit();

       LPC_GPIO0->FIODIR |= 1<<LED_P;
       LPC_GPIO0->FIODIR |= 1<<29;
       LPC_GPIO0->FIODIR |= 0xff000000;

       while(1)
       {
          LPC_GPIO0->FIOSET = 1<<LED_P;
          LPC_GPIO0->FIOSET = 1<<29;
          LPC_GPIO0->FIOSET = 0xff000000;
          //for (int i = 0; i < 1000000; i++);
          //LPC_GPIO0->FIOCLR = 1<<LED_P;
          //for (int i = 0; i < 1000000; i++);
       }
       return 0;
    }

    OpenOCD daje taki wynik
    Cytat:
    Open On-Chip Debugger 0.4.0 (2010-02-22-19:05)
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.berlios.de/doc/doxygen/bugs.html
    jtag_nsrst_delay: 200
    jtag_ntrst_delay: 200
    trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
    500 kHz
    Info : clock speed 500 kHz
    Info : JTAG tap: lpc1756.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
    Info : lpc1756.cpu: hardware has 6 breakpoints, 4 watchpoints
    Info : JTAG tap: lpc1756.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
    target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
    auto erase enabled
    Info : Padding image section 0 with 32768 bytes
    wrote 65536 bytes from file Z:/ARM/workspace/test/Debug/test.hex in 30.043200s (2.130 kb/s)
    Info : JTAG tap: lpc1756.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
    shutdown command invoked


    No i nie udaje się. Dioda podłączona do portu się nie zaświeca. Proszę o sugestie, jak mogę rozwiązać swój problem lub co robię źle.
  • Specjalista - Mikrokontrolery
    To nie jest moim zdaniem problem z OpenOCD, tylko masz źle skompilowany program. Po tym co mi podesłałeś widzę, że cały kod znajduje się pod jakimiś abstrakcyjnymi adresami, brakuje tablicy wektorów itd.

    Wrzuć cały projekt (kod, startup, skrypt linkera, makefile).

    4\/3!!
  • Specjalista - Mikrokontrolery
    Nie wiem z jakiego to środowiska, ale nie ma tam ani skryptu linkera, ani Makefile'a, więc niestety nie jestem w stanie Ci z tym pomóc poza stwierdzeniem, że całość jest źle skonfigurowana.

    4\/3!!
  • Poziom 24  
    Ja to kompiluję w eclipse.

    Cytat:

    **** Build of configuration Debug for project test ****

    cs-make all
    Building file: ../main.cpp
    Invoking: ARM Sourcery Windows GCC C++ Compiler
    arm-none-eabi-g++ -O0 -Wall -Wa,-adhlns="main.o.lst" -fno-exceptions -fno-rtti -c -fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -mcpu=cortex-m3 -mthumb -g3 -gdwarf-2 -o"main.o" "../main.cpp"
    In file included from ../main.cpp:1:
    ../lpc17xx.h:103: warning: ignoring #pragma anon_unions
    ../lpc17xx.h:843: warning: ignoring #pragma no_anon_unions
    Finished building: ../main.cpp

    Building target: test.elf
    Invoking: ARM Sourcery Windows GCC C++ Linker
    arm-none-eabi-g++ -Wl,-Map,test.map -mcpu=cortex-m3 -mthumb -g3 -gdwarf-2 -o"test.elf" ./core_cm3.o ./main.o ./system_LPC17xx.o
    c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/bin/ld.exe: warning: cannot find entry symbol _start; defaulting to 0000800c
    Finished building target: test.elf

    Invoking: ARM Sourcery Windows GNU Create Flash Image
    arm-none-eabi-objcopy -O ihex test.elf "test.hex"
    Finished building: test.hex

    Invoking: ARM Sourcery Windows GNU Create Listing
    arm-none-eabi-objdump -h -S test.elf >"test.lst"
    Finished building: test.lst

    Invoking: ARM Sourcery Windows GNU Print Size
    arm-none-eabi-size --format=berkeley test.elf
    text data bss dec hex filename
    1708 20 4 1732 6c4 test.elf
    Finished building: test.siz

  • Specjalista - Mikrokontrolery
    No ale przecież nie masz skryptu linkera - bez tego to po prostu nie ma prawa działać... A ta wtyczka z której korzystasz kompiluje pliki assemblera tylko jeśli mają rozszerzenie .S, a nie .s.

    Zestaw porad jest taki:
    https://www.elektroda.pl/rtvforum/topic1313509.html
    https://www.elektroda.pl/rtvforum/topic1339518-0.html

    Weź przykładowy projekt dla STM32, wstaw do niego tylko swoją funkcję main() (no i potrzebny dla niej nagłówek dla LPC17xx). W skrypcie linkera ustaw tylko adresy i rozmiary pamięci stosowne dla Twojego układu. Startupa i makefile'a nie musisz zmieniać w ogóle. Tablica wektorów oczywiście nie będzie poprawna, ale na tym etapie nie ma to żadnego znaczenia - bo nie masz przerwań - więc zadziała bez poprawek w tym pliku.

    4\/3!!
  • Poziom 24  
    Pobrałem przykład dla STM32_blink_led. W pliku linkera zmieniałem
    Cytat:
    __main_stack_size = 1024;
    __process_stack_size = 1024;
    Cytat:
    MEMORY
    {
    rom (rx) : org = 0x00000000, len = 256k
    ram (rwx) : org = 0x10000000, len = 16k
    }
    No i zastąpiłem plik main.c swoim. Ale nadal nie działa. Z ciekawszych komunikatów jest to
    Cytat:
    Warn : Verification will fail since checksum in image (0x00000199) to be written to flash is different from calculated vector checksum (0xeffff2d2).
    Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.
    wrote 4096 bytes from file Z:/ARM/workspace/stm32tolpc1756/out/stm32_blink_led.hex in 3.430101s (1.166 kb/s)


    Może kolega markosik20 odpalił swój procesor i byłby uprzejmy wysłać mi lub zamieścić tutaj gotowy wsad migający diodą?
  • Poziom 33  
    Niestety obecnie mam bardzo słabe łącze (bluconnect) więc swoich plików nie "przepchnę". Zresztą nigdy nie napisałem żadnego programu do migania diodą na LPC'ka.:D a obecnie mój projekt kompiluje się do ponad 100kB. Jedynie co mogę poradzić na już to poszukaj gotowych przykładów dla Keila. W tych przykładach startup jest pisany w C , jedynie co to podstaw plik linkera i makefile'a. Tak jak pisał Freddie....makefile'a i plik .ld weź z projektu z STM32 i pozmieniaj odpowiednio adresy i wielkości pamięci RAM i ROM. Druga sprawa to pokaż co "wypluwa" kompilator w konsoli.
  • Poziom 24  
    Cytat:
    Assembling file: startup.S
    arm-none-eabi-gcc -x assembler-with-cpp -c -mcpu=cortex-m3 -mthumb -g -ggdb3 -Wa,-amhls=out/startup.lst -MD -MP -MF out/startup.d -I. startup.S -o out/startup.o

    Compiling file: core_cm3.c
    arm-none-eabi-gcc -c -mcpu=cortex-m3 -mthumb -O0 -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes -Wextra -std=gnu89 -g -ggdb3 -fverbose-asm -Wa,-ahlms=out/core_cm3.lst -DSTM32F10X_MD -MD -MP -MF out/core_cm3.d -I. core_cm3.c -o out/core_cm3.o

    Compiling file: system_LPC17xx.c
    arm-none-eabi-gcc -c -mcpu=cortex-m3 -mthumb -O0 -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes -Wextra -std=gnu89 -g -ggdb3 -fverbose-asm -Wa,-ahlms=out/system_LPC17xx.lst -DSTM32F10X_MD -MD -MP -MF out/system_LPC17xx.d -I. system_LPC17xx.c -o out/system_LPC17xx.o

    Compiling file: vectors.c
    arm-none-eabi-gcc -c -mcpu=cortex-m3 -mthumb -O0 -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes -Wextra -std=gnu89 -g -ggdb3 -fverbose-asm -Wa,-ahlms=out/vectors.lst -DSTM32F10X_MD -MD -MP -MF out/vectors.d -I. vectors.c -o out/vectors.o

    Compiling file: main.cpp
    arm-none-eabi-g++ -c -mcpu=cortex-m3 -mthumb -O0 -ffunction-sections -fdata-sections -Wall -Wextra -std=gnu++98 -g -ggdb3 -fno-rtti -fno-exceptions -fverbose-asm -Wa,-ahlms=out/main.lst -DSTM32F10X_MD -MD -MP -MF out/main.d -I. main.cpp -o out/main.o

    Linking target: out/stm32_blink_led.elf
    arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -Tstm32f103rb_rom.ld -g -Wl,-Map=out/stm32_blink_led.map,--cref,--no-warn-mismatch -Wl,--gc-sections -nostartfiles out/startup.o out/core_cm3.o out/system_LPC17xx.o out/vectors.o out/main.o -o out/stm32_blink_led.elf

    Creating extended listing: out/stm32_blink_led.lss
    arm-none-eabi-objdump -S out/stm32_blink_led.elf > out/stm32_blink_led.lss

    Creating memory dump: out/stm32_blink_led.dmp
    arm-none-eabi-objdump -x --syms out/stm32_blink_led.elf > out/stm32_blink_led.dmp

    Creating IHEX image: out/stm32_blink_led.hex
    arm-none-eabi-objcopy -O ihex out/stm32_blink_led.elf out/stm32_blink_led.hex

    Creating binary image: out/stm32_blink_led.bin
    arm-none-eabi-objcopy -O binary out/stm32_blink_led.elf out/stm32_blink_led.bin

    Size of modules:
    arm-none-eabi-size -B -t --common out/startup.o out/core_cm3.o out/system_LPC17xx.o out/vectors.o out/main.o
    text data bss dec hex filename
    104 0 0 104 68 out/startup.o
    652 0 0 652 28c out/core_cm3.o
    864 4 0 868 364 out/system_LPC17xx.o
    320 0 0 320 140 out/vectors.o
    120 0 0 120 78 out/main.o
    2060 4 0 2064 810 (TOTALS)

    Size of target .elf file:
    arm-none-eabi-size -B out/stm32_blink_led.elf
    text data bss dec hex filename
    544 0 2048 2592 a20 out/stm32_blink_led.elf



    oraz na stderr
    Cytat:
    In file included from LPC17xx.h:95,
    from system_LPC17xx.c:25:
    core_cm3.h:790: warning: function declaration isn't a prototype
    core_cm3.h:791: warning: function declaration isn't a prototype
    core_cm3.h:793: warning: function declaration isn't a prototype
    core_cm3.h:794: warning: function declaration isn't a prototype
    core_cm3.h:796: warning: function declaration isn't a prototype
    core_cm3.h:797: warning: function declaration isn't a prototype
    core_cm3.h:798: warning: function declaration isn't a prototype
    core_cm3.h:799: warning: function declaration isn't a prototype
    core_cm3.h:800: warning: function declaration isn't a prototype
    core_cm3.h:801: warning: function declaration isn't a prototype
    core_cm3.h:802: warning: function declaration isn't a prototype
    core_cm3.h:803: warning: function declaration isn't a prototype
    In file included from system_LPC17xx.c:25:
    LPC17xx.h:103: warning: ignoring #pragma anon_unions
    LPC17xx.h:843: warning: ignoring #pragma no_anon_unions
    In file included from main.cpp:1:
    lpc17xx.h:103: warning: ignoring #pragma anon_unions
    lpc17xx.h:843: warning: ignoring #pragma no_anon_unions
  • Specjalista - Mikrokontrolery
    Zrób ten swój plik główny jako .c, a nie .cpp. Potem wrzuć też profilaktycznie plik .lss. Zasadniczo w tej sytuacji (wg mnie) już powinno się kompilować poprawnie - jeśli Twój kod robi wszystko co jest potrzebne... Możesz mieć jeszcze np przestawione jakieś zworki, które wymuszają uruchomienie bootloadera albo jakiś problem sprzętowy.

    4\/3!!
  • Poziom 24  
    Międzyczasie zainstalowałem keila. Zrobiłem w nim program. Skompilował się, ale podczas nagrywania openocd mam error: adres range 0x2fc .. 0x8fff is not sector aligned

    Próbuję dalej. ARM zdecydowanie jest dla ambitnych.

    Co do problemów sprzętowych. Nie wiem czy mogę wstawić linka, ale jakby co to niech moderator sobie wytnie. Posiadam ten Link moduł. Wyklucza to moim zdaniem błędy sprzętowe do minimum. Jak na razie ograniczyłem się do podpięcia 3V3 i GND oraz jednego pinu jako wyjście do leda, rezystora i potem do masy. To na płytce stykowej. Jak odepnę ten pin i podłącze pod diodę napięcie 3V3 to świeci.

    Walczę dalej.

    P.S. Poważnie to wygląda :|
  • Poziom 2  
    Od około tygodnia walczę z wgraniem programu na LPC1756. Korzystam z OpenOCD, Eclipse, BF30 z Kamami. Czy jest ktoś w posiadaniu działającego pliku konfiguracyjnego do LPC1756? Osobiście wykorzystałem plik z elektrody ale z innego tematu i wgrywanie kończy się niepowodzeniem.
  • Poziom 33  
    Boczke napisał:
    Osobiście wykorzystałem plik z elektrody ale z innego tematu i wgrywanie kończy się niepowodzeniem.


    Pokaż plik oraz dane jakie wyrzuca OpenOCD.
  • Poziom 2  
    Mój config:
    Cytat:
    # NXP LPC1768 Cortex-M3 with 512kB Flash and 32kB+32kB Local On-Chip SRAM, clocked with 4MHz internal RC oscillator

    if { [info exists CHIPNAME] } {
    set _CHIPNAME $CHIPNAME
    } else {
    set _CHIPNAME lpc1756
    }

    if { [info exists ENDIAN] } {
    set _ENDIAN $ENDIAN
    } else {
    set _ENDIAN little
    }

    if { [info exists CPUTAPID ] } {
    set _CPUTAPID $CPUTAPID
    } else {
    set _CPUTAPID 0x4ba00477
    }

    #delays on reset lines
    jtag_nsrst_delay 200
    jtag_ntrst_delay 200

    # LPC2000 & LPC1700 -> SRST causes TRST
    reset_config trst_and_srst srst_pulls_trst

    jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID

    set _TARGETNAME $_CHIPNAME.cpu
    target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position $_TARGETNAME

    # LPC1768 has 32kB of SRAM on its main system bus (so-called Local On-Chip SRAM)
    $_TARGETNAME configure -work-area-phys 0x10000000 -work-area-size 0x4000 -work-area-backup 0

    # REVISIT is there any good reason to have this reset-init event handler??
    # Normally they should set up (board-specific) clocking then probe the flash...
    $_TARGETNAME configure -event reset-init {
    # Force NVIC.VTOR to point to flash at 0 ...
    # WHY? This is it's reset value; we run right after reset!!
    mwb 0xE000ED08 0x00
    }

    # LPC1768 has 512kB of user-available FLASH (bootloader is located in separate dedicated region).
    # flash bank lpc1700 <base> <size> 0 0 <target#> <variant> <cclk> [calc_checksum]

    set _FLASHNAME $_CHIPNAME.flash
    flash bank $_FLASHNAME lpc2000 0x0 0x40000 0 0 $_TARGETNAME lpc1700 12000 calc_checksum

    # 4MHz / 6 = 666kHz, so use 500
    jtag_khz 500

    #interface
    interface ft2232
    ft2232_layout oocdlink
    ft2232_vid_pid 0x0403 0x6010
    ft2232_device_desc "OOCDLink A"


    Wgrywam aplikację ze strony: http://tenuki.fr/nio101/?page_id=117

    Komenda do OpenOCD:
    Cytat:
    openocd -f LPC1756.cfg -c "init" -c "reset halt" -c "flash write_image erase lpc1756.elf" -c "reset run" -c "shutdown"


    I otrzymuję komunikat:

    Cytat:

    Open On-Chip Debugger 0.3.1 (2009-11-20-00:17)
    $URL$
    For bug reports, read
    http://openocd.berlios.de/doc/doxygen/bugs.html
    jtag_nsrst_delay: 200
    jtag_ntrst_delay: 200
    trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
    Warn : use 'lpc1756.cpu' as target identifier, not '0'
    Error: flash driver 'lpc1756.flash' not found


    Wykonywałem wiele projektów na AVR jednak z góry przyznaję, że to moja pierwsza styczność z ARM