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

STM32 - obsługa przerwań od UART podczas zapisu do pamięci flash mikrokontrolera

prawicowiec 24 Lip 2017 20:02 1584 19
  • #1 24 Lip 2017 20:02
    prawicowiec
    Poziom 7  

    Witam

    Czy obsługa przerwań STM32F1 od UARTa nie koliduje z jednoczesnym zapisem do pamięci flash mikrokontrolera (czy podczas zapisu do pamięci flash nie są blokowane przerwania) ?

    0 19
  • #2 25 Lip 2017 09:35
    arturt134
    Poziom 26  

    Wydaje mi się, że jedyne ograniczenie, to takie, że podczas zapisu do FLASH nie można z niej czytać, czyli procedura obsługi przerwania musi być w RAM-ie i nie może odwoływać się do pamięci FLASH.

    0
  • #3 25 Lip 2017 10:43
    BlueDraco
    Specjalista - Mikrokontrolery

    Podczas zapisu do Flash w uC, które mają jeden bank Flash, próba odczytu powoduje zatrzymanie procesora i poczekania do końca zapisu. Nie jest to problemem przy obsłudze przerwań UART, bo czas zapisu jest krótszy, niż czas transmisji znaku przez UART.

    1
  • #4 26 Lip 2017 08:46
    prawicowiec
    Poziom 7  

    uC zapisuje za każdym razem 64 bajty danych do pamięci flash

    0
  • #5 26 Lip 2017 13:49
    BlueDraco
    Specjalista - Mikrokontrolery

    A jaki to ma związek z Twoim problemem? Jeśli nie robisz tego w przerwaniu o priorytecie wyższym od przerwania UART - nie ma to znaczenia. Przerwanie UART może zostać obsłużone pomiędzy zapisami kolejnych porcji danych.

    0
  • #6 26 Lip 2017 14:37
    2675900
    Użytkownik usunął konto  
  • #7 26 Lip 2017 22:24
    prawicowiec
    Poziom 7  

    Urządzenie wykonuje pomiary co kilkanaście minut i w zależności czy jest połączenie GPRS wysyła dane po sieci. Jeżeli z jakiegoś powodu nie ma połączenia to zapisuje wyniki pomiaru do pamięci flash mikrokontrolera. Urządzenie pełni rolę SLAVE a ja komunikuję się w dowolnej chwili z wykorzystaniem Modbus RTU przez RS485 i odczytuję bieżące wyniki, które są zapisane w pamięci RAM. Zdarza się, że odpowiedz którą otrzymuję od urządzenia jest błędna tak jakby gubił dane ramki Modbus RTU. Wcześniej napisałem program który tylko obsługuje komunikację SLAVE Modbus RTU i działa b. dobrze (przetestowałem przy pomocy terminala i panelu WEINTEK). Zaimplementowałem ten kod do właściwego kodu programu urządzenia no i właśnie zdarza się, że gubi mi dane zapytania (nie ma wtedy odpowiedzi urządzenia bo ramka jest zapewne błędna) lub wysyła nieprawidłową ramkę (brakuje w niej części danych). Szukam przyczyny i jedynie co przychodzi mi do głowy to konflikt, że w momencie zapisu/odczytu z pamięci flash nieprawidłowo działa obsługa Modbus RTU albo konflikt w momencie gdy urządzenie zapisuje dane do pamięci RAM a ja w tym samym momencie odczytuję te dane Modbus'em. Niestety nie wiem jak sobie poradzić z tym problemem. Co jeszcze bardziej komplikuje to urządzenie może też wysyłać dane do pamięci zewnętrznej po I2C jak również wysyłać komendy po innym UART do SIM900. Tak jak pisałem nie mam zielonego pojęcia co powoduje ten konflikt

    0
  • #8 26 Lip 2017 22:36
    2675900
    Użytkownik usunął konto  
  • #9 27 Lip 2017 00:06
    BlueDraco
    Specjalista - Mikrokontrolery

    To za mało - w RAM musiałaby się znaleźć tablica adresów procedur obsługi wyjątków oraz wszystkie funkcje wołane z procedury przerwania (np. SPL).

    Moim zdaniem problem leży gdzie indziej, np. w źle napisanej obsłudze przerwań UART lub w grubszym błędzie koncepcyjnym.

    0
  • #10 27 Lip 2017 07:18
    arturt134
    Poziom 26  

    Ja też uważam, że problem nie wynika z zapisu do pamięci FLASH.
    Gdybym to ja miał szukać rozwiązania, to najpierw spróbowałbym wyłączyć większość funkcjonalności programu, żeby doprowadzić do sytuacji gdy problem zniknie (w skrajnym przypadku zostanie Ci tylko obsługa Modbus RTU :). Wtedy po kolei zacząłbym włączać poszczególne moduły programu, tak aby się przekonać gdzie występuje konflikt. Jak już namierzysz przyczynę, to dalej powinno pójść z górki.

    0
  • #11 27 Lip 2017 14:46
    QuadMan
    Poziom 13  

    Witam,

    BlueDraco napisał:
    ...Nie jest to problemem przy obsłudze przerwań UART, bo czas zapisu jest krótszy, niż czas transmisji znaku przez UART.


    ale, czy aby na pewno? Czas zapisu dla STM32F103 to według DS 20-70us, więc dla szybkości transmisji rzędu 230400bps może być "cienko". Zdaję sobie sprawę, że w tym konkretnym przypadku nic takiego się nie wydarzy ( jakoś nie wyobrażam sobie MB pracującego z taką szybkością transmisji), chodzi mi jedynie o to, że nieraz trzeba brać to pod uwagę.
    Kolejna sprawa: kol prawicowiec nic nie napisał o kasowaniu tego FLASHA - jeśli coś stale do niego pisze, to pewnie też go od czasu do czasu kasuje, a kasowanie strony to 20-40ms, a to już może być problemem.
    Tak, czy siak - dyskusja czysto akademicka - wystarczy przecież na próbę zrezygnować z zapisów do FLASH-a i już wszystko będzie jasne.

    Pozdrawiam, QuadMan.

    0
  • #12 27 Lip 2017 21:54
    BlueDraco
    Specjalista - Mikrokontrolery

    Każdy UART ma przynajmniej podwójny bufor, więc przy 230400 mamy max. częstotliwość bajtów 23040, czyli ponad 40 us na bajt, czyli ponad 80 us na obsługę dwóch kolejnych przerwań. Z kasowaniem oczywiście racja. W razie czego jest jeszcze DMA, ale użycie DMA do odbioru UART to dość pokręcona technika.

    0
  • #13 27 Lip 2017 21:58
    2675900
    Użytkownik usunął konto  
  • #14 30 Lip 2017 19:59
    prawicowiec
    Poziom 7  

    Nie mogę pokazać kodu ponieważ nie jestem jego właścicielem.

    USART2 wykorzystywany jest do komunikacji z SIM900, USART1 oraz TIM3 do Modbus RTU.

    Jakie ustawić priorytety od w/w źródeł przerwań ?

    0
  • #15 30 Lip 2017 22:12
    2675900
    Użytkownik usunął konto  
  • #16 30 Lis 2017 11:40
    xadamus
    Poziom 9  

    To ja podniose temat: chodzi o uszczegółowienie logiki działania procesora przy zapisie do wewnetrznego flash.
    Jesli wykonuje zapis do flash to kontroler wstrzymuje dzialanie programu na czas zapisu/kasowania - to oczywiste. I jesli przychodzi przerwanie a obsluga jest w RAM (tak jak i wektor przerwan) to przerwanie wykonuje sie - to tez oczywiste.
    Niech teraz przychodza dwa przerwania: najpierw przerwanie z obsluga we flash - wykonanie kodu zostanie wstrzymane bo flash nie jest gotowy, ale jesli za chwile przyjdzie przerwanie z obslugą w RAM o wyzszym priorytecie to sie wykona ? A przerwanie o priorytecie nizszym niz to z obsługa we flash nie? (troche zakecone, ale mam nadzieje ze da sie zrozumiec).

    0
  • #17 30 Lis 2017 12:08
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Jeśli podczas zapisu do flash układ próbuje odczytać coś z flash, rdzeń zostanie zatrzymany do momentu zakończenia zapisu. Nie ma więc czegoś takiego, że zostanie zatrzymany (czy to przez następne instrukcje w funkcji dokonującej zapisu - np. sprawdzenie flagi czy zapis się już zakończył - czy przez przerwanie, czy przez cokolwiek innego), ale jak przyjdzie przerwanie i akurat będzie w RAM, to nagle się magicznie uruchomi i je wykona, żeby potem się znów zablokować. Jeśli już się zatrzyma, to zostanie zatrzymany do zakończenia zapisu. Przynajmniej ja to tak rozumiem (;

    0
  • #18 30 Lis 2017 12:24
    2675900
    Użytkownik usunął konto  
  • #19 30 Lis 2017 12:26
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Przecież napisałem dokładnie to samo w pierwszym zdaniu - "Jeśli podczas zapisu do flash układ próbuje odczytać coś z flash...".

    0
  • #20 01 Gru 2017 20:41
    xadamus
    Poziom 9  

    Ok dzieki. Czyli jesli kasujemy lub zapisujemy flasha wykonujac procedurę z pamięci flash, to nawet jesli handlery przewan sa umieszczone w RAM tak samo jak i tablica przerwan, to zadne przerwanie w RAM sie juz nie wykona do czasu skonczenia operacji na flash.

    0