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-bo
otloader

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ć?

do góry

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

> 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ć?

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

A czym ci podpadł st-link?

do góry

On 15/10/2023 22:50, Dawid Rutkowski wrote:
> A czym ci podpadł st-link?

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.

do góry

On 15/10/2023 22:29, heby wrote:
> Fabryczny jest niestabilny.

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.

do góry

W dniu 2023-10-15 o 23:20, heby pisze:
> On 15/10/2023 22:29, heby wrote:
>> Fabryczny jest niestabilny.
>
> 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.
>

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.

do góry

On 16/10/2023 16:30, Piotr Gałka wrote:
> 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.

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.

do góry

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

> Tutaj problem polega na tym, że fabryczny booloader stara się w
> pierwszej kolejności stwierdzić, czy programowanie będzie na UART

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.

do góry

On 16/10/2023 18:44, Piotr Gałka wrote:
> 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).

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

do góry

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.

do góry

niedziela, 15 października 2023 o 23:21:11 UTC+2 heby napisał(a):
> On 15/10/2023 22:29, heby wrote:
> > Fabryczny jest niestabilny.
>
> 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.

To pomaga na fabryczny czy na stm32duino?

do góry