problem z programowaniem zewnętrznego STM32 z programatora Nucleo

[bestsiwy]

Cześć.

 

Do tej pory w zastosowaniach hobbystycznych używałem modułów Nucleo. Jednak teraz postanowiłem zaprojektować własną płytkę PCB ze zintegrowanym STM32L476RG, czyli takim samym jak w kursie. Zrobiłem wyprowadzenia do programowania na goldpinach i połączyłem je do odpowiednich złącz na procesorze zgodnie z dokumentacją programatora. Jest też zworka do BOOT. 

No i niestety nie jestem w stanie zaprogramować procesora. Próba wgrania przez STM32CubeIDE kończy się błędem komunikacji, załączam poniżej.

Początkowo źle podłączyłem zasilanie, ale doczytałem w oficjalnej dokumentacji, że zasilanie powinno iść z mojego urządzenia do programatora, a nie odwrotnie. Poprawiłem to połączenie pobierając 5V bezpośrednio z płytki. Sprawdziłem woltomierzem i jestem pewny, że napięcie dochodzi zarówno do procesora jak i do programatora. Styki procesora również nie mają zwarcia, sprawdzone pod mikroskopem i przedzwonione multimetrem podczas montażu. Zworki CN2 zdjęte.

 

Proszę o pomoc w rozwiązaniu problemu. Pierwszy raz próbuję zrobić niezależny system ze zintegrowanym procesorem i robiłem port programowania na oko, czytając doku i podobne projekty. 

 

https://www.st.com/en/evaluation-tools/nucleo-l476rg.html#documentation 

[H1M4W4R1]

22 minuty temu, bestsiwy napisał:

To nie problem sprzętowy tylko programowy - IDE nie widzi programatora (brak połączenia)... Sprawdziłbym czy adres i port GDB są prawidłowo ustawione.

[bestsiwy]

Sprawdziłem i porty są zgodne.

Natomiast nie bardzo wiem jak sprawdzić adres. 

 

[H1M4W4R1]

2 godziny temu, bestsiwy napisał:

Sprawdziłem i porty są zgodne.

Niby wszystko się zgadza... innych pomysłów nie mam poza opcją przestawienia na serwer lokalny przy wyborze połączenia (pierwsza opcja od góry). Do nauki i testowania powinno wystarczyć. 

Ewentualnie płytka może nie mieć zasilania (według opisu raczej to nie jest problem)...

Edytowano 27 czerwca przez H1M4W4R1

[KatzePL]

Sprawdź zaporę...

[bestsiwy]

Tylko dlaczego w takim razie mogę zaprogramować Procek wbudowany w nucleo? 
Generalnie nie mam problemu z zaprogramowaniem samej płytki (wzorki cn2 założone), wtedy wszystko jest ok. Natomiast kiedy je zdejmę i podłączę zewnętrzny procesor (taki sam jak ten na płytce) to występuje powyższy błąd. 

Edytowano 29 czerwca przez bestsiwy

[Treker (Damian Szymański)]

@bestsiwy a masz pewność, że ten drugi mikrokontroler jest poprawnie podłączony i da się go zaprogramować? Jeśli masz drugie Nucleo to możesz zrobić test i jednym Nucleo zaprogramować mikrokontroler w drugim. Będziesz miał jasne, czy winny jest programator, czy mikrokontroler.

[bestsiwy]

6 godzin temu, Treker napisał:

@bestsiwy a masz pewność, że ten drugi mikrokontroler jest poprawnie podłączony i da się go zaprogramować? Jeśli masz drugie Nucleo to możesz zrobić test i jednym Nucleo zaprogramować mikrokontroler w drugim. Będziesz miał jasne, czy winny jest programator, czy mikrokontroler.

Mam pewność, że ten na płytce Nucleo programuje się poprawnie, bo używam go na co dzień do prototypowania. Natomiast nie dam sobie głowy uciąć, czy ten STM który jest wlutowany w zaprojektowaną przeze mnie płytkę jest w pełni sprawny, bo to świeżak z hurtowni. Wiem, że napięcie dociera, natomiast nie widzę innej drogi na stwierdzenie czy działa jak tylko udany proces programowania. 

Teraz przyszła mi do głowy jedna rzecz. Czy da się podłączyć równolegle dwa procesory i je zaprogramować? Chodzi mi o to, żeby zmostkować na goldpinach ten który jest na nucleo.

[74HC04]

19 godzin temu, bestsiwy napisał:

Teraz przyszła mi do głowy jedna rzecz. Czy da się podłączyć równolegle dwa procesory i je zaprogramować? Chodzi mi o to, żeby zmostkować na goldpinach ten który jest na nucleo.

Nie można programować dwóch procesorów stm32 naraz, ponieważ swd to interfejs dwukierunkowy, który nie ma adresów (w przeciwieństwie do np. I2C). Skoro jest dwukierunkowy, to znaczy że programator sprawdza, co mu wysyła programowany układ. Gdyby oba programowane układy naraz coś wysyłały, to programator by nie mógł nic poprawnie odebrać, a już nie mówiąc o sytuacji, w której jeden stm32 by miał ustawiony stan wysoki, a drugi stm32 niski. 

 

Skoro mikrokontroler jest fabrycznie nowy, to może nie mieć ustawionego włączonego swd. Często jak mam problem z przesłaniem programu na stm32, pomaga zmiana ustawienia Reset behaviour w sekcji debugger w Run Configurations. W ramach testu ustaw Connect under reset i upewnij się, że pin reset w stm32 jest podłączony dobrze do programatora.

 

A czy masz podłączone 5V do Vdd, czy 3.3V?

Edytowano 30 czerwca przez 74HC04

[bestsiwy]

Dzięki za sugestię. Sprawdzę ten trop. Vdd 5V. 

[74HC04]

Cytat

W dokumentacji jest tak napisane: 

1.71 V to 3.6 V power supply

STM32 nie może być zasilany bezpośrednio z 5V. To może uszkodzić mikrokontroler. Maksymalne napięcie to 3,6V, więc np. 3,3V jest odpowiednie.

Edytowano 30 czerwca przez 74HC04

[bestsiwy]

No to by tłumaczyło wiele. Wymienię kontroler na nowy i zasilę go 3,3V. Dzięki za dotychczasową pomoc. Dam znać jak zrobię jakieś postępy. 

[bestsiwy]

Witam ponownie. 

 

Jak do tej pory bez postępu. 

Dnia 30.06.2025 o 15:56, 74HC04 napisał:

STM32 nie może być zasilany bezpośrednio z 5V. To może uszkodzić mikrokontroler. Maksymalne napięcie to 3,6V, więc np. 3,3V jest odpowiednie.

Napięcie zmienione na 3,3V. Wymieniłem STM32 na nowy. Brak reakcji na programator.

Dnia 30.06.2025 o 13:13, 74HC04 napisał:

Skoro mikrokontroler jest fabrycznie nowy, to może nie mieć ustawionego włączonego swd. Często jak mam problem z przesłaniem programu na stm32, pomaga zmiana ustawienia Reset behaviour w sekcji debugger w Run Configurations. W ramach testu ustaw Connect under reset i upewnij się, że pin reset w stm32 jest podłączony dobrze do programatora.

 

A czy masz podłączone 5V do Vdd, czy 3.3V?

Pobawiłem się reset behaviour, również bez efektów. 

Natomiast NRST mam podpięty bezpośrednio, bez dodatkowego osprzętu sprzęgającego. Czyli nóżka nr 7 na STM do złącza CN4 pin 5 (licząc od gniazda USB), bez C lub R.

Cały czas mam ten błąd poniżej. Wykluczam zaporę albo uszkodzenie programatora, bo wbudowany STM32L4 w Nucleo programuje bez problemu. Dlatego niestety obstawiam błąd w HW, ale nie widzę go niestety...

 

Error in final launch sequence:

Failed to execute MI command:

target remote localhost:7184

Error message from debugger back end:

Remote replied unexpectedly to 'vMustReplyEmpty': timeout

Failed to execute MI command:

target remote localhost:7184

Error message from debugger back end:

Remote replied unexpectedly to 'vMustReplyEmpty': timeout

Remote replied unexpectedly to 'vMustReplyEmpty': timeout

 

Edytowano 4 lipca przez bestsiwy

[H1M4W4R1]

Dnia 26.06.2025 o 20:25, bestsiwy napisał:

Podrzucisz cały procek i kondensatory odsprzęgające? Bo coś mi tu nie pasuje (konkretniej pływające VBAT)...

[bestsiwy]

Pewnie. Shemat płytki z prockiem:

ARCARE_MAIN.pdf