Goto page 1, 2 Next
Atlantis
Guest
Wed Aug 07, 2019 12:04 pm
Eksperymentuję właśnie z mikrokontrolerem PIC24fj256da210. Złożyłem
własną płytkę prototypową i powoli z nią eksperymentuję. Udało mi się
odpalić timer, UART, USB i zamigać paroma diodami.
Zauważyłem natomiast dziwne zachowanie niektórych pinów GPIO. Mianowicie:
Mam na płytce cztery diody LED, podłączone do pinów RB0..RB3. Te na RB1
i RB2 migają prawidłowo. Natomiast RB0 i RB3 nie jestem w stanie
uruchomić. Wszystkie piny są ustawione jako cyfrowe wyjścia, no i
znajdują się na tym samym porcie...
Nie byłem też w stanie zmienić stanu RB12 oraz coś jest nie tak z SPI
(wydaje mi się, że PPS skonfigurowany prawidłowo). Podejrzewam, że
przyczyna może być ta sama.
Ktoś ma jakiś pomysł co do tego, co może być nie tak? Czyżby coś o
wyższym priorytecie było domyślnie włączone po resecie, roszcząc sobie
prawo do niektórych pinów?
cezar
Guest
Wed Aug 07, 2019 12:39 pm
On 07/08/2019 13:04, Atlantis wrote:
Quote:
Eksperymentuję właśnie z mikrokontrolerem PIC24fj256da210. Złożyłem
własną płytkę prototypową i powoli z nią eksperymentuję. Udało mi się
odpalić timer, UART, USB i zamigać paroma diodami.
Zauważyłem natomiast dziwne zachowanie niektórych pinów GPIO. Mianowicie:
Mam na płytce cztery diody LED, podłączone do pinów RB0..RB3. Te na RB1
i RB2 migają prawidłowo. Natomiast RB0 i RB3 nie jestem w stanie
uruchomić. Wszystkie piny są ustawione jako cyfrowe wyjścia, no i
znajdują się na tym samym porcie...
Nie byłem też w stanie zmienić stanu RB12 oraz coś jest nie tak z SPI
(wydaje mi się, że PPS skonfigurowany prawidłowo). Podejrzewam, że
przyczyna może być ta sama.
Ktoś ma jakiś pomysł co do tego, co może być nie tak? Czyżby coś o
wyższym priorytecie było domyślnie włączone po resecie, roszcząc sobie
prawo do niektórych pinów?
Nie znam sie ale ludzie na forach piszą że trzeba pisać do LATx a nie do
PORTx
c.
Marek
Guest
Wed Aug 07, 2019 3:45 pm
On Wed, 7 Aug 2019 14:04:05 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:
Quote:
Ktoś ma jakiś pomysł co do tego, co może być nie tak? Czyżby coś o
wyższym priorytecie było domyślnie włączone po resecie, roszcząc
sobie
prawo do niektórych pinów?
W jaki sposób ustawiasz porty na cyfrowe? Należy używać io API wtedy
ma się pewność że inne nadrzędne peryferia portu zostaną wyłączone.
--
Marek
Atlantis
Guest
Thu Aug 08, 2019 6:57 pm
On 07.08.2019 17:45, Marek wrote:
Quote:
W jaki sposób ustawiasz porty na cyfrowe? Należy używać io API wtedy ma
się pewność że inne nadrzędne peryferia portu zostaną wyłączone.
Za pośrednictwem rejestrów. Z tego co widzę biblioteka do obsługi
peryferiów dla PIC24 jest dość uboga - nawet autorzy podręczników z
którymi miałem do czynienia operowali bezpośrednio na rejestrach. No
chyba, że jest jakaś wersja Harmony dla PIC24 - z tymi bibliotekami
jeszcze nie eksperymentowałem.
W każdym razie problem udało mi się rozwiązać, chociaż nie jestem pewien
co jest przyczyną. Po prostu zamiast wpisywać od razu wartość do
rejestru konfigurującego piny na cyfrowe/analogowe, ustawiłem wszystkie
jako analogowe, a potem pojedynczo poustawiałem te, które mnie
interesowały. Zadziałało. Możliwe, że we wcześniejszej wersji gdzieś
miałem błąd, którego nie mogłem się doszukać.
Udało mi się uruchomić SPI oraz podłączony do niego ENC28J60, razem z
TCP/IP (biblioteka z MLA). Działa też FatFS podpięty do biblioteki USB
MSD Host.
Pojawił się jednak problem, gdy próbowałem uruchomić FatFS z pamięcią
SPI Flash (układ z serii SST25*). Wykorzystałem sterownik od Microchipa,
który bez problemu działał na PIC32, ale jego kod jest napisany w sposób
uniwersalny i zawiera sekcje do kompilacji warunkowej dla PIC24.
Sterownik się kompiluje, ale jakakolwiek operacja ale każda operacja na
nośniku jakiej próbowałem (formatowanie, montowanie itp.) powoduje reset
mikrokontrolera. W rejestrze RCON mam ustawiony bit IOPUWR.
Zgodnie z dokumentacją:
"An illegal opcode detection, an illegal address mode or uninitialized W
register is used as an Address Pointer and caused a Reset".
Ktoś ma jakiś pomysł co do możliwej przyczyny? W jaki sposób dalej to
debugować, aby ustalić dokładne miejsce wystąpienia problemu?
Atlantis
Guest
Fri Aug 09, 2019 5:06 am
Ok, próbowałem debugować i widzę, że problem jest trochę inny, niż się
wydaje. O dziwo winny nie jest sterownik SPIFlash, ale biblioteka USB z
MLA. Nie wiem dlaczego, ale problem ujawnia się dopiero wtedy, gdy
włączę obsługę SPIFlash.
Co udało mi się ustalić:
1) Ustawiłem funkcję do obsługi przerwań "trap".
2) Po wystąpieniu błędu uruchomione zostaje przerwanie "_AddressError".
3) Prześledzenie wywołań na stosie wygląda następująco: main() ->
f_mount() -> USBHostInit(). Poniższa linia ma wywoływać _AddressError:
pCurrentEndpoint = usbDeviceInfo.pEndpoint0;
Jakiś pomysł co do tego, co może być nie tak?
Heap ustawiony ze sporym zapasem (10k). Sam MCU ma sporo pamięci RAM
(96k), a w chwili obecnej 76% jest wolne na stos.
Marek
Guest
Sat Aug 10, 2019 8:31 am
On Fri, 9 Aug 2019 07:06:47 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:
Quote:
wydaje. O dziwo winny nie jest sterownik SPIFlash, ale biblioteka
USB
Pamiętam miałeś kiedyś wyjątek przy uruchomieniu USB hid na pic32 a
to ta sama biblioteka.... Co to wtedy było? A może to ten sam
problem?
--
Marek
Atlantis
Guest
Sat Aug 10, 2019 11:15 am
On 10.08.2019 10:31, Marek wrote:
Quote:
Pamiętam miałeś kiedyś wyjątek przy uruchomieniu USB hid na pic32 a to
ta sama biblioteka.... Co to wtedy było? A może to ten sam problem?
Problem już rozwiązałem. Okazało się, że należało zmniejszyć rozmiar
sterty w ustawieniach linkera.
heby
Guest
Sat Aug 10, 2019 1:06 pm
On 10/08/2019 13:15, Atlantis wrote:
Quote:
Pamiętam miałeś kiedyś wyjątek przy uruchomieniu USB hid na pic32 a to
ta sama biblioteka.... Co to wtedy było? A może to ten sam problem?
Problem już rozwiązałem. Okazało się, że należało zmniejszyć rozmiar
sterty w ustawieniach linkera.
Nie dobrał się prawidłowy po wybraniu procesora?
Mialem kiedyś wpadkę z SAM7 atmela, dostarczone przez nich skrypty
linkera miały błedy adres pamięci flash. Ale oni mieli taki wtedy
bałagan z plikami .h i linkerem że pod koniec sprawdzałem każdą linijkę
ręcznie bo ilośc bugów można było wyjasnić tylko ciężką pracą zespołu
N-studentów w trybie czołgowym.
Marek
Guest
Sat Aug 10, 2019 3:38 pm
On Sat, 10 Aug 2019 15:06:11 +0200, heby <heby@poczta.onet.pl> wrote:
Quote:
Nie dobrał się prawidłowy po wybraniu procesora?
Przecież rozmiar określa programista wiedząc ile tego będzie
potrzebowal na malloc
--
Marek
Marek
Guest
Sat Aug 10, 2019 3:40 pm
On Sat, 10 Aug 2019 13:15:48 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:
Quote:
Problem już rozwiązałem. Okazało się, że należało zmniejszyć rozmiar
sterty w ustawieniach linkera.
Zmniejszyć? Jakby była za mała i zabrala to co potrzebuje linker
na min stos plus zmienne globalne wyrzuciłby błąd...
--
Marek
heby
Guest
Sat Aug 10, 2019 4:13 pm
On 10/08/2019 17:38, Marek wrote:
Quote:
On Sat, 10 Aug 2019 15:06:11 +0200, heby <heby@poczta.onet.pl> wrote:
Nie dobrał się prawidłowy po wybraniu procesora?
Przecież rozmiar określa programista wiedząc ile tego będzie
potrzebowal na malloc
Dlatego pytam. Domyślne skrypty linkera miewają bajer że heap jest
określany jako "od końca zmiennych globalnych do końca pamięci". Co
oznacza że może być zdefiniowany jako default do konkretnego modelu cpu
i nic nie stoi na przeszkodzie aby go dowolnie manipulować. Jednak
pojęcie "koniec pamięci" zazwyczaj występuje ślicznie określone w
skrypcie linkera w związku z modelem cpu.
Atlantis
Guest
Sat Aug 10, 2019 10:44 pm
On 10.08.2019 17:40, Marek wrote:
Quote:
Zmniejszyć? Jakby była za mała i zabrala to co potrzebuje linker na
min stos plus zmienne globalne wyrzuciłby błąd...
Tak. Sam jestem zaskoczony. W moich projektach na PIC32 ustawiałem
zwykle stertę na 2048 bajty, gdy korzystałem z bibliotek do obsługi USB.
Tym razem ustawiłem kilka razy więcej (najpierw 8kB, potem 10kB)
korzystając z fakty, że ten konkretny PIC24 dysponuje sporą ilością RAM-u.
Powrót do 2kB rozwiązał problem.
Marek
Guest
Sun Aug 11, 2019 6:56 am
On Sat, 10 Aug 2019 18:13:05 +0200, heby <heby@poczta.onet.pl> wrote:
Quote:
Dlatego pytam. Domyślne skrypty linkera miewają bajer że heap jest
określany jako "od końca zmiennych globalnych do końca pamięci".
Stos owszem tak się robi i ma to uzasadnienie ale sterta? To trochę
bez sens, jaki toolchain tak robi?
Kwestia główna jest taka, że błąd powodowała za duża sterta co jest
dziwne.
--
Marek
Grzegorz Niemirowski
Guest
Sun Aug 11, 2019 8:46 am
heby <heby@poczta.onet.pl> napisał(a):
Quote:
Dlatego pytam. Domyślne skrypty linkera miewają bajer że heap jest
określany jako "od końca zmiennych globalnych do końca pamięci".
A gdzie stos?
--
Grzegorz Niemirowski
https://www.grzegorz.net/
heby
Guest
Sun Aug 11, 2019 10:15 am
On 11/08/2019 10:46, Grzegorz Niemirowski wrote:
Quote:
Dlatego pytam. Domyślne skrypty linkera miewają bajer że heap jest
określany jako "od końca zmiennych globalnych do końca pamięci".
A gdzie stos?
Np. przed zmiennymi globalnymi albo w miejscu wymuszonym architekurą,
albo na końcu pamięci po sekcji heapu itd itp. Wszystko w skrypcie
linkera. Rzecz w tym że domyslny skrypt do KONKRETNEGO procesora
zazwyczaj ma to dobrze ustawione (sprawdzić czy nie Atmel).
Goto page 1, 2 Next