Próba debugowania programu w "Arduino IDE" 2.3.2 dla płytki "Arduino UNO R4 Minima" - debuggery: STLink i JLink

FlyingDutch · Wrzesień 2, 2024

Cześć,

jakiś czas temu nabyłem klona "Arduino UNO R4 Minima" - tutaj link:

https://pl.aliexpress.com/item/1005007151289027.html?spm=a2g0o.detail.pcDetailTopMoreOtherSeller.9.5d3eRPz8RPz8Sc&gps-id=pcDetailTopMoreOtherSeller&scm=1007.40000.327270.0&scm_id=1007.40000.327270.0&scm-url=1007.40000.327270.0&pvid=828901c0-ada2-4bfa-9b8e-5fc3e7c9e006&_t=gps-id%3ApcDetailTopMoreOtherSeller%2Cscm-url%3A1007.40000.327270.0%2Cpvid%3A828901c0-ada2-4bfa-9b8e-5fc3e7c9e006%2Ctpp_buckets%3A668%232846%238113%231998&pdp_npi=4%40dis!PLN!26.93!22.89!!!6.78!5.76!%40211b650b17249968650934050ef1a2!12000039603809496!rec!PL!2287185289!XZ&utparam-url=scene%3ApcDetailTopMoreOtherSeller|query_from%3A&gatewayAdapt=glo2pol

Płytka "Arduino UNO R4 Minima" jest pod względem wymiarów i poziomów logicznych (5V) zgodna z "Arduino UNO R3" - tak więc powinno się do niej teoretycznie dać podłączyc większość shieldów z tej starszej wersji. Największą zmianą w Arduino UNO R4 jest nowy wydajny 32-bitowy procesor ARM. Dokładnie płytka UNO R4 jest wyposażona w ARM Cortex-M4 firmy Renesans model RA4M1 taktowany zegarem 48 Mhz i posiadający 32 kB RAM (UNO R3 miał zaledwie 2 kB RAM), oraz jednostkę FPU do obliczeń zmienno-przecinkowych. Jest to więc dużo wydajniejsza płytka na kórej można oprzeć dużo bardziej wymagające sprzętowo projekty niż na UNO R3.

Poniżej kilka linków do opisu tej płytki:

https://docs.arduino.cc/hardware/uno-r4-minima/#features

https://docs.arduino.cc/tutorials/uno-r4-minima/cheat-sheet/

https://docs.arduino.cc/resources/datasheets/ra4m1-datasheet.pdf

Wydanie tej nowej wersji UNO R4 zbiegło się to także w czasie z dostępnością stabilnie działającej wersji "Arduino IDE" w wersji 2.3 gdzie jest dostępna perspektywa IDE służąca do debugowania programów. Postanowiłem sprawdzić jak w "Arduino IDE" 2.3.2 wygląda debugowanie programów dla płytki "Arduino UNO R4 Minima". Do debugowania tej płytki można użyć miedzy innymi sprzętowych debugerów "STLink" firmy ST oraz J-Link firmy SEGGER - posiadam oba wymienione debuggery.

Pierwszą czynnością, którą trzeba było wykonać było wlutowanie headera dla portu SWD (Serial Wire Debug) do podłączenia sprzętowego debuggera - patrz rysunek poniżej:

Istotne są piny: SWDIO, SWCLK i GND. Wykonałem też prowizoryczny kabel przejściówkę który z jednej strony mogłem podłączyć do headera SWD na płytce Arduino UNO R4, a z drugiej strony do sprzętowego debuggera STLINK lub JLink. Poniżej debugger STLINK podłączony do UNO R4:

Najpierw postanowiłem spróbować z debuggerem "STLinK" (https://botland.com.pl/programatory/4481-programatordebugger-stm8stm32-zgodny-z-st-linkv2-mini-waveshare-10053-5904422332846.html)

Otworzyłem "Arduino IDE" 2.3.2 i otworzyłem prosty program odbiornika protokołu RS485, wybrałem płytkę "Arduino UNO R4 minma" wgrałem przez port szeregowy ten szkic i przeszedłem do perspektywy "DEBUG" (trójkąt z małą pluskwą w lewym panelu IDE). Następnie w górnym pasku (pod menu głównym) kliknąlem ikonę "Start Debbuging" (jedna ikona w prawo od UPLOAD). IDE połączyło się z debuggerem i otworzyło się okno "gdb-server" w którym był komunikat o poprawnej komunikacji debuggera. W prawym górnym oknie IDE Arduino z kodem źródłowym ustawiłem breakpoint (punkt zatrzymania programu) w linii 34 szkicu - zrobiłem to przed uruchomieniem debugowania. Otworzyłem też okno "Debug console" - patrz zrzut ekranu z IDE:

W lewym panelu zatytułowanym "DEBUG" w górnej części są ikony do pracy krokowej, zatrzymania debugowania lub restartu aplikacji. Poniżej w zakładce "THREADS" jest wypisany aktualny stan programu - w tym przypadku zatrzymanie wykonania na brakpoincie w linii 34. Poniżej w zakładce "CALL STACK" mamy historię wywołań funkcji programu. Jeszcze niżej w panelu "DEBUG" możemy obejrzeć aktualny stan zmiennych programu - automatycznych i globalnych. W zakładce "WATCH" możemy ustawić wartość wyrażeń, których wartości chcemy wyświetlać - wtym przypadku są to dwie zmienne programu. Jeszcze niżej w panelu jest zakładka "BREAKPOINTS" z ustawionymi punktami zatrzymania programu - w tym przypadku jest tylko jeden punkt zatrzymania w lini 34 szkicu. Poniużej w zakładce "CORTEX PERIPHERALS" możemy odczytać stan rejestrów układów peryferyjnych MCU ARM Cortex-M4. W ostatnie zakładce panelu z dołu "CORTEX REGISTERS" możemy podejrzeć aktualny stan rejestrów wewnętrznych CPU ARM. Podsumowując - debugowanie aplikacji w ARduino IDE 2.3.2 z debuggerem STLink zadziałało, chociaż moim zdanie jest dużo mniej intuicyjne niż w Innych IDE czy debuggerach softwarowych.

------------------------------------------------------------------------------------------

Debugowanie programu z debuggerem JLink.

Debugger JLink musiałem podłączyć do Arduino R4 poprzez przejściówkę na płytce PCB bo nie miałem odpowiedniego kabla - wyszło to mocno prowizorycznie.

Zdjęcie poniżej:

Sterownik do JLinka i "Jlink Commander" miałem już wcześniej poprawnie zainstalowane (OS Windows 10). Sprawdziłem jeszcze, czy po podłączeniu JLink'a kablem USB jest on poprawnie widoczny w managerze urządzeń Windows:

Następnie otworzyłem "Adruino IDE" 2.3.2 z otwartym tym samym programem co dla debuggera STLINK. Przeszedłem do perspektywy DEBUG i kliknąłem ikonę "Start Debugging". Niestety po chwili w oknie "gdb-server" pokazał się błąd: "Error: No J-Link device found." - patrz zrzut ekranu poniżej:

Jak widać na początku listingu w tym oknie użyty był plik konfiguracyjny debugerra o nazwie "R7FA4M1AB.cfg" (gdzie nazwa jest nazwą naszego MCU z płytki UNO R4).

Postanowiłem przyjrzeć się problemowi bezpośrednio w "J-Link Commanderze" - otworzyłem go, potem wpisąłem komendę "connect" i wybrałem domyślny target "CORTEX-M4", następnie komendę "S" (wybór protokołu SWD) i ustawiłem szybkość połąćzenia na 4000KHz. W odpowiedzi otrzymałem komunikat:

WARNING: RESET (pin 15) high, but should be low. Please check target hardware.

Błąd ten wynika z faktu, że do debuggera Jlink nie podłączyłem pinu RESET z mikrokontrolera Arduino UNO R4. Poniżej pinout dla płytki Arduino UNO R4:

Jak widać pin RESET jest wyprowadzony na główny port płytki Arduino UNO R4. Teraz trzeba ustalić, gdzie jest pin RESET dla debuggera JLink - poniżej pinout gniazda:

https://www.segger.com/products/debug-probes/j-link/technology/interface-description/

Jak widać jest to pin 15 głównego gniazda debuggera Jlink. Wykonałem połączenie tych dwóch pinów kablem. Niestety ponowne próby podłączenia się do debuggera JLink za pomoca "JLink Commandera" wyświetlają ten sam błąd. Potem podłączyłem pin RESET JLinka do masy - próby połączenia także z tym samym błędem.

Już wiem co było nie tak - podłączałem się do złego pinu REST od strony gniazda JLink. Powinienem się podłączyć do pinu 3 nTRST - gdy to poprawiłem udało mi się połączyć z płytką Arduino UNO R4 za pomocą "Jlink Commandera":

Postanowiłem wydać kilka podstawowych komend w "JLink Commanderze", aby sprawdzić ,czy działają - patrz zrzut ekranu poniżej:

Najpierw wydałem komendę: "isHalted" aby sprawdzić, czy CPU jest zatrzymane - nie było więc je zatrzymałem komendą "Halt". Wyświetlone zostały podstawowe rejestry procesora. Potem wydałem komendę: "mem 0xE00FF000,64", aby wyświetlić 64 bajty pamięci od podanego adresu (Start ROM) i ta komenda zadziałała poprawnie.

Po zmianie związanej z pine RESET uruchomiłem ponownie "Arduino IDE" i spróbowałem wywołać debuggowanie z debuggerem Jlink, ale ponownie miałem ten sam błąd:

"Error: No J-Link device found." Poszukałem w sieci i bardzo dużo innych użytkowników miało rózne problem z debuggowanie w "Arduino IDE" z użyciem debuggera Jlink.

-------------------------

Postanowiłem zrobić jeszcze jedna próbę z debugowaniem "Arduino UNO R4 Minima" z oryginalnym debuggerem "Ozone" firmy SEGGER. Postępowałem dokładnie z tutorialem na tej stronie:

https://docs.arduino.cc/tutorials/uno-r4-minima/debugger/

W debuggerze "Ozone" trzeba było ustawić odpowiedni target MCU firmy Renesans i wybrać skompilowany plik binarny .elf projektu. Po wczytaniu projektu i uruchomieniu debugger zatrzymał się na ustawionym wcześniej punkcie przerwania - dalsze debugowanie przebiegało bez problemów.