Atollic TrueSTUDIO & CubeMX

Ja już dwa programatory tak zjarałem. Do dzisiaj nie wiem co było przyczyną.

W jaki sposób stworzyć plik do wgrania do STM32 aby umieścić 64kB blik binarny w górnej połówce flash?

W moim bluepillu jest 128KB flash (przynajmniej tak podają programy ładujące).

Nie. Chcę wykorzystać drugie 64kB do trzymania bazy z danymi, a program umieszczać standardowo w pierwszym 64kB obszarze.
Jak to zrobić?

PS. dopiero zaczynam i poznaje tą tematykę, więc proszę nie zbywać mnie krótkimi zdaniami

Jasne, że można trzymać dane we flashu. Sam tak nawet robię. Ale o wiele lepiej jest trzymać dane w górnej połowie flasha. W dolnej masz wektory przerwań.... Co prawda można je przenieść do RAM-u, ale to dodatkowa operacja. Więc po co komplikować sobie życie.

Jedni wolą Wielkanoc, drudzy Boże Narodzenie...... na początku flasha mam też bootloader, bo tak jest MI wygodniej.

O co Ci chodzi? Przecież napisałem, że tak jest MI wygodniej. Jeżeli masz ochotę, to możesz sekcję danych zrobić nawet w środku pamięci. To nie ma znaczenia.

Ja wybrałem taki podział: bootloader (ze swoimi wektorami), wektory przerwań aplikacji, kod aplikacji, dane. Aplikację uruchamiam z bootloadera. Przed uruchomieniem aplikacji ustawiam nowy adres tablicy wektorów przerwań (rejestr VTOR). Moim zdaniem jest wygodniej, jeżeli dane są ułożone w sposób opisany powyżej. Ale oczywiście nie uważam, że mam monopol na dobre pomysły, więc jeżeli znasz inne, lepsze, wygodniejsze lub choćby ciekawsze rozwiązanie, to je opisz - chętnie nauczę się czegoś nowego.

Zmieniłem STM32 na inny model i CubeMX przy próbie tworzenia i zapisu nowo utworzonego kodu zaczyna ściągać instalkę do nowego procesora i po chwili pokazuje błąd:
stm32cube_fw_f4_vXXX.zip (MD5 file checksum in not good)
Tak jest dla wszystkich wersji instalek tego procesora.

Gdy sam ściągnąłem z jakieś strony stm32cube_fw_f4_vXXX.zip pojawia się błąd:
These Files have problem during Download: stm32cube_fw_f4_vXXX.zip (MD5 file checksum in not good)

Jak to zainstalować poprawnie?

CubeMX mam w wersji 4.18.0

Czy nowa wersja będzie otwierać starsze pliki i już wygeneruje nowszy kod na podstawie tego starszego .ioc?

Czy lepiej najpierw odinstalować starszą wersję?

OK, zainstalowałem najnowszą wersję i wszystko poszło bezboleśnie
Jednak w Atollicu pojawił się błąd w nowo wygenerowanym kodzie:
w pliku stm32f4xx_hal_conf.h mam: Unresolved inclusion: "stm32f4xx_hal_dma_ex.h"

Czy ten problem powoduje CubeMX i jak temu zaradzić?

Nie naginajmy tego stwierdzenia "trzeba czasem pomyśleć", bo działa ono w obydwie strony...

Nie ma tego w katalogach projektu. Ściągnąłem ten plik z internetu, ale skąd mam wiedzieć, czy jest to ten którego szukam.
Na razie wszystko jest OK, ale dlaczego CubeMX podrzuca "braki"?

stmx wrote:

Rafal_777 wrote:

Nie naginajmy tego stwierdzenia "trzeba czasem pomyśleć", bo działa ono w obydwie strony...

I do sieci trzeba było iść .... A wystarczy ...



I masz tam ten, z którego Cube "czerpie"

Rafal_777 wrote:

ale dlaczego CubeMX podrzuca "braki"?

Niczego nie podrzuca tylko czegos nie odchaczyłeś i Cube zobił to co mu kazałeś.

A nie przyszło ci do głowy, że w katalogu Repository nie ma tego pliku i właśnie tam go ręcznie wrzuciłem...

Dzisiaj przesiadłem się na stm32l433 i znowu CubeMX stworzył kod w którym TrueStudio pokazuje błędy:
Unresolved inclusion: "stm32l4xx_hal_exti.h"
Unresolved inclusion: "stm32l4xx_hal_dma_ex.h"

Mam teraz CubeMX 5.2.0 który ściągną sobie STM32Cube FW_L4 V1.6.0.

Czy ja coś robię źle, czy to norma w kodach CubeMX?

PS: poza tym gdy sprawdziłem działanie dla FATFS to tu również pojawiła się niekompatybilność plików z informacją w pliku ff.h o różnych revizjach plików. Czy w tym przypadku wystarczy sztucznie zmienić numer rewizji, czy to może powodować później błędy?

Pojawiło się nowe narzędzie STM32CubeIDE, które jest połączeniem TrueStudio oraz STM32CubeMX https://www.st.com/en/development-tools/stm32cubeide.html