[stm32] aktualizacja firmware przez usb (DFU i DfuSe) - nie czyści pamięci

Witam,

Mam problem z biblioteką USB-FS od STM32. Jako punkt wyjścia wybrałem sobie ich przykład z biblioteki dla Device Firmware Upgrade (wcześniej bezproblemowo pracowałem z USB HID). Przerobiłem ich projekt pod swoją płytkę (korzystam z ZL31ARM + własna płytka przyłączeniowa z obsługą USB). Wszystko się już ładnie kompiluje, sprzęt jest wykrywany jako urządzenie DFU i program DfuSe też go poprawnie widzi.

Teraz chciałem wgrać firmware przy pomocy DfuSe. Przygotowałem sobie plik *.dfu, ustawiłem wektor przerwań i początku pamięci flash w linkerze z odpowiednim offsetem (0x3800), problem jest taki: przy próbie upgrade łączy się, ale od razu staje na 0% podczas czyszczenia wewnętrznego flasha, tj "Erase Phase (0%)" i dalej już się nic nie dzieje. Program ląduje w HardFault_Handler(void).

1. pytanie chyba dość głupie, ale zapytam - czy pamięć na płytce ewaluacyjnej może być zabezpieczona że jej nie chce wyczyścić, czy to raczej wina źle napisanego bootloadera (korzystam z Atollica lite i on bez problemu programuje flasha st-linkiem, ale może ustawia jakieś bity zabezpieczające za sobą? to własnie z poziomu TrueStudio kompiluje i wgrywam bootloadera DFU)
2. czy ma znaczenie co wgrywamy (firmware w postaci pliku .dfu) na tym etapie, czy nie ma to absolutnie żadnego znaczenia, a czyszczenie i tak powinien przejść (chodzi mi o to, czy nie popełniłem jakieś błędu związanego z ustawianiem offsetów na adresach i czy to by mogło mieć wpływ) - wydaje mi się że nie powinno to mieć wpływu, a czyszczenie i tak powinien przejść...

No i ostatnie pytanie, bardziej ogólne - czy ktoś miał podobny problem? Trochę się już z tym męczę i skończyły mi się pomysły.

Będę wdzięczny za wszelką pomoc i sugestie. Kodów programów chyba nie ma sensu wklejać - są to przykłady z biblioteki. Szkoda, że nie mam zestawu ewaluacyjnego od ST, może nie wszystko przerobiłem tak jak trzeba pod swoją płytkę...

kaczart napisał:

(...) ustawiłem wektor przerwań i początku pamięci flash w linkerze z odpowiednim offsetem (0x3800)

Co to za magiczny offset?

gaskoin napisał:

kaczart napisał:

(...) ustawiłem wektor przerwań i początku pamięci flash w linkerze z odpowiednim offsetem (0x3800)

Co to za magiczny offset?

Pamięć STM32F103RB, pierwsze 14K (0x3800) zajmuje bootloader, pozostałe 114K program właściwy. W efekcie początek flash (w skrypcie linkera) zaczyna się od adresu 0x08003800. Właśnie... gdzie ja wyczytałem że tak jest akurat dla tej pamięci to już nie pamiętam.

Może tak być że przez złe adresowanie bootloader zaczyna czyścić samego siebie? To by się zgadzało, bo po próbie flashowania przez DFU, bootloader też już nie dizała (nie rozpoznaje urządzenia).

Z tym że te adresowanie dotyczy wsadu który będzie wgrywany z poziomu bootloadera. W źródłach od ST dla bibliotek DFU żadnego adresowania nie zmieniałem - muszę tego poszukać.

Dodano po 1 [godziny] 54 [minuty]:

doszedłem - czasem wystarczy jak ktoś zada proste pytanie, które daje do myślenia (dzięki gaskoin

Rozwiązanie dla potomnych: bootloader skompilowany przez truestudio lite nie mieścił się w założonych 14K.. zajmuje.. uwaga ... 30KB ! Coś mi się wydaje, że wersja lite działa bez optymalizacji i nie da się tego zmienić z poziomu IDE (czas się przesiąść na eclipse). Bootloader kasował sam siebie. Dopiero jak dałem dużo większy offset to wszystko zaczęło śmigać.

Wersja lite kompiluje z optymalizacją tylko gdy przestawisz ją z trybu debug na release, lecz wtedy nie dołącza żadnych danych do debugu - porażka.

udało Ci się dojść? Jak nie to wklej źródła i będziemy dochodzić.. tak z sufitu ciężko cokolwiek wywróżyć.