Skocz do zawartości

etet100

Użytkownicy
  • Zawartość

    9
  • Rejestracja

  • Ostatnio

Reputacja

2 Neutralna

O etet100

  • Ranga
    2/10

Ostatnio na profilu byli

Blok z ostatnio odwiedzającymi jest wyłączony i nie jest wyświetlany innym użytkownikom.

  1. No racja, może i nie jest. W końcu wlutowałem w tą płytkę STM32F411. Z tym się łączy bez najmniejszego problemu.
  2. Reset miałem podłączony i oczywiście robiłem próby łączenia przy aktywnym resecie. Choć pojawia się pytanie JAK ONI TO ZROBILI BEZ RESETU? Bo on nie jest standardowo nigdzie wyprowadzony ani nie ma przycisku. No a urządzenie działało i trudno uwierzyć żeby akurat z programowaniem był problem. IO, CLK oraz NRST sprawdziłem. Taktowanie na pewno jest, zasilanie ogólnie też musi być skoro układ pracuje.
  3. Witam. Mam takie chińskie urządzenie do sterowania frezarką CNC NVUM_SKv1.1 (załączam słabe zdjęcie). Jest w nim kontroler STM32F205RBT6. I chciałbym podmienić program na własny. Od spodu na brzegu wyprowadzone są linie SWDIO, SWDCLK, GND i 3,3V. Reset nie jest wyprowadzony ale jest tam prosty układ z małym kondensatorkiem i rezystorem pod które można się podpiąć. Podłączyłem takiego klona STLINK v2 i niestety nie potrafię się połącyć z procesorem. Z różnymi F103 oraz F303 nie było do tej pory problemu. Sprawdzałem oscyloskopem na nóżkach procesora i zarówno IO jak i CLK wygląda ok. Próbowałem wszystkich możliwych ustawień programatora (connect under reset, hard reset, soft reset i inne). Ani razu nie udało mi się podpiąć do niego. Ma ktoś jakiś pomysł? Czy ten kontroler może mieć wyłączone SWD ? Może lepiej próbować DFU? Tylko tam boot0 podłączone jest do masy a nie chciałbym tego ciąć i się podpisać do tych ledwo widocznych ścieżek.
  4. Już kompletnie zdesperowany postanowiłem porównać pliki linkera generowane przez atollic i cubeide. Różnic jest ogólnie sporo ale zauważyłem na początku różnicę _estack = 0x2000A000; /* end of "RAM" Ram type memory */ i _estack = 0x20009FFF; /* end of "RAM" Ram type memory */ Zmieniłem to 9FFF na A000 (jak w Atollic) i poszło! Potem zacząłem zacząłem szukać pod tym kątem i jest takie coś: https://community.st.com/s/question/0D50X0000Ansc6GSQQ/stm32cubeide-linker-lptim-lsi-clock Troszkę inny kontroler, identyczne problemy, identyczne rozwiązanie. I piszą, że ST o tym wie ale się nie przejmuje. Czy to w takim razie może traktować jak poprawne rozwiązanie?
  5. Niby nowe ale to zdaje się jest oparte w dużej części na już istniejących rozwiązaniach. Ten CubeMX to przecież nic nowego. A wychodzi mi, że to on coś źle generuje. Choć mogę się w 100% mylić.
  6. Zrobiłem jeszcze raz ten sam projekt w Atollic Studio (tym razem GCC 6.3.1) i działa bezbłędnie. Czyli ten STM32CubeIDE jakoś niedobrze tworzy projekt. Ale w internecie nie ma śladu po takich przypadku. Wszystkim działa tylko mi nie.
  7. No i niestety to raczej nie jest kwestia wersji GCC. Skompilowałem ten projekt pod wersją 5 i wyszło dokładnie to samo.
  8. Ale chyba nadal istnieje tryb software? Wiem, że FPU ich nie wspiera. Wszędzie piszą, że w takiej sytuacji kompilator po prostu zrealizuje to softwarowo. Ale floaty niby drukuje. A przetestowałem to na 1000 sposobów i nie działa. A zanim zainstalowałem te nowe STM32CubeIDE to nie miałem takich problemów. Czego bym nie podstawił jako parametr %f to dostaje wartość w stylu 51275175258712571248012958901285791207581251. Tak samo czego bym nie podstawił do tego do tej metody ze zmiennymi parametrami do dostaje coś w okolicach 0. I nie ma znaczenia czy włącze te cholerne FPU czy nie. "TAK" czyli jak? Bo ten kod uprościłem na koniec. Wcześniej było przepisywanie do zmiennych i nie zmieniło to kompletnie nic. Nie wiem co łamie kod ale próbowałem na dziesiątki sposobów. Właściwie to nawet podstawienie do tej funkcji stałej nic nie zmienia. Dopiero zmiana jednego z jej parametrów z double na przykładowo int powoduje, że kod się nie wypiepsza na wywołaniu.
  9. Witam. Tworzę prostą aplikację pod Stm32CubeIDE z użycie kontrolera STM32F303 (z wbudowanym FPU). Trafiłem na dziwne problemy kiedy próbowałem użyć sprintf z włączonym wsparciem dla %f. Za każdym razem zamiast poprawnie sformatowanej liczby dostawałem bardzo długi ciąg cyfr. Znalazłem nawet na githubie jakąś inną implementację sprintf i to znowu często zamiast poprawnej wartości zwracało mi 0.00. W końcu okazało się, że problem jest z va_arg: void test(const char* format, ...) { va_list va; va_start(va, format); double arg1 = va_arg(va, double); char buf[102]; sprintf(buf, "a %.2f", arg1); va_end(va); } test("format", 0.1234); Zatrzymuje kod na linii z va_arg i widzę, że to zwraca głupoty. Obszedłem to przy pomocy takiego dziwnego rozwiązania: uint64_t doubleBinary = va_arg(va, uint32_t) | ((uint64_t)va_arg(va, uint32_t) << 32); double arg = *(double*)&doubleBinary; I tu dostaje poprawną wartość. Ale potem mam taki fragment (to z tego sprintf): static size_t _ftoa(out_fct_type out, char* buffer, size_t idx, size_t maxlen, double value, unsigned int prec, unsigned int width, unsigned int flags) { {... tu jakiś kod...} } //i wywołanie: uint64_t doubleAsInt = va_arg(va, uint32_t) | ((uint64_t)va_arg(va, uint32_t) << 32); double doubleAsDouble = *(double*)&doubleAsInt; idx = _ftoa(out, buffer, idx, maxlen, doubleAsDouble, precision, width, flags); format++; No i na tym _ftoa znowu jest problem bo zamiast wejść do procedury to kod wpada mi do: Default_Handler: Infinite_Loop: b Infinite_Loop Próbowałem wyłączyć FPU i skompilować wszystko na software. va_arg nadal nie działa ale nie ma tego crasha przy _ftoa. Potem uruchomiłem ten sam program pod starym EmBitz (GCC w wersji 5) i tam wszystko wydaje się działać bezbłędnie (na tyle na ile udało mi się sprawdzić). Przy czym te projekty nie są identycznie (mój kod jest taki sam ale to co jest generowane przez środowisko już na pewno nie). Ma ktoś pomysł jak to debugować i o co może chodzić? Nie jestem w tym specjalnie zaawansowany i skończyły mi się już pomysły. W internecie znalazłem jakieś szczątkowe informacje, że double ma 8 bajtów i z tym jest jakiś problem (niestety bez konkretów więc nic mi to nie dało).
×
×
  • Utwórz nowe...