Przeszukaj forum

Słowem wstępu Jak większość elektroników wie magistrala USB nie należy do tych przyjemnych w implementacji. Często coś nie działa, lub urządzenie nie jest enumerowane. Co można zrobić w takim przypadku? Diagnozowanie przy użyciu software'u Teoretycznie możemy korzystać z oprogramowania takiego jak Free USB Protocol Analyzer, aczkolwiek często nie wykrywa ono urządzeń - dla przykładu jednego z moich projektów CDC nie jest w stanie wykryć niezależnie od portu, do którego zostanie wpięty. Stąd trzeba było poszukać innych rozwiązań... Hardware USB Sniffer Jak nie możemy zdiagnozować USB za pomocą software, to może podsłuchamy transmisję między hostem a device'm? Dobrze, ale ile kosztuje taki sprzęt, bo już prawdopodobnie ktoś go stworzył? 4000-9000 PLN 😮 Teledyne LeCroy No cóż... może istnieją tańsze rozwiązania? BugBlat miniSniffer / ezSniffer Chwila szukania tańszych alternatyw i trafiamy na stronę, gdzie widzimy 59.99$ plus wysyłka... No to już bardziej racjonalna cena. Alternatywnie można też kupić we francuskim lab401 jeżeli nie chcemy długo czekać. No cóż... w przeliczeniu z wysyłką z Francji cena to jakieś 370 złotych... to już sensowna wartość za tak użyteczny sprzęt - zamawiamy. Po oczekiwaniu na paczkę Wreszcie dotarła paczka - w niej wyłącznie płytka miniSniffer (bez okablowania). W przypadku wysyłki ChronoPostem w Polsce paczkę dostarcza DPD. Obudowa była wykonana chwilę później. Jak widzimy na obrazku urządzenie posiada dwa porty z jednej strony i jeden z drugiej. Są one używane następująco: USB-C - połączenie urządzenia z komputerem służącym do analizy (z oprogramowaniem miniSniffer) USB-A - podłączenie urządzenia - device USB-micro-B - podłączenie do komputera-hosta Patrząc na płytkę jest ona wykonana bardzo dobrze, a sercem jest układ FPGA - LCMX02. Podłączenie Samo podłączenie urządzenia do komputera jest bardzo proste, wystarczy wpiąć wszystkie przewody na swoje miejsce i uruchomić oprogramowanie. Należy pamiętać, by kliknąć przycisk Capture i podłączyć device do hosta (przycisk Connect). Pozwala nam to też na diagnozowanie pakietów kontrolnych (zawsze możemy odłączyć programowo urządzenie, po czym rozpocząć sniffing i podłączyć urządzenie). I tutaj pokazuje się główna różnica między miniSniffer, a ezSniffer - pojemność pamięci. miniSniffer posiada pojemność 128kB, która jest dość mała, ezSniffer 256MB. Należy mieć to szczególnie na uwadze w przypadku diagnozowania urządzeń, które przesyłają ogromną ilość pakietów danych. Ekran software'u Sam software jest dość prosty i wizualnie podobny do tego od Teledyne LeCroy. Posiada podgląd transakcji i pakietów, stąd łatwo możemy sprawdzić jak wygląda komunikacja w poszczególnych transakcjach. Widzimy wszystkie niezbędne dane - typ pakietu, endpoint, adres, dane czy CRC. Do tego również mamy określoną ilość czasu jaka minęła od początku diagnostyki. Warto wiedzieć, że nie możemy ustawić sobie offsetu na czas, więc jest to dość problematyczne, gdyż trzeba sobie ręcznie przeliczać, ale wystarczy prosty kalkulator i da się to zrobić. Dosyć przydatną funkcją jest ukrywanie pakietów NAK oraz SOF, więc zostają wyłącznie te, które mają znaczenie w komunikacji (te pierwsze zawsze można aktywować gdy np. diagnozujemy czy to komunikacja USB powoduje spadek wydajności czy inne algorytmy wewnątrz urządzenia). Pakiety kontrolne Raspberry Pi Pico (biblioteka przykładów, device low-level) Podsumowanie Jeżeli ktoś projektuje proste urządzenia USB (FS, HS), to miniSniffer jest przydatnym narzędziem do testowania. Jeżeli przesyłamy duże ilości danych lepiej skusić się na zakup ezSniffer, gdyż posiada znacznie większy bufor pamięci. W cenie 370 PLN z dostawą (lab401) jest to bardzo opłacalny zakup biorąc pod uwagę, że markowe rozwiązania kosztują 10 razy drożej, a ich dodatkowe funkcje są zwykle zbędne. Dodatkowym atutem urządzenia jest API, które można pobrać i napisać własne oprogramowanie 🙂 Problemy Podczas testowania urządzenia zauważyłem następujące "problemy": Urządzenie nie podłącza automatycznie device do hosta - trzeba klikąć przycisk w oprogramowaniu Oprogramowanie na linuxie wymaga nieoficjalnych wxWidgets - nie mogłem ich znaleźć w repozytoriach AUR / ArchLinux'a, znalazłem je wyłącznie w repozytoriach Debiana. Program instalujący na linuxie jest dostosowany pod Debiana / Ubuntu, na innych dystrybucjach trzeba go instalować ręcznie. Porty z początku ciężko chodzą, ale potem się dostosowują 🙂 Czy warto zakupić urządzenie? Jeżeli planujesz eksperymentować z USB - jak najbardziej, no chyba, że masz dostęp do Teledyne LeCroy Mercury lub innego markowego rozwiązania np. na uczelni czy w pracy... Wtedy raczej bym skorzystał z tej drugiej opcji.

Cześć. Jestem znowu zmuszony prosić was o pomoc gdyż po dwóch dniach poszukiwań nie udało mi się znaleźć odpowiedzi na mój problem. Korzystam z układu STM32h745ZI nucleo. Próbuje odpalić program na obu rdzeniach procesora i na razie po prostu zamigać diodami z jednego i drugiego. Debugger ustawiłem według opisu ze strony msalamon. Nie do końca tylko rozumiem w jaki sposób mam to uruchomić, Próbowałem bezpośrednio tak jak jest tam napisane, czyli odpalić najpierw program dla CM4 a później dla CM7 oraz tylko CM7. Efekt jest taki, że dioda z CM4 zaświeca się tylko na chwilę, później widzę, że STM przechodzi w stan resetu przed wgrywaniem softu na drugi rdzeń i do końca świeci juz tylko dioda z rdzenia CM7. To, że między wgraniem jednego i drugiego softu STM przechodzi w stan resetu wnioskuje po tym, że zaświeca się czerwona dioda, dokładnie tak jak w chwili podłączania układu do zasilania z linią BOOT0 podłączoną do 3V3. I tu właśnie pojawia się następny problem. Jeśli nie mam tak połączonego BOOT0 nie jestem w stanie w żaden sposób połączyć się z ST-Linkiem a więc wgrać nowego softu. To raczej nie jest poprawne działanie układu i pewnie właśnie to połączenie sprawia, że usuwany jest soft z rdzenia CM4. Jednak nie wiem kompletnie co mogę z tym zrobić.

Cześć, nie wiem czy dokładnie temat opisze mój problem ale: Musiałem zrobić na PC reinstalke Windowsa i pobrałem Keila. Wszystko ładnie pobrało mi - sterowniki do STlinka, biblioteki etc. zautomatu. I pojawił się taki problem, że za każdym razem jak zaprogramuje procka muszę wciskać reset by program ruszył. Wcześniej nie musiałem mam opcję zaznaczoną w ustawieniach STlinka ale po wgraniu i podstawowego programu (mruganie dioda) int main(void) { init_all(); while(1) { GPIOA->ODR^=1<<5; delay(20); } } zawsze musze zresetować plytke (nucelo f103) czy ktoś z Was miał podobny problem? Przed reinstalka systemu ten sam program nie wymagał czegoś takiego Pozdrawiam!

Mikroporadnik dla początkujących. Przeglądając internet często trafiałem na posty dotyczące problemu z debugowaniem popularnych tanich płytek Blue Pill a szczególnie tych zawierających chińskie klony mikrokontrolerów z kuźni STM oznaczonych CKS32. Sposoby tu przedstawione działają w środowisku Ac6 SW4STM32 i zapewne w podstawowym eclipse z dołączonymi pluginami dla STM32 za pomocą taniego klona programatora st-link v2. ------------- STM32F103C8T6 --- Problem z błędem dot. resetu podczas debugowania w SW4 przez SWD można obejść edytując plik konfiguracyjny, który jest tworzony w katalogu projektu po dodaniu nowej konfiguracji: RUN -> Debug Configurations... Trzeba kliknąć 2 razy na "Ac6 STM32 Debugging", pojawi się nowa konfiguracja. Trzeba teraz dodać plik .elf w polu "C/C++ Application" Następnie w zakładce "Debugger" po drodze można dodać opcję w polu "OpenOCD Command" na końcu za ścieżką do ocd -d3 lub -d2 dzięki czemu w konsoli debugera wyświetli się więcej informacji. Poniżej w Configuration Script należy zaznaczyć opcję "User Defined", kliknąć przycisk Browse... i otworzyć do edycji plik .cfg w pliku tym na samym dole trzeba pozbyć się wpisu "srst_only" Od tej pory procek będzie resetowany prawidłowo i możliwe będzie debugowanie po kliknięciu w robala w pasku narzędzi a połączenie z st-linkiem nie wymaga linii reset. W moim przypadku to jedyny sposób na uruchomienie debugera bo nie pomagało nawet fizyczne podłączenie resetu. W trueSTUDIO natomiast konieczne jest podłączenie linii resetu do płytki. W zakładce "Startup" na dole można też odznaczyć opcję "set breakpoint at: main " która w niektórych wersjach gdb powodowała błędy. Najlepiej dodać własne breakpinty. Tyle wystarczy aby debugować oryginalne procesory STM32 ostatnio jednak bardzo często spotykane są płytki z klonami STM. ------------- CKS32F103C8T6 (odpowiednik STM32F103CBT6 128kB Flash) --- Chiński klon ma wbity inny nr. urządzenia niż STM przez co debuger wywala błąd stlinka o niewłaściwym nr. urządzenia. Pierwsze co trzeba zrobić na początku, to w folderze instalacyjnym SW4STM32 włączyć wyszukiwarkę plików i wyszukać pliki " stm32f1x.cfg " (powinny być 2) i w każdym z nich zmienić instrukcję set _CPUTAPID 0x1ba01477 na set _CPUTAPID 0x2ba01477 Dzięki temu uC będzie poprawnie identyfikowany i debuger się uruchomi. Nie znalazłem niestety sposobu aby przekonać trueSTUDIO do debugowania tego klona tak więc w CubeIDE pewnie też będzie problem. Trzeba pamiętać aby przywrócić oryginalne pliki stm32f1x.cfg po zmianie płytki na oryginalny STM32. Czasami zdarza się, że debuger się zatnie, tj. nie zamknie sesji prawidłowo przez co jej wątek wisi w systemie i nie da się uruchomić debugowania ponownie. Pomaga wyłączenie wątku eabi-... przez w systemie operacyjnym alt+ctrl+del lub konsolę czy monitor systemu w linuxie. Oprócz ilości pamięci jest jeszcze jedna ważna różnica pomiędzy oryginalnym STM32F103C8T6 a CKS, tym razem na korzyść STM a mianowicie możliwość przetaktowania. STM32 będzie działał poprawnie przy taktowaniu ponad 120MHz chiński klon natomiast przetaktować się już nie da powyżej 72MHz. Na koniec jeszcze przykładowy plik main.c, blink za pomocą freeRTOS. Aby móc go sobie uruchomić do debugowania trzeba utworzyć nowy projekt C/C++ typu Ac6 wybrać odpowiedni procesor na blue pillu C8T6 lub CBT6, w kolejnym oknie dodać freeRTOS i podmienić plik main.c w projekcie na przykładowy. Miłego debugowania. #include "stm32f1xx.h" #include "FreeRTOS.h" #include "task.h" // Przedrostki funkcji np. v lub i pochodz¹ od zwracanych typów np. void lub int // Przedrostkiem prv zaczynaj¹ siê funkcje prywatne czyli statyczne static void prvSetupHardware(void); void vLEDTask(void *); //! Przydalaby sie wlasna struktura inicjalizujaca HAL int main(void){ prvSetupHardware(); /// Creating tasks Start: // dynamiczna alokacja pamiêci xTaskCreate( vLEDTask, "LEDTask", 100, NULL, 1, NULL );// (adres funkcji,dowolna nazwa, wielkosc stosu dla zadania w bajtach, opcjonalny parametr, priorytet wywolywania funkcji 1 - 9, wskaznik do konkretnego adresu pamiêci lub null) // statyczna alokacja pamiêci //xTaskCreateStatic(); /// End tasks creating // Glówna funkcja RTOS vTaskStartScheduler(); for(;;); // stack overflow // Kod programu jest podzielony na zadania, funkcja main sluzy tylko do // tworzenia zadañ poczatkowych. } //------------------------------------------------------------ void vLEDTask(void *pvParameters) { // Powinna byc w systemie funkcja umozliwiajaca zmiane // wartosci pvParameters z zewnatrz tutaj argument nie jest uzywany TickType_t xMonotonicClockState; // Pobiera aktualny czas systemwy // dziala podobnie do millis w arduino xMonotonicClockState = xTaskGetTickCount(); for(;;){ HAL_GPIO_TogglePin (GPIOC, GPIO_PIN_13); // Po przelaczeniu kreci sie w tym tasku vTaskDelayUntil(&xMonotonicClockState, pdMS_TO_TICKS(100)); } vTaskDelete(NULL); } /* void vApplicationTickHook(void){ //! Ta funkcja jest wykonywana w przerwaniu od ticka systemowego //! aby dodac tê funkcjonalnosc nale¿y w pliku FreeRTOSConfig.h //! #define configUSE_TICK_HOOK 1 //! Dzia³anie podobne do IDLE_HOOK z ta róznica, ze IDLE jest //! wykonywana podczas stanu bezczynnosci po oczyszczeniu pamiêci //! z zakoñczonych tasków. } void vApplicationIdleHook(void){ //! Ta funkcja jest wykonywana podczas idle state. } */ static void prvSetupHardware(void){ //inicjalizacja na podstawie kursu forbota SystemCoreClock = 8000000; // taktowanie 8Mhz HAL_Init(); __HAL_RCC_GPIOC_CLK_ENABLE(); GPIO_InitTypeDef LedC13 = { // obiekt gpio bêd¹cy konfiguracj¹ portów GPIO GPIO_PIN_13, // konfigurujemy pin 5 GPIO_MODE_OUTPUT_PP, // jako wyjscie GPIO_NOPULL, // rezystory podciagajace sa wylaczone GPIO_SPEED_FREQ_LOW // nieskie czêstotliwosci przelaczania }; HAL_GPIO_Init(GPIOC, &LedC13); // inicjalizacja portu GPIOC }