Keil uVision MDK-Lite, płyta STM32F072B-Discovery i Flash API

Używam MDK-Lite w wersji 5.23 z płytą „Discovery” STMicroelectronics STM32F072B-Disco i próbuję użyć przykładu Flash dostarczonego przez próbki Discovery.

Użyłem tej płyty i łańcucha narzędzi do innych przykładów i napisałem trochę pracy w SPI i GPIO. IDE działa jak mistrz. Jednak w przypadku tego konkretnego projektu mogę zbudować kod i uruchomić go, pobierając i używając przycisku resetowania. Nie mogę użyć debugera w projekcie, jak tylko użyję procedury HAL_FLASHEx_Erase (). Po uruchomieniu tej procedury IDE wyświetla okno dialogowe „Nie można uzyskać dostępu do celu. Zamykanie sesji debugowania”.

Co do tego, co warto, wiem, że nie jest to błąd programowy, ponieważ jeśli pobiorę kod, a następnie wykonam go, naciskając przycisk reset, zadziała. Użyłem tego samego debugera z płytą TI i był on również w stanie zaprogramować flash i wykonać procedury flashowania. Jestem prawie pewien, że nie usuwam części flasha, w której przechowywany jest kod, więc to nie tak.

Jeśli przekroczę tę linię w main.c

if (HAL_FLASHEx_Erase(&EraseInitStruct, &PageError) != HAL_OK)

następnie przerywa sesję debugowania. Jeśli zamiast tego wejdę do tej samej linii, a następnie przejdę przez każde z wywołań procedury usuwania pamięci flash, to zadziała i ostatecznie wyjdzie poza procedurę i będę mógł debugować resztę kodu.

Domyślam się, że na pewnym poziomie jest to zasilacz. Zasilanie zewnętrzne lub przełączanie szyn zasilających na pokładzie.

Aby wyjaśnić scenariusz, debugowanie działa dobrze po resecie sprzętowym, ale kiedy twój cel usuwa blok flash, połączenie debugowania jest przerywane?

Debugowanie nie dba o prawidłowe działanie kodu - możesz być w stanie blokady, a zatrzymanie debugowania powinno nadal działać. Jedyną rzeczą po stronie procesora, która blokuje debugowanie, jest zablokowany dostęp AHB. Oznacza to, że problem dotyczy albo interfejsu SWD między STM32F7, a wbudowanym układem interfejsu USB-SWD (również przypuszczam, że STM32). To urządzenie ma wbudowane przełączanie szyny zasilającej, co pomieszało mnie przy pierwszym użyciu płyty.

Warto zauważyć, że wymazywanie flash zwiększy bieżące zużycie urządzenia - czy Twój zewnętrzny zasilacz spełnia swoje zadanie i czy możesz użyć alternatywy?

Edycja: W oparciu o twoją opinię, że przekroczenie tego kodu powoduje awarię debugera, podczas gdy jednoetapowe nie, myślę, że twój problem jest związany z tym pytaniem .

Przełączanie jest realizowane przy użyciu punktu przerwania (i odpytywania dla stanu zatrzymania), podczas gdy pojedynczy krok jest obsługiwany sprzętowo. To nadal nie wyjaśnia, dlaczego debugger wydaje się być zdezorientowany, ale pozwala na to, że debuger próbuje uzyskać dostęp do kodu (z pamięci flash), gdy kontroler pamięci flash jest aktywny.

W oparciu o te obserwacje zasugerowałbym, aby ustawić punkt przerwania po wymazaniu i starać się unikać uruchamiania tego scenariusza.