Przy uruchamianiu laptopa DELL z Win7 z podłączoną płytka STM32VL Discovery na USB, nie startuje mi windows. Ekran pusty, tylko u góry ledwo widoczne piksele. Próbowałem w systemie zmieniać botowanie usb i nic. Jest ok, jeśli podłącze płytkę po uruchomieniu windowsa. Czy tak ma być, czy tez trzeba coś ustawić, zmienić itp. Proszę o radę. Płytka kupiona na Allegro.

Moje boje z STM32 na razie na płytce STM32VL Discovery muszę uznać za udane. Wreszcie ogarniam te nowe procki i programowanie. Dużo tego do przetrawienia. Dzięki koledze SunRiver-owi za jego bardzo pomocne artykuły. Przydatne tez bardzo są książki o STM32 panów Paprockiego i Galewskiego.

A jeszcze jedno pytanie. Na razie męczę CooCox v1.77. Nawet niezły. Czasem przy starcie pojawia mi się taki komunikat


Coś mu się nie podoba. Chwilę lapek myśli i komunikat znika i jest wszystko ok. Na ile, tego nie wiem. Albo coś z Javą albo z CooCox v1.77 najnowszy, może jeszcze nie dopracowany.

Jestem jeszcze na początkowym etapie zabawy z STM32 i będę chciał spróbować paczki Eclipse Luny SunRiver-a. Troche mi brakuje tych kolorków i wcięć z Eclipse na AVR-y. Jakie jest wasze zdanie CooCox czy Eclipse Luna ?

Z góry dziękuje za rady i pomoc.

Całkiem możliwe że wykrywa ci pamięć masową na VL i próbuje się botoować z niej .... wyłącz w biosie botowanie z pamięci przenośnych , albo po prostu podłączaj płytkę po uruchomieniu komputera



wygląda na jakis problem z javą ...



proponuje keplera ... gdyż plugin ARM trochę z luną źle działa .. a na Keplerku ... a zresztą poczytaj na stronie bedziesz wiedział co się porobiło w keplerze gwoli ST-linka i cierpliwie poczekaj na marsa stable ...

Zaciąłem się na dwa sposoby. Pierwszy to nie mogę odejść od lapka. Wciągający temat. Ale jak zwykle na tym etapie zdarzają się i tego rodzaju zacięcia



No i utknąłem jak Kubuś Puchatek w dziurze. Może pomożecie mi ruszyć. Program który uruchamiam pochodzi z książki "STM32... " M. Galewskiego "LCD - odliczanie" . Po mikro adaptacjach doszedłem do tego miejsca i stop.



Problem rozwiązany. Dodałem biblioteke syscalls z repository->common ->C library i jest ok. Nie ma jak się zaciąć.

czasem tak się dzieje ... niemniej niema co się zniechęcać ja jednak coIDE odpusciłem bo cocoox zepsuł workspace

W pliku print.c znalazłem taki fragment z syntax error, te pytajniki obok.


i chyba przez to mam sporo warningów. Próbuję to rozwiązać na razie bez efektu.

wiesz no ... po pytajnikach nie wiem co to ma za błąd być może tak byś jego treść wskazał ??
bo syntax error to tylko tzw: syn większego errora -- > żartuję ,

to błąd składni -- czyli coś nie tak z tym wpisem , ale może byc tresć błędu jakaś dokładniejsza ??

To ostrzeżenie to być może ma jakiś związek z tym że w programach pana Galewskiego stringi pisze np. "odliczanie\0" czego CooCox nie trawi. Po usunięciu \0 co jak wiadomo automatycznie jest dodawane problem zniknął. I LCD wreszcie mi ruszył.
Natomiast staram się rozwiązać następujący problem z ustawieniem częstotliwości zegara PLL. Otóż wyrzuca mi błąd gdy umieszczę wiersz 85 a z wierszem 84 jest ok. Niby to samo a jednak ciągle mnie zastanawia dlaczego tak jest.



Tu na drugim obrazku jest definiowany ten parametr ale warunkowo.



Czy idzie z tym coś zrobić ?
Podejrzewam że ma to coś z definiowaniem USE_STDPERIPH_DRIVER i STM32F10X_MD_VL .
W Keil MDK4 to działa.

Coś mi się wydaje jakby linia VL nie miała PLL. Trochę się pogubiłem.

kwestia toolchaina niestety ..
a pętla PLL jest i w linii VL ... zerknij do noty na obwody czasowe taktowania ew do pomocnika STM32 Cube

Dzięki SunRiver za wsparcie.
Zgadza się, PLL jest w STM32VL (24MHz) a już myślałem przez chwilę że go nie ma.
Małe pytanie w temacie konfiguracji portu, czy dla "GPIO_InitStructure.GPIO_Speed = GPIO_Speed_xMHz;" (x = 2 lub 10 lub 50MHz) to xMHz <=SYSCLK ? Wydaje mi się że tak jest, ale czy na pewno ? Czyli maksymalna szybkość przełączania portu dla STM32VL może być 2 lub 10MHz. Czy możesz to moje rozumowanie potwierdzić.

Czy koledzy mogą mi podpowiedzieć gdzie robię błąd ?

W pliku display_led.h mam z definiowane



W pliku main.c są one widziane ,



natomiast w pliku stm32f10x_it.h , w obsługiwanym przerwaniu już nie



sygnalizuje mi błąd :



Jeśli podmienię na GPIOC to jest ok.

Podobnie jest ze zmiennymi w pliku display_led.h jeśli chcę ich użyć w przerwaniu.


Deklaracje, definicje zewnętrzne dla pliku przerwań są niewidoczne.

Includy są w dobrej kolejności.

Gdzie robię błąd ? Czy jeszcze czegoś nie dołączyłem ?

Program do obsługi 6-ciu multipleksowanych segmentów wyświetlaczy LED. Na razie to ćwiczenie, ale utknąłem i ani kroku do przodu.

Czyli masz include dla display_led.h w pliku z przerwaniami ?

_________________
sig off ;(

Nie, w przerwaniu nie mam.

W pliku main.c mam



W pliku display_led.h mam



W pliku stm32f10x_conf.h mam odblokowane


Nawet jeśli zadeklaruję zmienną globalna w main.c to nie jest ona widziana w przerwaniu.
Przykładowo



w przerwaniu



i efekt




Zastanowiło mnie teraz twoje "czyli masz...", a może "czy mam...
i dałem w pliku stm32f10x_it.h



i przynajmniej jest ok z LED_SEGM

Zastanawiam się co trzeba zrobić aby przerwanie zobaczyło definicję zmiennej globalnej z z main.c ?
Zastanawia mnie to powyżej /* Private variables ---------------------------------------------------------*/

w main.c sprobuj

_________________
sig off ;(

Z extern też nie poszło.
Musi być jakiś niuans.
Powtórzyłem deklarację z main.c w pliku stm32f10x_it.c zmiennej z. Przy czym w main.c jest z "extern volatile unsigned char z;"
A tu poniżej bez extern.



I niby poszło. Bez błędu. Ale czy takie powtórzenie deklaracji to jest ok. Czy z i z to ta sama zmienna.
Muszę to jakoś sprawdzić.

Zobacz to topic10273.html#p114809

_________________
sig off ;(

Dzisiaj wyskoczył mi przy uruchamianiu Coocox'a komunikat "An error has accured. See the log file" i stop. Nie da rady uruchomić programu. Ale na szczęście po surfowałem w necie i znalazłem to, że trzeba usunąć katalog w "Coide/configuration/ProgramData/.metadata/.plugins/Org.eclipse.core.resources" i elegancko Coide ruszył.

Ale wracając do tych zmiennych niewidocznych w innych plikach dołączanych, to nadal się męczę i coś jednak jest nie tak.
W sumie np. zmienna "extern volatile unsigned char z;" zdefiniowana przed main w głównym pliku jako zmienna globalna a na dodatek "extern" powinna być widoczna wszędzie. Jakiś niuans musi być. Czekam na pomoc i podpowiedź.

W main.c zostaw:

natomiast w stm32f10x_it.h albo w stm32f10x_it.c dodaj

i wtedy powinien widzieć tą zmienną w przerwaniu.

_________________
40-32:2=4!

@PJS ze sie tak zapytam ... czy to na pewno jest dobre podejscie ? nie jest tak ze w 2 miejscach deklarujesz zmienne ?

_________________
sig off ;(

extern wskazuje, że dana zmienna została już gdzieś indziej zadeklarowana i nie jest to ponowna deklaracja tej zmiennej.
Spójrz np. tu: http://4programmers.net/C/Extern

_________________
40-32:2=4!

Dzięki, zmienne extern już działaja i rozumiem o co chodzi.
Ale jak mówią i dalej w las tym więcej drzew.
Aktualnie bawię się w uruchomienie na moim STM32VLDiscovery prosty licznik zliczający impulsy z encodera i wyświetlający wynik na wyświetlaczu LED.
I tu pełny sukces, liczy i wyświetla ok, załączam kod



i obsługa przerwania



Lecz zastanawia mnie przekierowanie licznika TIM3 czyli tzw ramp.
Otóż wejścia na PC6 i PC7 czyli kanał 1 i 2 jest ok. Ale jednocześnie mam zablokowane piny portu PC8 i PC9, które akurat są podłączone na płytce discovery do LED-ów. Z dokumentacji wynika, że mogą lub są podłączone przez ramp do kanału 3 i 4 licznika TIM3. Jak je odłączyć aby w przyszłości wykorzystać je do innych celów. Aktualnie są bezużyteczne.

Zarówno parametr, aktualnie mam ustawiony na "GPIO_FullRemap_TIM3 : TIM3 Full Alternate Function mapping" ,
ale zmiana na " GPIO_PartialRemap_TIM3 : TIM3 Partial Alternate Function mapping"
nic nie zmienia.

Widać w przerwaniu, moją wstawkę na toglowanie LED, lecz niestety to nie działa. Natomiast zmienna "z" jest ok.

Jak sobie z ty poradzić ?

A ustawiasz gdzieś PC8 i PC9 jako wyjścia?

Tak, tylko po tych niepowodzeniach usunąłem ten fragment. Jeśli dopiszę w pliku konfiguracyjnym GPIO_Pin8



To zapali się dioda LED na PC8 ale brak możliwości wpływania na ten port. Podobnie jest z PC9.
Dzieje się tak, jakby ramp przyporządkowywał kanały 1-4 do PC6, 7, 8, 9.
Na razie te piny nie wykorzystuję, ale gdy będzie potrzeba to kłopot.

I coś znalazłem w książce Paprockiego

Wyprowadzenia alternatywne dla TIM3
Domyślne TM3_CH1-4 PA6, PA7, PB0, PB1
Częściowy ramping TM3_CH1-4 PB4, PB5, PB0, PB1
Całkowity ramping TM3_CH1-4 PC6, PC7, PC8, PC9

Teraz muszę sprawdzić na domyślnym, bo na całkowitym to już wiem dlaczego.

Dobra, powoli

1. Nie ramp tylko remap.
2. Z tego co zrozumiałem Twój post, problem jest następujący: chcesz mieć TIM3_CH1 i TIM3_CH2 na PC6 i PC7. W związku z tym korzystasz z funkcji remappingu. Jednocześnie chcesz korzystać z PC8 i PC9 jako normalnych GPIO, right?
3. Co nowego wnosi cytat z książki? To samo masz w dokumentacji (Reference Manual RM0008):

4. Tego nie rozumiem - "domyślnie" to bez remappingu - czyli nie będziesz miał CH1/2 na PC6/7 - a przecież o to właśnie chodziło?
5. Ja nie wiem. Napisałem program uruchamiający TIM3 w trybie enkodera, "full remapujący" TIM3 na PC6,7,8,9 i machający PC8 i PC9 jako normalnymi GPIO... działa zgodnie z założeniem. Na screenie przebiegi z PC8 i PC9.


Kod:

Także ten... albo ja nie rozumiem co rozumiesz jako problem, albo masz błąd w kodzie

Dzięki wwojtek. Na spokojnie przeanalizuję. Tym bardziej że zrobiłem remap jako domyślny, czyli no remap na PA6 i PA7 i mam to samo. Czyli PC8 i PC9 nie działa. Cudów nie ma, gdzieś błąd w kodzie.


No i znalazłem. Złą maskę wpisałem (~licznik & 0x03FF) zamiast prawidłowo (~licznik & 0x003F). W obsłudze przerwania od TIM1



W brew pozorom takie błędy sprawiają że szukając go można się sporo nauczyć i to nowych rzeczy, szczególnie na początku nauki.