Najlepszy bootloader USB do programowania STM32F401 (WeAct BlackPill)

Sun Oct 15, 2023 10:29 pm   

Cześć.

Chciałbym programować STM32F401 przez USB, bez podpinania STLinka.

Mam płytkę BlackPill (WeAct), ale pytanie jest bardziej generyczne, bo
ocelowo to będzie siedziało na moim PCB.

Jaki bootoader, obecnie, do tego typu CPU jest polecany?

Widzę np. STM32duino-bootloader, ale opis w readme powoduje u mnie
wywracanie kiszek (winny złej kompilacji jest za nowy gcc i iluminaci).

https://github.com/rogerclarkmelbourne/STM32duino-bootloader

Widzę też STM32 HID Bootloader

https://github.com/Serasidis/STM32_HID_Bootloader

ale nie mam pewności co to jakości, używanie HID z resztą to jakiś
workaround.

A dlaczego rozglądam się za jakimś bootoladerem?

Fabryczny jest niestabilny. Zgłasza się w 1 na 4 resety. W pozostałych 3
przypadkach nie akceptuje adresu USB. Sprawdziłem to na mojej płytce i
jeszcze na innej i mam podobne efekty.

Jest jescze coś, co powinienem obejrzeć?

Sun Oct 15, 2023 10:50 pm   

niedziela, 15 października 2023 o 22:30:28 UTC+2 heby napisał(a):


Brzmi jak ponury żart w ten piękny wieczór
(a jutro wstaję o 6 ).

A czym ci podpadł st-link?

Sun Oct 15, 2023 10:59 pm   

On 15/10/2023 22:50, Dawid Rutkowski wrote:

Niczym. Używam. Ale w tym konkretnym wypadku wygodniej mi będzie dać
komuś urządzenie z ganizdem USB niż z prośbą o dokupienie STLinka.

Chciałbym mieć wygodne upgrade firmware w wersji finalnej.

Projekt będzie OpenSource, więc taki bootloader jest ok.

Sun Oct 15, 2023 11:20 pm   

On 15/10/2023 22:29, heby wrote:

Jaki ten usenet jest wspaniały. Ledwie wysłałem posta, przypadkiem
trafiłem na:

https://www.stm32duino.com/viewtopic.php?t=1807

"[...]Solution: Tying A10 to GND successfully makes it enter DFU
bootloader mode 100% of the time[...]".

Sprawdziłem. Potwierdzam.

Mon Oct 16, 2023 4:30 pm   

W dniu 2023-10-15 o 23:20, heby pisze:

Nie znam się na bootloaderach (brat to robi) ale dwa skojarzenia z tym
co napisałeś:

Jak projektowałem (ponad rok temu - więc szczegóły w pamięci już trochę
zatarte) płytkę z EFM32HG309F64G-C-QFN24 to:
- któraś noga z jakiegoś booloaderowatego powodu miała być podwieszona,
- brat narzekał, że jakieś ich (Silabsa) narzędzie gadające z ich
własnym bootloaderem w procku po USB potrafiło powiesić cały komputer.

Jak potem robił swoją obsługę USB (bazując na ich bibliotece) to mi coś
opowiadał o problemie 64 bajtów.
Na tyle na ile to zapamiętałem to jak USB (nie znam się aby określić
jakiego trybu to się tyczy) rozbija dłuższe transmisje na bloki po 64
bajty to jak cała transmisja jest wielokrotnością 64 to tam był jakiś
problem z ostatnią ramką.
Tego, że był problem z ostatnią ramką to jestem pewien, ale jaki to już
nie. Możliwe, że dosyłana jest na koniec ramka pusta a ich hardware
głupiał jak rozmiar był 0 a ich biblioteka nie miała obejścia tego
problemu. A może odwrotnie - czekał na kolejną ramkę, której już nie było.
Jeśli ta sama biblioteka była użyta w tym ich bootloaderze (co jest
przecież prawdopodobne) to by wyjaśniało możliwe problemy.
P.G.

Mon Oct 16, 2023 4:41 pm   

On 16/10/2023 16:30, Piotr Gałka wrote:

Tutaj problem polega na tym, że fabryczny booloader stara się w
pierwszej kolejności stwierdzić, czy programowanie będzie na UART czy
USB. Ponieważ niepodwieszona noga RX UARTu powoduje szum, traktowane
jest to jako komunikacja po UART i bootloader nie odpala USB.

Rozwiązaniem było by uruchomienie wewnętrznego pullupa przed testem
komunikacji. Dorobienie tego pullupa ręcznie rozwiązuje problem, RX nie
szumi, bootoader przechodzi do obsługi USB.

Mon Oct 16, 2023 6:44 pm   

W dniu 2023-10-16 o 16:41, heby pisze:


To pewnie też był powód podwieszenia u nas bo chyba bootloader też mógł
komunikować się i po UART i po USB.
Pisałeś, że do GND, u nas było (według jakiegoś opisu i tak zrobiłem na
płytce) do VCC (co dla UARTa wydaje się logiczniejsze).
P.G.

Mon Oct 16, 2023 6:47 pm   

On 16/10/2023 18:44, Piotr Gałka wrote:

Wystarczy podpiąc do bylegdzie, bo wygląda na to, że detekcja ruchu na
UART polega na szukaniu zboczy, nie stanów.

Mon Oct 16, 2023 7:11 pm   

Zbieg okoliczności :)

Gdy ja coś w tym wątku napisałem brat akurat wrócił do tych płytek
sprzed roku.
Rok temu w czasie uruchamiania softu (nasze pierwsze podejście do 32
bitowego procka - ever) było tak, że raz zaprogramowana płytka już jest
odkładana na bok - nie mieliśmy opanowanego kasowania wszystkiego do
zera i wgrywania ich bootloadera i nie mieliśmy czasu się tym zajmować
bo to było ratunkowe robienie produktu zastępującego inny na prockach,
które stały się niedostępne - czyli robota była 'na wczoraj'. W ten
sposób kilkanaście płytek (kolejne wersje naszego softu) wylądowało w
poczekalni, że kiedyś się je odzyska.
Wtedy w ogóle obowiązywała jeszcze koncepcja, że (tak jak z AtXmega)
sami będziemy z prockami gadać po DEBUG, ale ileś tam rzeczy nam
działało, ale nie wszystkie, a te ich programatory wysyłają jakieś setki
rozkazów bez ładu i składu - postanowiliśmy sobie odpuścić, szczególnie,
że od jakiegoś czasu mamy 2-etapową produkcję, i pierwszy wsad nie
wymaga wstawiania kluczy, które mój program generuje na bieżąco w czasie
produkcji urządzeń.

Na płytce robimy normalnie 3 pinowe (raster 1,27) złącze DEBUG i dla
innych Silabsów to wystarcza. Ich programator (Silabsa płytka
uruchomieniowa) potrafi wykasować procesor.
Nie wiem dlaczego wersja programu na PC, którą na produkcji programują
te procesory nie potrafi ich wykasować. Podobno dopiero programator,
który jest w całym środowisku uruchomieniowym potrafi.
Dlatego ostatnio przysłali nam ileś płytek do wyczyszczenia. Brat je
wszystkie (późniejsze projekty z innym prockami Silabsa - bez USB)
wyczyścił i dotarł do tych z USB i program twierdzi, że wyczyścił, a
potem nie potrafi się z prockiem dogadać. Stąd godzinę temu konsultacja
ze mną - czy mi się coś nie kojarzy. A mi się kojarzyło, że z jakiegoś
powodu na tej płytce wyprowadzałem też pin reset.

Brat, do normalnego kabelka dodał jeden przewód, aby dało się go w ten
reset wetknąć i dosłownie przed sekundą dał znać, że sukces - te płytki
też dało się przywrócić do stanu początkowego
P.G.

Mon Oct 16, 2023 9:42 pm   

niedziela, 15 października 2023 o 23:21:11 UTC+2 heby napisał(a):

To pomaga na fabryczny czy na stm32duino?

Mon Oct 16, 2023 10:01 pm   

On 16/10/2023 21:42, Dawid Rutkowski wrote:

To pomaga na goły STM32F401. Czy jakieś płytki mają ten RX podpięty,
podciągniety czy cokolwiek, nie wiem. Mój nie ma (Black Pill).

Mon Oct 16, 2023 10:06 pm   

poniedziałek, 16 października 2023 o 22:01:35 UTC+2 heby napisał(a):

I dobrze że nie ma.
Nie oglądałem - miejsce na kabelek jest?
Ciekawe czy jest o tym w jakimś manualu.

Mon Oct 16, 2023 10:08 pm   

On 16/10/2023 22:06, Dawid Rutkowski wrote:

Pin jest. To taka płytka z goldpinami.


Ponoć wspominają, ale kto by tam czytał datashit-y mające po 1k+ stron.

Tue Oct 17, 2023 12:14 pm   

W dniu 2023-10-16 o 22:08, heby pisze:


Mi się wydaje, że czasem trzeba.

Dziś/jutro będę próbował się doczytać czy RTC, które podobno jest w
EFM32PG23... to da się użyć, czy muszę dać scalak RTC na zewnątrz.
Główna wątpliwość - z tego co na razie wiem to nie ma żadnej nogi, która
byłaby przeznaczona do podłączenia baterii/supercapa do podtrzymania RTC.
P.G.

Tue Oct 17, 2023 1:14 pm   

On 17/10/2023 12:14, Piotr Gałka wrote:


RTC może oznaczać różne rzeczy. Dla Ciebie to zegar podtrzymywany
baterią (tym jest 'RTC' w PC i tym są 'moduły RTC' które można kupić do
jakiegoś Arduino), ale jako element mikrokontrolera to po prostu jeden z
zegarów, ten który zawsze liczy sekundy/godziny, a nie jakieś inne cykle
i może np. obudzić maszynę o zadanej porze ze stanu uśpienia, ale bez
normalnego zasilania nie działa.

Jacek