No tak - nie zauważyłem tego na początku a też użyłem STM32CubeIDE ... ale to dlatego, że nie miałem zainstalowanego ST-Linka poprawnie. Dzięki
------------------------ [ Dodano po: 16 minutach ]
ale zaraz - zaraz - bawię się teraz tym i okazuje się, że np jestem w projekcie Bluepill i klikam RUN - a on mi go bez żadnego problemu wgrywa do całkiem innego procka. W Blupilu jest stm32F1x .... a ja mam podłączony procek stm32F4x
no i ciekawostka - program się naprawdę wgrywa i mój procek dostaje świra tzn - dioda która miała migać przestaje migać !!!
tak ma być ?
Zdarzało się tak i mnie, że "wchodził" program z innego procka, ale to jest wg mnie błąd i pewnie wynika ze specyfiki (elastyczności bym nazwał) samego interfejsu SWD.
W takim wypadku oczywiście program nie będzie działał poprawnie - co raczej jest oczywiste
. Z ciekawości warto podglądnąć jak działa ST-link utility. Tam, w przeciwieństwie do AVR, nie potrzeba podawać typu procesora, rodzaj procka jest wykrywany automatycznie podczas inicjalizacji interfejsu SWD.
Co do CubeIDE, domyślnie za wgrywanie wsadów oraz debugger odpowiada GDB server, oprócz tego jest jeszcze OpenOCD do wyboru. Udało mi się ustalić, że ten pierwszy nie sprawdza procka i wgrywa jak leci. Ten drugi zwraca błędy i nie da się zaprogramować nieodpowiedniego uK.
Statystyki: Napisane przez Zealota — 14 wrz 2020, o 11:49
]]>