RTV forum PL | NewsGroups PL

PIC24fj256da210 - dziwne zachowanie GPIO

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - PIC24fj256da210 - dziwne zachowanie GPIO

Goto page Previous  1, 2

heby
Guest

Sun Aug 11, 2019 10:20 am   



On 11/08/2019 00:44, Atlantis 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.

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

Atlantis
Guest

Mon Aug 12, 2019 6:39 pm   



On 11.08.2019 08:56, Marek wrote:

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

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

Atlantis
Guest

Mon Aug 12, 2019 7:01 pm   



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 (Cool
..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 (5Cool
..data 0x4ec4 0 0x26 (3Cool
_0x558a833c59934428 0x4eea 0 0x1c (2Cool
..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)

heby
Guest

Mon Aug 12, 2019 7:04 pm   



On 12/08/2019 20:39, Atlantis wrote:
Quote:
Jest więc całkiem możliwe, że problem ze zbyt dużą stertą też był
objawem jakiegoś innego błędu. Jak powinienem go szukać?

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?

http://ww1.microchip.com/downloads/en/devicedoc/39707a.pdf

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?

Marek
Guest

Tue Aug 13, 2019 1:33 pm   



On Mon, 12 Aug 2019 20:39:28 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:
Quote:
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ę

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

--
Marek

Atlantis
Guest

Tue Aug 13, 2019 6:34 pm   



On 13.08.2019 15:33, Marek wrote:

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

Watchdog wyłączony. Na tym etapie tylko zaciemniałby sytuację.
Wygląda na to, że chyba znalazłem przyczynę. Wczytałem się w
dokumentację i okazuje się, że ten konkretny model PIC24 ma sporą
pamięć, ale nie cała jest dostępne bezpośrednio. W standardowy sposób
dostępne jest tylko 30kB, pozostałe 66kB to pamięć rozszerzona (EDS).
Zmylił mnie fakt, że MPLABX w użytych zasobach uwzględnia całość. Z
punktu widzenia programu pamięci było mniej niż oczekiwałem i stos w
pewnym momencie zaczął pisać po stercie.

Przejrzałem kod i odzyskałem trochę zmiennych globalnych tam, gdzie to
tylko było możliwe. Wystarczyło, żeby ruszyły wszystkie rzeczy, które do
tej pory nie chciały działać.

Teraz tylko muszę opanować obsługę tej rozszerzonej pamięci z poziomu C.
Gotowych bibliotek nie chciałbym przerabiać, ale teraz zostało mi już
tylko (poza dopracowaniem paru szczegółów) napisanie warstwy własnej
aplikacji, która równie dobrze może korzystać z tej części RAM-u.

Marek
Guest

Wed Aug 14, 2019 7:15 am   



On Tue, 13 Aug 2019 20:34:36 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:
Quote:
Teraz tylko muszę opanować obsługę tej rozszerzonej pamięci z
poziomu C.

Takie pytanie zasadnicze - po co Ci ten wynalazek? Smile Masz opanowany
pic32, o wiele więcej zasobów, z kontekstu wynika że probojesz
uruchamic podobny soft (stos tcpip) który z powodzeniem uruchamiales
na pic32 Po co się męczyć z niszowym układem? Jak mawiał klasyk
edukacja nie usprawiedliwia straconego czasu Smile.

--
Marek

Atlantis
Guest

Wed Aug 14, 2019 9:20 am   



On 14.08.2019 09:15, Marek wrote:

Quote:
Takie pytanie zasadnicze - po co Ci ten wynalazek? Smile Masz opanowany
pic32, o wiele więcej zasobów, z kontekstu wynika że probojesz uruchamic
podobny soft (stos tcpip) który z powodzeniem uruchamiales na pic32  Po
co się męczyć z niszowym układem? Jak mawiał klasyk edukacja nie
usprawiedliwia straconego czasu Smile.

1) Praktyczny cel jest taki, że PIC24 traktuję jako furtkę do dsPIC33,
którym też chciałbym się trochę bliżej przyjrzeć. Sporo krótkofalarskich
projektów opartych na DSP powstało właśnie na procesorach z tej rodziny.
2) Okazuje się, że nie ma aż tak wielkich różnic pomiędzy PIC24 i PIC32.
Największą jest fakt, że pisząc kod najlepiej posługiwać się rejestrami
- biblioteka plib (przynajmniej ta "legacy") zdaje się być mniej
dopracowana i chyba nie jest do końca kompatybilna z nowszymi układami.
Jednak układ rejestrów jest bardzo podobny i można się w tym bez trudu
połapać. Chciałem jednak wykonać jakiś projekt na tym MCU aby przekonać
się, czy nie ma jakichś poważniejszych "pułapek" i jak się okazuje, na
jedną trafiłem. Teraz powinno już pójść z górki. Wink
3) To trochę realizacja hobby. Uruchamiałem już soft na różnych
"dziwnych" rodzinach CPU i MCU. W tym także takich, które zaliczają się
do kategorii "retro". Jednym z projektów, które w tej chwili leżą u mnie
na półce jest przeniesienie pewnej istniejącej konstrukcji (w pierwszej
wersji zrealizowanej na AVR, w drugiej na PIC32) na system
mikroprocesorowy oparty na 6502. Wink

Goto page Previous  1, 2

elektroda NewsGroups Forum Index - Elektronika Polska - PIC24fj256da210 - dziwne zachowanie GPIO

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map