On 10/08/2019 17:38, Marek wrote:
> 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

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.

do góry

On 10.08.2019 17:40, Marek wrote:

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

do góry

On Sat, 10 Aug 2019 18:13:05 +0200, heby <h...@p...onet.pl> wrote:
> 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

do góry

heby <h...@p...onet.pl> napisał(a):
> 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/

do góry

On 11/08/2019 10:46, Grzegorz Niemirowski wrote:
>> 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).

do góry

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

do góry

On 11.08.2019 08:56, Marek wrote:

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

do góry

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)

do góry

On 12/08/2019 20:39, Atlantis wrote:
> 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/3970
7a.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?

do góry

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

do góry