PIC24fj256da210 - dziwne zachowanie GPIO

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?

Reply to
Atlantis
Loading thread data ...

Nie znam sie ale ludzie na forach piszą że trzeba pisać do LATx a nie do PORTx

c.

Reply to
cezar

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.

Reply to
Marek

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?

Reply to
Atlantis

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.

Reply to
Atlantis

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?

Reply to
Marek

Problem już rozwiązałem. Okazało się, że należało zmniejszyć rozmiar sterty w ustawieniach linkera.

Reply to
Atlantis

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.

Reply to
heby

Przecież rozmiar określa programista wiedząc ile tego będzie potrzebowal na malloc

Reply to
Marek

Zmniejszyć? Jakby była za mała i zabrala to co potrzebuje linker na min stos plus zmienne globalne wyrzuciłby błąd...

Reply to
Marek

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.

Reply to
heby

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.

Reply to
Atlantis

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.

Reply to
Marek

heby snipped-for-privacy@poczta.onet.pl> napisał(a):

A gdzie stos?

Reply to
Grzegorz Niemirowski

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).

Reply to
heby

Coś wychodzi na to że bug jest gdzie indziej. O ile pamiętam PIC24 ma softwareowy stack. Nie jest tak że jest źle ustawiony (np tuż za sztywno

2kB heapu) i zamazuje heap w czasie pracy? Albo masz jakąś długą rekurencję?
Reply to
heby

Całkiem możliwe, że natknąłem się na kolejną anomalię, która może być związana z tym błędem. Mianowicie zabrałem się za uruchamianie serwera HTTP od Microchipa z MPFS2. Wszystko się skompilowało, jednak gdy próbuję skonfigurować sockety TCP w TCPConfig.h, układ wpada w pętlę resetów. Po każdym restarcie mam ustawiony bit, który wskazuje na tę przyczynę, co ostatnio (jeszcze nie sprawdziłem, czy wywołuje się to samo przerwanie obsługi wyjątku).

Jest to o tyle dziwne, że problem pojawia się nawet wtedy, gdy dodam choćby jedno gniazdo umieszczone w pamięci ENC28J60:

{TCP_PURPOSE_HTTP_SERVER, TCP_ETH_RAM, 256, 256}

Jest więc całkiem możliwe, że problem ze zbyt dużą stertą też był objawem jakiegoś innego błędu. Jak powinienem go szukać?

Reply to
Atlantis

Linker przy kompilacji wyrzuca następujące informacje:

xc16-ld 1.32 (B)

Program Memory [Origin = 0x200, Length = 0x2a9f8]

section address length (PC units) length (bytes) (dec)

------- ------- -----------------

-------------------- .text 0x200 0x1a82 0x27c3 (10179) .const 0x1c82 0x1074 0x18ae (6318) MPFSData 0x2cf6 0x3040 0x4860 (18528) .text 0x5d36 0xbda4 0x11c76 (72822) .dinit 0x11ada 0x21c 0x32a (810) .text 0x11cf6 0x8c4 0xd26 (3366) .init.delay32 0x125ba 0x1c 0x2a (42) MPFSHelpers 0x125d6 0xe 0x15 (21)

Total program memory used (bytes): 0x1b5d6 (112086) 42%

Ivt Memory [Origin = 0x4, Length = 0xfc]

section address length (PC units) length (bytes) (dec)

------- ------- -----------------

-------------------- .ivt._T1Interrupt 0x1a 0x2 0x3 (3) .ivt._T3Interrupt 0x24 0x2 0x3 (3) .ivt._RTCCInterrupt 0x90 0x2 0x3 (3) .ivt._USB1Interrupt 0xc0 0x2 0x3 (3)

Data Memory [Origin = 0x800, Length = 0x18000]

section address alignment gaps total length (dec)

------- ------- --------------

------------------- .nbss 0x800 0 0x8e (142) .ndata 0x88e 0 0x4 (4) .nbss 0x892 0 0x4 (4) .ndata 0x896 0 0x4 (4) .nbss 0x89a 0 0x8 (8) .ndata 0x8a2 0 0x6 (6) .nbss 0x8a8 0 0x6 (6) _0xf67efda85d51b770 0x8ae 0 0x2 (2) .nbss 0x8b0 0 0x2 (2) .ndata 0x8b2 0 0x4 (4) _0xf6824b805d51b774 0x8b6 0 0x2 (2) .ndata 0x8b8 0 0x2 (2) _0xf6783da85d51b775 0x8ba 0 0x2 (2) .nbss 0x8bc 0 0x4 (4) .ndata 0x8c0 0 0x2 (2) .bss 0x8c2 0 0x452e (17710) .data 0x4df0 0 0x9a (154) _0xf68e39b45d51b776 0x4e8a 0 0x3a (58) .data 0x4ec4 0 0x26 (38) _0x558a833c59934428 0x4eea 0 0x1c (28) .bss 0x4f06 0 0x14 (20) .bss 0x4f1a 0 0xac (172) .bss 0x4fc6 0 0x28 (40) .bss 0x4fee 0 0x10 (16) .data 0x4ffe 0 0x2 (2) _0xf68278fc5d51b776 0x5000 0 0x10 (16) .bss 0x5010 0 0x1da (474) .data 0x51ea 0 0x24 (36) .bss 0x520e 0 0x40 (64) .bss 0x524e 0 0x36 (54) .bss 0x5284 0 0x4 (4) .heap 0x5288 0 0x800 (2048)

Total data memory used (bytes): 0x5288 (21128) 21%

Dynamic Memory Usage

region address maximum length (dec)

------ -------

--------------------- heap 0x5288 0x800 (2048) stack 0x5a88 0x2578 (9592)

Maximum dynamic memory (bytes): 0x2d78 (11640)

Reply to
Atlantis

Zacznij od kreślenia od jakiego adresu do jakiego masz heap i od jakiego do jakiego stos. To powinno być widoczne na etapie kompilacji/linkowania albo w definicjach albo w skrypcie linkera. Częsty błąd to podanie innych definicji niż skryptu.

W ogóle nie zauważyłem jakiego kompilatora używasz.

Można by podglądnąć co się po takim resecie stało ze stosem, czy aby na pewno pracuje we właściwym obszarze.

PIC24 ma ponoć hardware trap dla sytucji gdy stos wyjedzie poza zakres. Nie wystrzelił przypadkiem?

formatting link

8.2.1.1STACK ERROR TRAP

Niestety o PICach 24 niewiele wiem, ale problemy są zazwyczaj mocno generyczne i relatywnie podobne z innymi cpu.

Wpomniałeś że pCurrentEndpoint = usbDeviceInfo.pEndpoint0; wywala trap. Co to jest pEndpoint0 i jeśli jest szersze niż 8 bit to czy nie leży przypadkiem na nieparzystym adresie? A może w ogóle ta struktura leży na nieistniejącym adresie?

Napisz program który robi kilka malloc co do których masz pewność że się nie zmieszczą i wypełnij jakąś wartością tą pamięć jeśli zaalokuje. Nie zrobią przypadkiem resetu zamiast zwrócić 0?

Reply to
heby

Źle skonfigurowane bufory są wykrywane runtime i wtedy kod robi while(0); jeśli masz aktywnego wdg będą resety w kółko.

Reply to
Marek

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.