Pytanie dotyczące SEGGER J-Link

[FlyingDutch]

Cześć,

mam pytanie dotyczące programatora/debuggera J-Link. Czy za pomocą "J-Link Commander" (J-Link.exe) pod OS Windows 10 można wgrać program (binarny) do MCU, które nie posiada pamieci Flash (ma tylko RAM). Pytanie w kontekście płytki: "Sparkfun QuickLogic Thing Plus - EOS S3"

https://www.sparkfun.com/products/17273

Płytka jest oparta na "QuickLogic EOS S3 Ultra Low Power SOC" - połączenie ARM-Cortex-M4F MCU i (FPGA) - tutaj datasheet:

https://cdn.sparkfun.com/assets/7/a/c/c/e/QL-EOS-S3-Ultra-Low-Power-multicore-MCU-Datasheet-v3_3d.pdf

Używam tego tutoriala do rozpoczęcia pracy z płytką:

https://learn.sparkfun.com/tutorials/quicklogic-thing-plus-eos-s3-hookup-guide

Patrz paragrafy zaczynające się od "Download Binaries using JLink SWD" (na końcu tutoriala).

Czy ktoś mógłby mi wyjaśnić jak to jest z "J-Link"  - dotychczas myślałem, że J-Link może wczytać program binarny wyłącznie do pamięci Flash, ale prawdopodobnie się mylę. Ważne - w tym tutorialu razem z J-Link nie jest używane "OpenOCD" tylko wyłącznie "J-Link Commander" (program Jlink.exe).

Będę bardzo wdzięczny za wyjaśnienie tego tematu.

Pozdrawiam

[kaworu]

1 godzinę temu, FlyingDutch napisał:

Czy ktoś mógłby mi wyjaśnić jak to jest z "J-Link"  - dotychczas myślałem, że J-Link może wczytać program binarny wyłącznie do pamięci Flash, ale prawdopodobnie się mylę.

Nie mogę powiedzieć jak to dokładnie wygląda z j-linkiem, ale mogę powiedzieć jak w ogole wygląda wgrywanie programu do pamięci.
I generalnie jest tak, że żaden programator nie programuje pamięci bezpośrednio, bo to jest horrendalnie wolna operacja. *Chyba* wszystkie programatory działają tak, że wgrywają mały program do pamięci SRAM, odpalają go i za jego pośrednictwem ładują dane do flasha. W przypadku st-linka w folderze z interfejsem programatora jest folder "FlashLoader", który zawiera programy ładujące dla różnych id rdzeni.
A jako, że do programowania i tak używa się loadera pracującego na docelowym MCU nic nie stoi na przeszkodzie aby mieć taki loader, który zaprogramuje cokolwiek co jest podłączone do procesora. Co z resztą w stlinku jest używane do programowania pamięci SPI flash obecnych na płytkach developerskich.

[FlyingDutch]

45 minut temu, kaworu napisał:

Nie mogę powiedzieć jak to dokładnie wygląda z j-linkiem, ale mogę powiedzieć jak w ogole wygląda wgrywanie programu do pamięci.
I generalnie jest tak, że żaden programator nie programuje pamięci bezpośrednio, bo to jest horrendalnie wolna operacja. *Chyba* wszystkie programatory działają tak, że wgrywają mały program do pamięci SRAM, odpalają go i za jego pośrednictwem ładują dane do flasha. W przypadku st-linka w folderze z interfejsem programatora jest folder "FlashLoader", który zawiera programy ładujące dla różnych id rdzeni.
A jako, że do programowania i tak używa się loadera pracującego na docelowym MCU nic nie stoi na przeszkodzie aby mieć taki loader, który zaprogramuje cokolwiek co jest podłączone do procesora. Co z resztą w stlinku jest używane do programowania pamięci SPI flash obecnych na płytkach developerskich.

Cześć,

właśnie chodzi mi o alternatywę dla bootloader'a, czyli wgranie programu za pomocą wyłacznie JTAG lub SWD. Sytuacja jest jeszcze bardziej skomplikowana, bo chodzi o załadowanie programu binarnego dla MCU i jednocześnie pliku konfiguracyjnego dla FPGA, oraz uruchomienie całości. Nietypowe jest to, że wygląda na to, ze SOC nie posiada prawdopodobnie w ogóle pamięci Flash (nie ma też zewnętrznej kości z Flash na płytce) ma wyłącznie 512KB RAM. No i chodzi mi konkretnie o J-Link'a (używanego bez "OpenOCD" za pomocą JLink.exe - commandera pos OS Windows10).

Pozdrawiam

 

[kaworu]

6 minut temu, FlyingDutch napisał:

właśnie chodzi mi o alternatywę dla bootloader'a, czyli wgranie programu za pomocą wyłacznie JTAG lub SWD.

No właśnie o tym napisałem (wykonalne, ale się tak nie robi). A, że JL nie używam, to tez odpowiedziałem tylko na ogólną część posta.

Tak czy inaczej SWD daje programatorowi dostęp do wszystkiego, więc fizycznie przez samo SWD da sie dobrać do czegokolwiek co jest w przestrzeni adresowej MCU + rdzeń. Także ładujesz program pod adres pamięci RAM, ustawisz PC i uruchamiasz. Pierwszy wynik z google na to jak to zrobić JLinkiem https://forum.segger.com/index.php/Thread/1992-Jlink-to-download-a-bin-file-to-memory-and-execute-it/ aczkolwiek post z 2014, mogło się coś zmienić. No i o części FPGA niech się jakiś spec wypowie co miał z tym układem do czynienia.

 

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[FlyingDutch]

18 minut temu, kaworu napisał:

No właśnie o tym napisałem (wykonalne, ale się tak nie robi). A, że JL nie używam, to tez odpowiedziałem tylko na ogólną część posta.

Tak czy inaczej SWD daje programatorowi dostęp do wszystkiego, więc fizycznie przez samo SWD da sie dobrać do czegokolwiek co jest w przestrzeni adresowej MCU + rdzeń. Także ładujesz program pod adres pamięci RAM, ustawisz PC i uruchamiasz. Pierwszy wynik z google na to jak to zrobić JLinkiem https://forum.segger.com/index.php/Thread/1992-Jlink-to-download-a-bin-file-to-memory-and-execute-it/ aczkolwiek post z 2014, mogło się coś zmienić. No i o części FPGA niech się jakiś spec wypowie co miał z tym układem do czynienia.

 

Cześć,

no właśnie mi chodziło o potwierdzenie, że jest to możliwe - Dziękuję 😀

Pozdrawiam

 

[Elvis]

@FlyingDutch Możliwe jest jak najbardziej, tylko nie rozumiem dlaczego upierasz się przy używaniu narzędzi od segger-a. Może łatwiej będzie użyć openocd.

Edit: Trochę się pospieszyłem z odpowiedzią - oczywiście można za pomocą SWD wgrać kod do pamięci SRAM, zmienić stan rejestrów Cortex-M4F i w ten sposób wykonać program. Niestety EOS S3 to o wiele więcej niż prosty mikrokontroler i nie wszystko jest dostępne w ten sposób. Z tego co widzę w dokumentacji, konfiguracja FPGA jest pobierana z pamięci flash, więc raczej nie uda się konfigurować za pomocą SWD/JTAG-a.

Edytowano Lipiec 2, 2022 przez Elvis

[FlyingDutch]

25 minut temu, Elvis napisał:

@FlyingDutch Możliwe jest jak najbardziej, tylko nie rozumiem dlaczego upierasz się przy używaniu narzędzi od segger-a. Może łatwiej będzie użyć openocd.

Cześć @Elvis

nie upieram się, chciałem mieć alternatywę, gdybym nie miał zainstalowanego/nie chciał instalować "OpenOCD"  🙂

Pozdrawiam

[Elvis]

Doczytałem trochę o EOS S3 i tak jak dopisałem w poprzednim komentarzu - chyba nie uda się zrobić tego co próbujesz:

Ale wgrywanie programu do RAM pewnie zadziała.

[FlyingDutch]

1 godzinę temu, Elvis napisał:

Doczytałem trochę o EOS S3 i tak jak dopisałem w poprzednim komentarzu - chyba nie uda się zrobić tego co próbujesz:

Ale wgrywanie programu do RAM pewnie zadziała.

Hej @Elvis

tak przy okazji EOS S3 zapytam - używałeś może Symbiflow do syntezy układów FPGA (niekoniecznie z EOS S3)?

Pozdrawiam

 

[Elvis]

Symbiflow nie używałem. Próbowałem to nawet zainstalować, ale to jakiś koszmarek, chyba nadaje się tylko do trzymania w kontenerze dockera.

Ale symbiflow to raptem kiepsko przygotowane skrypty, które wykorzystują inne narzędzia open-source, jak yosys, czy icarus-verilog. Można z nich korzystać bez zawracania sobie głowy symbiflow-em, działają bardzo fajnie i do tego szybko. Używam ich z układami ice40 i bardzo polecam.

[Elvis]

Jednak pierwszy wniosek był słuszny - jednak da się programować za pomocą SWD nie tylko Cortex-M4, ale również FPGA w EOS S3 :)

[Elvis]

Symbiflow na pewno nie będzie moim ulubionym narzędziem, prawdę mówiąc mam nadzieję, że nigdy więcej nie będę go już używać. To koszmarny przykład jak można wykorzystać bardzo dobre, open-sourceowe narzędzia i zrobić z nich koszmar o jakim nie śniło się w korporacjach typu Xilinx, czy Altera.

Ale na wypadek, gdyby ktoś nieostrożny jednak chciał kiedyś zobaczyć dlaczego nie warto tego używać, albo po prostu chciał uruchomić miganie diodą na płytce SparkFun QuickLogic Thing Plus krótko opiszę co udało mi się z wielkim bólem uzyskać.

Na początek linki do samej płytki na stronie Botland: https://botland.com.pl/moduly-uczenia-maszynowego/20237-sparkfun-quicklogic-thing-plus-eos-s3-modul-uczenia-maszynowego-sparkfun-dev-17273-5904422352455.html oraz strona producenta: https://www.sparkfun.com/products/17273. Obie strony podają linki do producenta samego układu, czyli QuickLogic EOS S3: https://www.quicklogic.com/products/soc/

Na koniec to co najważniejsze, czyli nieszczęsny Symbiflow w wersji dla EOS-S3: https://github.com/QuickLogic-Corp/quicklogic-fpga-toolchain/releases/ Plik w wersji release powinien się teoretycznie dać zainstalować, ale pomimo prób na kilku dystrybucjach typu Ubuntu 20.04LTS, czy Debian 11 okazuje się, że to tak nie działa. Instalacja zawsze kończy się śmieciami w systemie oraz błedem niezgodności czegośtam.

Na szczęście można użyć Docker-a i samemu skompilować Symbiflow, albo chociaż użyć gotowej wersji w środowisku, które u autorów tego nieszczęścia pewnie działało. Pliki dla dockera znajdziemy w repozytorium: https://github.com/QuickLogic-Corp/quicklogic-fpga-toolchain, czyli tam gdzie plik "instalatora". W każdym razie mamy tam plik Dockerfile oraz Dockerfile.use-installer:

Pliki są prawie nowe, mają raptem 2 lata więc powinny działać. Pierwszy, czyli Dockerfile pozwala na budowanie wszystkiego od podstaw co może zająć trochę czasu, więc lepiej użyć drugiego, czyli Dockerfile.use-installer. Powinien on pobrać plik instalacyjny, który jak wiemy nie działa na prawdziwej dystrybucji, ale może na tym specyficznym obrazie dockera zadziała.

Budowanie obrazu jest opisane w pliku Dockerfile i jest to standardowe wywołanie:

docker build . -f Dockerfile.use-installer -t symbiflow

Jak można się spodziewać nawet to się nie uda i pojawią się błędy... brakuje biblioteki libtbb2. Teoretycznie kontenery są po to, żeby takich błędów nie było, ale jak zwykle teoria wypiera praktykę, nie pozostaje nic innego niż dodać bibliotekę do pliku, czyli dodać jedną linijkę w pliku Dockerfile.use-installer:

RUN apt-get update && apt-get install -y \
    libcanberra-gtk-module \
    make \
    curl \
    git \
    wget \
    libtbb2 \
    xz-utils && \
    rm -rf /var/lib/apt/lists/*

Teraz jest dużo lepiej, obraz jest budowany poprawnie i można spróbować go użyć.

Najpierw warto jednak przygotować jakiś testowy kod, powiedzmy w Verilogu plik top.v:

module top(
        input btn,
        output led
);

always @(*)
        led = ~btn;

endmodule

Linie btn oraz led muszą być podłączone do odpowiednich pinów - na schemacie nie znalazłem zegara dla FPGA, stąd tak banalny przykład jak zapalanie diody przyciskiem. W kazdym razie plik z definicją pinów można nazwać przykładowo board.pcf, a numery pinów odszukać na schemacie płytki:

set_io btn B3
set_io led G7

Teraz wypadałoby uruchomić obraz Symbiflow w dockerze:

docker run -it --rm -v "$(pwd)":/symbiflow symbiflow /bin/bash

Parametr -v pozwala na dostęp z poziomu kontenera do bieżącego katalogu. Dzięki temu pliki top.v oraz board.pcf będą widoczne dla symbiflow-a, a wynik działania będzie w bieżącym katalogu.

Kontener "widzi" bieżący katalog jako /symbiflow, więc możemy do niego przejść wykonując:

cd /symbiflow

Teraz uruchamiamy "condę" pisząc:

source /opt/symbiflow/eos-s3/conda/bin/activate 

I już możemy używać symbiflow... od razu wspomnę, że warto byłoby poprawić skrypty Docker-a, ale taka wersja wystarczy do eksperymentów - i pozwala zobaczyć jak proste rzeczy można zupełnie bez sensu skomplikować.

Aby zsyntetyzować projekt można wykonać polecenie:

ql_symbiflow -compile -src . -d ql-eos-s3 -P PD64 -t top -v top.v -p board.pcf

Jednak ten wątek zaczynał się pytaniem o J-Link, warto więc dodać jeszcze jeden parametr:

ql_symbiflow -compile -src . -d ql-eos-s3 -P PD64 -t top -v top.v -p board.pcf -dump jlink

Dodanie parametru -dump sprawi, że oprócz typowego pliku przeznaczonego do konfiguracji FPGA otrzymamy również gotowy skrypt dla JLinka:

Teraz mamy już wszystko, żeby skonfigurować układ. Skoro miał być JLink, więc niech będzie:

JLinkExe -Device CORTEX-M4 -If SWD -Speed 4000 -AutoConnect 1 -CommanderScript top.jlink

Skrypt ma 483KB, więc jego wykonanie trochę zajmuje... ale na koniec mamy działający układ - po naciśnięciu przycisku zapala się dioda.

To chyba najbardziej skomplikowane zapalanie diodą jakie miałem "przyjemność" testować. W porównaniu do Symbiflow, gołe narzędzia open-source to czysta przyjemność, o Vivado od Xilinxa nawet nie wspominając. Ale całość działa, teraz można pomyśleć jak wyrzucić śmieci wprowadzone przez symbiflow i to samo uruchomić szybciej i sprawniej 🙂

Edytowano Lipiec 2, 2022 przez Elvis

[FlyingDutch]

10 godzin temu, Elvis napisał:

Jednak pierwszy wniosek był słuszny - jednak da się programować za pomocą SWD nie tylko Cortex-M4, ale również FPGA w EOS S3 🙂

@Elvis - tak mi się wydawało, ale nie byłem pewien. Dziękuję za potwierdzenie.

Pozdrawiam

[FlyingDutch]

9 godzin temu, Elvis napisał:

Symbiflow na pewno nie będzie moim ulubionym narzędziem, prawdę mówiąc mam nadzieję, że nigdy więcej nie będę go już używać. To koszmarny przykład jak można wykorzystać bardzo dobre, open-sourceowe narzędzia i zrobić z nich koszmar o jakim nie śniło się w korporacjach typu Xilinx, czy Altera.

Ale na wypadek, gdyby ktoś nieostrożny jednak chciał kiedyś zobaczyć dlaczego nie warto tego używać, albo po prostu chciał uruchomić miganie diodą na płytce SparkFun QuickLogic Thing Plus krótko opiszę co udało mi się z wielkim bólem uzyskać.

Na początek linki do samej płytki na stronie Botland: https://botland.com.pl/moduly-uczenia-maszynowego/20237-sparkfun-quicklogic-thing-plus-eos-s3-modul-uczenia-maszynowego-sparkfun-dev-17273-5904422352455.html oraz strona producenta: https://www.sparkfun.com/products/17273. Obie strony podają linki do producenta samego układu, czyli QuickLogic EOS S3: https://www.quicklogic.com/products/soc/

Na koniec to co najważniejsze, czyli nieszczęsny Symbiflow w wersji dla EOS-S3: https://github.com/QuickLogic-Corp/quicklogic-fpga-toolchain/releases/ Plik w wersji release powinien się teoretycznie dać zainstalować, ale pomimo prób na kilku dystrybucjach typu Ubuntu 20.04LTS, czy Debian 11 okazuje się, że to tak nie działa. Instalacja zawsze kończy się śmieciami w systemie oraz błedem niezgodności czegośtam.

Na szczęście można użyć Docker-a i samemu skompilować Symbiflow, albo chociaż użyć gotowej wersji w środowisku, które u autorów tego nieszczęścia pewnie działało. Pliki dla dockera znajdziemy w repozytorium: https://github.com/QuickLogic-Corp/quicklogic-fpga-toolchain, czyli tam gdzie plik "instalatora". W każdym razie mamy tam plik Dockerfile oraz Dockerfile.use-installer:

Pliki są prawie nowe, mają raptem 2 lata więc powinny działać. Pierwszy, czyli Dockerfile pozwala na budowanie wszystkiego od podstaw co może zająć trochę czasu, więc lepiej użyć drugiego, czyli Dockerfile.use-installer. Powinien on pobrać plik instalacyjny, który jak wiemy nie działa na prawdziwej dystrybucji, ale może na tym specyficznym obrazie dockera zadziała.

Budowanie obrazu jest opisane w pliku Dockerfile i jest to standardowe wywołanie:

docker build . -f Dockerfile.use-installer -t symbiflow

Jak można się spodziewać nawet to się nie uda i pojawią się błędy... brakuje biblioteki libtbb2. Teoretycznie kontenery są po to, żeby takich błędów nie było, ale jak zwykle teoria wypiera praktykę, nie pozostaje nic innego niż dodać bibliotekę do pliku, czyli dodać jedną linijkę w pliku Dockerfile.use-installer:

RUN apt-get update && apt-get install -y \
    libcanberra-gtk-module \
    make \
    curl \
    git \
    wget \
    libtbb2 \
    xz-utils && \
    rm -rf /var/lib/apt/lists/*

Teraz jest dużo lepiej, obraz jest budowany poprawnie i można spróbować go użyć.

Najpierw warto jednak przygotować jakiś testowy kod, powiedzmy w Verilogu plik top.v:

module top(
        input btn,
        output led
);

always @(*)
        led = ~btn;

endmodule

Linie btn oraz led muszą być podłączone do odpowiednich pinów - na schemacie nie znalazłem zegara dla FPGA, stąd tak banalny przykład jak zapalanie diody przyciskiem. W kazdym razie plik z definicją pinów można nazwać przykładowo board.pcf, a numery pinów odszukać na schemacie płytki:

set_io btn B3
set_io led G7

Teraz wypadałoby uruchomić obraz Symbiflow w dockerze:

docker run -it --rm -v "$(pwd)":/symbiflow symbiflow /bin/bash

Parametr -v pozwala na dostęp z poziomu kontenera do bieżącego katalogu. Dzięki temu pliki top.v oraz board.pcf będą widoczne dla symbiflow-a, a wynik działania będzie w bieżącym katalogu.

Kontener "widzi" bieżący katalog jako /symbiflow, więc możemy do niego przejść wykonując:

cd /symbiflow

Teraz uruchamiamy "condę" pisząc:

source /opt/symbiflow/eos-s3/conda/bin/activate 

I już możemy używać symbiflow... od razu wspomnę, że warto byłoby poprawić skrypty Docker-a, ale taka wersja wystarczy do eksperymentów - i pozwala zobaczyć jak proste rzeczy można zupełnie bez sensu skomplikować.

Aby zsyntetyzować projekt można wykonać polecenie:

ql_symbiflow -compile -src . -d ql-eos-s3 -P PD64 -t top -v top.v -p board.pcf

Jednak ten wątek zaczynał się pytaniem o J-Link, warto więc dodać jeszcze jeden parametr:

ql_symbiflow -compile -src . -d ql-eos-s3 -P PD64 -t top -v top.v -p board.pcf -dump jlink

Dodanie parametru -dump sprawi, że oprócz typowego pliku przeznaczonego do konfiguracji FPGA otrzymamy również gotowy skrypt dla JLinka:

Teraz mamy już wszystko, żeby skonfigurować układ. Skoro miał być JLink, więc niech będzie:

JLinkExe -Device CORTEX-M4 -If SWD -Speed 4000 -AutoConnect 1 -CommanderScript top.jlink

Skrypt ma 483KB, więc jego wykonanie trochę zajmuje... ale na koniec mamy działający układ - po naciśnięciu przycisku zapala się dioda.

To chyba najbardziej skomplikowane zapalanie diodą jakie miałem "przyjemność" testować. W porównaniu do Symbiflow, gołe narzędzia open-source to czysta przyjemność, o Vivado od Xilinxa nawet nie wspominając. Ale całość działa, teraz można pomyśleć jak wyrzucić śmieci wprowadzone przez symbiflow i to samo uruchomić szybciej i sprawniej 🙂

@Elvis,

dziękuję za ten tutorial - właśnie wczoraj sam boleśnie się przekonałem, że procedura instalacji Symbiflow opisana w dokumentacji do płytki nie działa. Twój post jest bardzo pomocny.

Pozdrawiam

 

 

[FlyingDutch]

Hej @Elvis,

czy można jeszcze (jak już tak sporo napisałeś w tym temacie) podpytać Cię o opinie/doświadczenia związane z "Zephyr RTOS"? Poniekąd także w kontekście tego zestawu developerskiego "QickLogic Thing Plus", który ma wsparcie "Zephyr RTOS". Mam też trochę bardziej ogólne pytanie "Czy według Ciebie takie płytki jak "QuickLogic Thing Plus" (SoC łaczące MCU i FPGA ) znajdą ciekawe zastosowania, czy może to chwilowa moda? Wiem, że to trochę wróżenie z fusów i zabawa we wróżkę, ale jestem ciekaw twojej opinii w tej sprawie.

Pozdrawiam