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?

do góry

On 07/08/2019 13:04, Atlantis wrote:
> 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.

do góry

On Wed, 7 Aug 2019 14:04:05 +0200, Atlantis <m...@w...pl>
wrote:
> 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

do góry

On 07.08.2019 17:45, Marek wrote:

> 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?

do góry

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.

do góry

On Fri, 9 Aug 2019 07:06:47 +0200, Atlantis <m...@w...pl>
wrote:
> 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

do góry

On 10.08.2019 10:31, Marek wrote:

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

do góry

On 10/08/2019 13:15, Atlantis wrote:
>> 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.

do góry

On Sat, 10 Aug 2019 15:06:11 +0200, heby <h...@p...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

--
Marek

do góry

On Sat, 10 Aug 2019 13:15:48 +0200, Atlantis <m...@w...pl>
wrote:
> 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

do góry