Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Stm32f407 Discovery, C, WorkbenchSTM32, PWM TIMER4 nie uruchamia się.

25 Mar 2020 21:06 339 19
  • Poziom 8  
    Witam

    Chcę uruchomić timer4 dla pinu PD12 w trybie PWM. Dłubię kod już drugi dzień i na oscyloskopie nadal brak jakiejkolwiek reakcji. Zaznajomiłem się z tym tematem: topic3080858, ale występują tam makra, których mój workbench nie posiada.
    Bardzo proszę o nakierowanie co robię źle.

    Kod: c
    Zaloguj się, aby zobaczyć kod
  • Poziom 8  
    Fakt, nie wiedziałem o tym, że należy również w tym rejestrze wybrać funkcję. Zgodnie z RM - piny 8-15 AFRH AF2 (TIM3...TIM5).
    Dodałem linijkę:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    W obsłudze procedury przerwania prócz update'a flagi przerwania nic więcej nie mam - czy powinno być tam coś jeszcze ?

    W ostatnim pytaniu masz rację - ustawiałem kanał 4, który dotyczy PD15 a nie PD12. Tutaj ewidentnie się pomyliłem.
    Niestety, po zmianach nadal brak efektów.
  • Poziom 23  
    Uruchamiasz licznik w trybie OnePulseMode, zatem po jednokrotnym przeliczeniu licznik staje i ustawia bit TIM_CR1_CEN na 0, potem już nic nie robi. Żeby zaczął liczyć należy ponownie go wyzwolić choćby poprzez ponowne ustawienie TIM_CR1_CEN. Na początek wywal ten OPM i próbuj uruchomić licznik w trybie ciągłym

    Dodatkowo włączasz przerwanie TIM4_IRQn, ale nie masz jego obsługi pewnie, więc program ląduje do HardFault.
    Wg RM PD12 tyczy się AF2 dla TIM4_CH1, jak pisze Kolega wyżej, dla TIM4_CH4 jest dedykowany pin PD15.
    Generalnie masz pomieszane ustawienia z CH1 oraz CH4. Wg mnie warto sobie z CubeMX wyeksportować pinologię np do Excela i mieć pod ręką funkcje alternatywne dla pinów.
    Oprócz tego koniecznie zacznij od poradnika Szczywronka, masz tam raczej wszystko na tacy co jest tematem tego wątku.

    Jeszcze jedno na początku włączasz zegary dla licznika oraz GPIOD zarazem wyłączając wszystkie inne z AHB1ENR. Pisze to, żebyś po uporaniu się z problemem wątku nie wpadł od razu w inny problem z resztą kodu.
  • Poziom 8  
    @simw Dzięki za uwagi. Usunąłem wskazane przez Ciebie rzeczy. Niestety nie znalazłem makro do ustawienia tego AFR'a i wyszedł taki dziwoląg. Z książki podanej korzystam, ale kod jest dla F013, nie mniej porównam je oba jeszcze raz dokładnie.
    Cytat:
    Wg mnie warto sobie z CubeMX wyeksportować pinologię np do Excela i mieć pod ręką funkcje alternatywne dla pinów.
    Sprawdze sobie to jak to działa, dzięki.

    Bieżący kod wygląda tak (nadal nie działa):
    Kod: c
    Zaloguj się, aby zobaczyć kod
  • Specjalista - Mikrokontrolery
    mietus012 napisał:
    GPIOD->AFR[1] &= ~0x00000F00;

    Abstrahując od tego, czy ustawienie AF2 to akurat to co chcesz zrobić, to powyższa linijka z pewnością _NIE_ robi tego co chciałeś. Generalnie ona nic nie zrobi - pin dalej będzie miał wybrane AF0.

    mietus012 napisał:
    GPIOD->OTYPER |= GPIO_OType_PP;
    GPIOD->OSPEEDR |= GPIO_Speed_100MHz;
    GPIOD->PUPDR |= GPIO_PuPd_NOPULL;

    Powyższe 3 linijki z poprawne jedynie "przypadkiem" - do rejestrów nie należy wpisywać makr/wartości przeznaczonych dla HALa, tylko makra/wartości przeznaczone dla tych rejestrów, np. coś na styl GPIO_OTYPER_... GPIO_OSPEEDR_... i GPIO_PUPDR_...

    A samo przerwanie dla zwykłego PWMa jest Ci kompletnie zbędne i do niczego niepotrzebne.
  • Pomocny post
    Poziom 23  
    mietus012 napisał:
    GPIOD->AFR[1] &= ~0x00000F00;

    A cóż to ma wg Ciebie robić?
    Przecież masz ustawić na ostatnich 4 bitach (PD15) liczbę 2 - co odpowiada AF2, zatem:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Spróbuj używać stałych z CMSIS, będzie łatwiej to ogarniać.

    Dodano po 14 [minuty]:

    Jeszcze tu masz błąd: TIM4->CCR1 = 50;
    Powinno być: TIM4->CCR4 = 50;

    Dodano po 1 [minuty]:

    Działający kod wygląda tak:
    Kod: c
    Zaloguj się, aby zobaczyć kod
  • Poziom 8  
    Dziękuję wszystkim za uwagi. Kod oczywiście działa.

    Cytat:
    Powyższe 3 linijki z poprawne jedynie "przypadkiem" - do rejestrów nie należy wpisywać makr/wartości przeznaczonych dla HALa, tylko makra/wartości przeznaczone dla tych rejestrów, np. coś na styl GPIO_OTYPER_... GPIO_OSPEEDR_... i GPIOD_PUPDR_...


    Niestety żadnych takich makr nie znalazłem, nie wiedziałem, że używam ich błędnie.

    Cytat:
    Spróbuj używać stałych z CMSIS, będzie łatwiej to ogarniać.

    Chodzi o makra w stm32f4xx.h - aby tych używać ?

    Kod: c
    Zaloguj się, aby zobaczyć kod

    Workbench nie rozpoznaje tych makr (próbowałem zainkludować stm32f4xx.h z CMSIS).
    Dzięki jeszcze raz za uwagi, każda informacja co robię źle jest dla mnie istotna.
  • Specjalista - Mikrokontrolery
    mietus012 napisał:
    Niestety żadnych takich makr nie znalazłem, nie wiedziałem, że używam ich błędnie.

    Są zaraz obok innych, które znalazłeś. Masz w swoim kodzie np.:
    GPIOD->MODER |= GPIO_MODER_MODER12_1;
    I to jest właśnie OK. Makra o których piszę są zdefiniowane w dokładnie tym samym pliku co powyższe GPIO_MODER_MODER12_1.

    mietus012 napisał:
    Workbench nie rozpoznaje tych makr (próbowałem zainkludować stm32f4xx.h z CMSIS).

    Dla tej dyskusji istotne jest jedynie to, czy program z takimi makrami się kompiluje czy nie. To czy IDE je potrafi zinterpretować jest tu bez znaczenia.
  • Poziom 8  
    Cytat:
    Są zaraz obok innych, które znalazłeś. Masz w swoim kodzie np.:
    GPIOD->MODER |= GPIO_MODER_MODER12_1;

    Sorry, moje niedopatrzenie.

    Cytat:
    Dla tej dyskusji istotne jest jedynie to, czy program z takimi makrami się kompiluje czy nie. To czy IDE je potrafi zinterpretować jest tu bez znaczenia.

    Napisałem nieprecyzyjnie - nie rozpoznaje i nie kompiluje się (środowisko System Workbench for STM32).
  • Specjalista - Mikrokontrolery
    mietus012 napisał:
    Napisałem nieprecyzyjnie - nie rozpoznaje i nie kompiluje się (środowisko System Workbench for STM32).

    Zapewne w tym co wkleił simw wyżej jest jakaś drobna literówka czy coś takiego. Przejrzyj plik w którym masz GPIO_MODER_MODER12_1 i znajdziesz też resztę.
  • Poziom 8  
    Ok, dzięki za odpowiedź. Proszę jeszcze o wyjaśnienie kwestii litery 'U' przy przesunięciu bitowym:

    Kod: c
    Zaloguj się, aby zobaczyć kod
  • Specjalista - Mikrokontrolery
    mietus012 napisał:
    Ok, dzięki za odpowiedź. Proszę jeszcze o wyjaśnienie kwestii litery 'U' przy przesunięciu bitowym:

    Nie no, weź nie idź tą durną drogą. W tych nagłówkach _SĄ_ odpowiednie makra. Na pewno.

    "u" jest zaś zupełnie zbędne w tym przypadku - niczego nie zmienia i niczemu specjalnemu nie służy. Już bardziej sensowne byłoby po lewej stronie operatora, ale i tak by nic nie zmieniało w tej sytuacji.

    Znajdź sobie plik stm32f407xx.h, a w nim masz np.:
    Code:
    #define GPIO_OSPEEDR_OSPEED15_Pos        (30U)                                 
    
    #define GPIO_OSPEEDR_OSPEED15_Msk        (0x3UL << GPIO_OSPEEDR_OSPEED15_Pos)   /*!< 0xC0000000 */
    #define GPIO_OSPEEDR_OSPEED15            GPIO_OSPEEDR_OSPEED15_Msk     

    Code:
    #define GPIO_AFRH_AFSEL15_Pos            (28U)                                 
    
    #define GPIO_AFRH_AFSEL15_Msk            (0xFUL << GPIO_AFRH_AFSEL15_Pos)       /*!< 0xF0000000 */
    #define GPIO_AFRH_AFSEL15                GPIO_AFRH_AFSEL15_Msk 

    Code:
    #define GPIO_PUPDR_PUPD0_Pos             (0U)                                  
    
    #define GPIO_PUPDR_PUPD0_Msk             (0x3UL << GPIO_PUPDR_PUPD0_Pos)        /*!< 0x00000003 */
    #define GPIO_PUPDR_PUPD0                 GPIO_PUPDR_PUPD0_Msk                 
    #define GPIO_PUPDR_PUPD0_0               (0x1UL << GPIO_PUPDR_PUPD0_Pos)        /*!< 0x00000001 */
    #define GPIO_PUPDR_PUPD0_1               (0x2UL << GPIO_PUPDR_PUPD0_Pos)        /*!< 0x00000002 */
    #define GPIO_PUPDR_PUPD1_Pos             (2U)                                 
    #define GPIO_PUPDR_PUPD1_Msk             (0x3UL << GPIO_PUPDR_PUPD1_Pos)        /*!< 0x0000000C */
    #define GPIO_PUPDR_PUPD1                 GPIO_PUPDR_PUPD1_Msk                 
    #define GPIO_PUPDR_PUPD1_0               (0x1UL << GPIO_PUPDR_PUPD1_Pos)        /*!< 0x00000004 */
    #define GPIO_PUPDR_PUPD1_1               (0x2UL << GPIO_PUPDR_PUPD1_Pos)        /*!< 0x00000008 */

    itd. itd. itd.

    Jeśli takich makr tam nie masz, to albo masz te pliki uszkodzone, albo jakąś przedpotopową wersję, albo masz źle skonfigurowany projekt.

    P.S. Wcześniej sam popełniłem drobną literówkę w tym co sugerowałem, już poprawiam.
  • Poziom 23  
    Freddie Chopin napisał:
    Zapewne w tym co wkleił simw wyżej jest jakaś drobna literówka czy coś takiego.

    No w tym wypadu nie ma literówek, przykład na bieżąco kompilowałem, wgrywałem do uK. Raczej to kwestia wersji CMSIS z Cube.

    mietus012 napisał:
    Ok, dzięki za odpowiedź. Proszę jeszcze o wyjaśnienie kwestii litery 'U' przy przesunięciu bitowym:

    Te wartości to to kopiuj-wklej z nagłówków CMSIS, U oznacza unsigned

    W SW4STM najedź kursorem myszy na GPIO_MODER_MODER12_1 i kliknij z Ctrl zostaniesz przeniesiony do właściwego pliku nagłówkowego i poprzeglądaj te wpisy, jeśli masz zamiar częściej programować STM32 to polecam, aby w ten sposób zaglądać do "dokumentacji". W wielu przypadkach nie trzeba nawet zaglądać do RM, żeby rozwiązywać na bieżąco zagadnienia związane z rejestrami.
  • Poziom 8  
    Tak tak - używam zawsze ctrl'a do podglądnięcia makra. Ale mój problem z tego co widzę rozbija się o nagłówek.
    Cytat:
    Znajdź sobie plik stm32f407xx.h, a w nim masz np.:

    @Freddie Chopin podał mi bibliotekę stm32f407xx.h, ale u mnie w projekcie wszystkie są opisane w taki sposób: stm32f4xx.h. (brak 07).

    Dodam jedynie że w projekcie zawsze wybieram płytkę Discovery oraz procesor stm32F407. Natomiast przydzielane biblioteki zawsze są typu f4xx.h
    Środowisko instalowałem około miesiąc temu. Czy problem może wynikać z zaznaczania opcji Standard Peripheral Library na końcu tworzenia projektu ?
  • Pomocny post
    Specjalista - Mikrokontrolery
    mietus012 napisał:
    @Freddie Chopin podał mi bibliotekę stm32f407xx.h, ale u mnie w projekcie wszystkie są opisane w taki sposób: stm32f4xx.h. (brak 07).

    Nagłówek stm32f4xx.h "pod maską" tak naprawdę dołącza odpowiedni dla danego układu nagłówek - np. stm32f407xx.h, zależnie od tego co jest zdefiniowane globalnie w projekcie:

    Code:
    #if defined(STM32F405xx)
    
      #include "stm32f405xx.h"
    #elif defined(STM32F415xx)
      #include "stm32f415xx.h"
    #elif defined(STM32F407xx)
      #include "stm32f407xx.h"
    #elif defined(STM32F417xx)
      #include "stm32f417xx.h"
    #elif defined(STM32F427xx)
      #include "stm32f427xx.h"
    #elif defined(STM32F437xx)
      #include "stm32f437xx.h"
    #elif defined(STM32F429xx)
      #include "stm32f429xx.h"
    #elif defined(STM32F439xx)
      #include "stm32f439xx.h"
    #elif defined(STM32F401xC)
      #include "stm32f401xc.h"
    #elif defined(STM32F401xE)
      #include "stm32f401xe.h"
    #elif defined(STM32F410Tx)
      #include "stm32f410tx.h"
    #elif defined(STM32F410Cx)
      #include "stm32f410cx.h"
    #elif defined(STM32F410Rx)
      #include "stm32f410rx.h"
    #elif defined(STM32F411xE)
      #include "stm32f411xe.h"
    #elif defined(STM32F446xx)
      #include "stm32f446xx.h"
    #elif defined(STM32F469xx)
      #include "stm32f469xx.h"
    #elif defined(STM32F479xx)
      #include "stm32f479xx.h"
    #elif defined(STM32F412Cx)
      #include "stm32f412cx.h"
    #elif defined(STM32F412Zx)
      #include "stm32f412zx.h"
    #elif defined(STM32F412Rx)
      #include "stm32f412rx.h"
    #elif defined(STM32F412Vx)
      #include "stm32f412vx.h"
    #elif defined(STM32F413xx)
      #include "stm32f413xx.h"
    #elif defined(STM32F423xx)
      #include "stm32f423xx.h"
    #else
     #error "Please select first the target STM32F4xx device used in your application (in stm32f4xx.h file)"
    #endif


    mietus012 napisał:
    Czy problem może wynikać z zaznaczania opcji Standard Peripheral Library na końcu tworzenia projektu ?

    Może. Nie zaznaczaj tego. SPL jest "dead", nierozwijane i niewspierane. Jak już coś musisz wybrać, to HAL ("Hardware Abstraction Library", choć ta nazwa nie ma nic wspólnego z rzeczywistością).
  • Poziom 8  
    Ok, pobrałem firmware HAL. Skopiowany kod dotyczący TIM4 kompiluje się bez problemu więc jest ok.
    Dobra informacja jest taka, że teraz gdy klikam na podgląd makra to wyświetla mi faktycznie z biblioteki stm32f407xx.h
    Wtedy makra podane przez @simw są widoczne.

    Dzięki za całą masę cennych uwag i podpowiedzi.
  • Poziom 23  
    Wg mnie masz bardzo stare środowisko.
    Musisz koniecznie porzucić SPL, bo w tym nikt już Ci nie pomoże. Musisz pozbyć się tego balastu. Z Twojej perspektywy to pewnie mało optymistyczne, ale w dłuższej perspektywie jedyne sensowne rozwiązanie.
    To co teraz próbujesz robić to sztukowanie wielkiego ryzyka i nawet ze wsparciem forum może Ci sie nie udać tego ogarnąć.

    Jeśli środowisko instalowałeś miesiąc temu to czy przy tej okazji zrobiłeś update - Help->Chech for update? Należy to zrobić.
    To niestety całkowicie nie rozwiąże Twojego problemu, bo SystemWorkbech i tak dalej będzie stare nagłówki dołączał. Wg mnie masz dwie sensowne drogi:
    1. Zostać przy SW, ale szablony generować z CubeMX, zacząć programować w HAL lub usuwać HALa i dalej jechać na rejestrach - w taki wypadku będziesz miał kompatybilne nagłówki.

    2. Porzucić SW i zainstalować STM32CubeIDE, w najnowszej wersji nie trzeba babrać się z HALem, od razu można generować szablony pod pisanie na rejestrach, z najbardziej aktualnymi plikami nagłówkowymi.
    Drugi sposób bym zalecał.
  • Poziom 8  
    Zrobiłem update bo był do pobrania. Po dodaniu HAL'a plik main nadal wygląda jako clear:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Taka postać bez dziwnych zbędnych funkcji jest dla mnie akceptowalna.
    Interesuje mnie tylko i wyłącznie pisanie na rejestrach. Chyba na razie pozostanę przy tych zmianach.
  • Poziom 23  
    mietus012 napisał:
    aka postać bez dziwnych zbędnych funkcji jest dla mnie akceptowalna.
    Interesuje mnie tylko i wyłącznie pisanie na rejestrach. Chyba na razie pozostanę przy tych zmianach.
    Faktycznie sprawdziłem u siebie, są nowe nagłówki i można pisać na rejestrach bez zbędnego balastu.