Thread stack

Hello all,

it seems I have a problem with stack size in multi-threaded application.
The stack size allocation before crush ("Bad next thread") is:

Thread name: Idle Thread,                Total stack: 4608,      Stack
used: 1140,       Remaining in stack: 3468

Thread name: main,                       Total stack: 12288, Stack used:
12112,  Remaining in stack: 176

Thread name: SharedMemoryReceiver,       Total stack: 8192,  Stack used:
3564,   Remaining in stack: 4628

Thread name: task1,                      Total stack: 8192,  Stack used:
3328,   Remaining in stack: 4864

Thread name: task2,                      Total stack: 8192,      Stack
used: 3888,       Remaining in stack: 4304

Thread name: task3,                      Total stack: 8192,      Stack
used: 368,        Remaining in stack: 7824

Thread name: task4,                      Total stack: 8192,      Stack
used: 4328,
Remaining in stack: 3864

Thread name: task5,                      Total stack: 8192,      Stack
used: 4960,       Remaining in stack: 3232

Re: Thread stack

Hi Mykhailo,

Have a look at the following ECOS configuration options under the ISO C 
Library package:
CYGSEM_LIBC_MAIN_STACK_FROM_SYSTEM - if not selected the app has to 
assign the stack.
CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE - you would have to recompile the 
ecos configuration project each time you change this.

Either way you'll have to recompile the ecos config project at least 
once, but with the former, you would then only need to recompile the app 
each time to change the main thread's stack size.

Hope that helps,

Andrew Parlane

On 09/11/2011 07:34, Mykhailo Lytvyn wrote:
> Hello all,
>
> it seems I have a problem with stack size in multi-threaded application.
> The stack size allocation before crush ("Bad next thread") is:
>
> Thread name: Idle Thread,                Total stack: 4608,      Stack
> used: 1140,       Remaining in stack: 3468
>
> Thread name: main,                       Total stack: 12288, Stack used:
> 12112,  Remaining in stack: 176
>
> Thread name: SharedMemoryReceiver,       Total stack: 8192,  Stack used:

Halting Ecos

Hi,

I'm using TSIM to simulate an application that was compiled and linked
with eCos configuration for LEON3. I want to measure performance of the
application but once the application finishes, it runs eCos's idle loop.
Is there any way to stop/halt eCos when the application returns?

Thank you,
Nga

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: Halting Ecos

ngad <at> uci.edu wrote:
> Hi,
> 
> I'm using TSIM to simulate an application that was compiled and linked
> with eCos configuration for LEON3. I want to measure performance of the
> application but once the application finishes, it runs eCos's idle loop.
> Is there any way to stop/halt eCos when the application returns?

You could add an 'asm("ta 0")' statement at the end of your
application. This should cause the processor to go into
error mode and halt.

Jiri.

> 
> Thank you,
> Nga
> 
> 

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Kinetis TWR-K60N512 MRAM debug

Hi list,
I make simple patch for using MRAM on Kinetis.
I configure all clocks in my GDB script from FlexBus example (from Freescale)
It works for me (I don't use Redboot), but maybe there are something else to do.
Best regards.
 		 	   		  

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: Kinetis TWR-K60N512 MRAM debug

On 14.11.2011 13:04, jjp jjp wrote:
> Hi list,
> I make simple patch for using MRAM on Kinetis.
> I configure all clocks in my GDB script from FlexBus example (from Freescale)
> It works for me (I don't use Redboot), but maybe there are something else to do.
> Best regards.

Hi jjp.

Thanks for tweaking Kinetis port. However I have some remarks:

It's kind of too intrusive. You don't have to deal with architecture. It
is a bad idea since you will have to patch arch every time you checkout.
Or at least you may encounter conflicts.

Everything can be resolved in platform, I advise you to create new
platform twr_k60n512_mram (clone twr_k60n512 and rename) and try to
resolve everything there. No need to change a bit anywhere else except
add entries to ecos.db.

Look here for hints for your new platform CDL:
http://ecos.sourceware.org/ml/ecos-devel/2011-07/msg00002.html

Ilija

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: Kinetis TWR-K60N512 MRAM debug

----------------------------------------
> Date: Mon, 14 Nov 2011 23:58:24 +0100
> From: ilijak <at> siva.com.mk
> To: jackoaway <at> hotmail.com
> CC: ecos-discuss <at> ecos.sourceware.org
> Subject: Re: [ECOS] Kinetis TWR-K60N512 MRAM debug
>
> On 14.11.2011 13:04, jjp jjp wrote:
> > Hi list,
> > I make simple patch for using MRAM on Kinetis.
> > I configure all clocks in my GDB script from FlexBus example (from Freescale)
> > It works for me (I don't use Redboot), but maybe there are something else to do.
> > Best regards.
>
> Hi jjp.
>
> Thanks for tweaking Kinetis port. However I have some remarks:
>
> It's kind of too intrusive. You don't have to deal with architecture. It
> is a bad idea since you will have to patch arch every time you checkout.
> Or at least you may encounter conflicts.
>
> Everything can be resolved in platform, I advise you to create new
> platform twr_k60n512_mram (clone twr_k60n512 and rename) and try to
> resolve everything there. No need to change a bit anywhere else except
> add entries to ecos.db.
>
> Look here for hints for your new platform CDL:
> http://ecos.sourceware.org/ml/ecos-devel/2011-07/msg00002.html

Re: Halting Ecos

Thanks Jiri. It works!!

Nga

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Fwd: [ECOS] PANIC: soaccept: !NOFDREF

Hello,

I didn't receive any answer and I didn't find any fix. So I try a second time.

Thank you for your help,
JEANNETON Arnaud

----- Mail transféré -----
De: "arnaud jeanneton" <arnaud.jeanneton <at> free.fr>
À: ecos-discuss <at> ecos.sourceware.org
Envoyé: Samedi 29 Octobre 2011 11:58:15
Objet: [ECOS] PANIC: soaccept: !NOFDREF

Hello,

I have the same problem as described in the following post, found at http://sourceware.org/ml/ecos-discuss/2003-09/msg00488.html.
Does anybody know how to fix it ?

Thank you for your help,
JEANNETON Arnaud

Re: PANIC: soaccept: !NOFDREF

From: Gary Thomas <gary at mlbassoc dot com>
To: Grant Edwards <grante at visi dot com>
Cc: eCos Discussion <ecos-discuss at sources dot redhat dot com>
Date: 27 Sep 2003 17:28:39 -0600
Subject: Re: [ECOS] PANIC: soaccept: !NOFDREF
Organization: MLB Associates
References: <20030927170930.A26900 <at> visi.com>

Re: eth_recv out of MBUFs

Hi Stanislav,

did you manage do create a patch? I have some MBUF problems too, running out of
MBUFs or noticed big latencies which can be reduced some times with debug output
inside the network driver. The whole MBUF stuff seem to be quite critical and I
need a stable network stack.

Bye...

On 11.08.2011 18:51, Stanislav Meduna wrote:
> Hi all,
> 
> thank you all for the hints. I think I now know the cause
> of the problem - it is most probably caused by the
> nature of how our application communicates that does
> not go well with the mbuf allocation.
> 
> Our application sends many (about 50/sec in my test
> setup, in praxis it varies wildly) short (about 60 byte)
> TCP packets and as the latency is more important than
> the throughput it does it on a socket with the TCP_NODELAY
> option.
> 
> It looks the stack does not coalesce the data into clusters
> in this setup and allocates a separate mbuf for each
> such packet. Of course if the cable is plugged out or something
> this quickly leads to a mbuf pressure that is twice more than
> naively expected because of the overhead (128 byte mbuf used
> for 60 byte of data). Considering that the amount of data needed
> in the mbufs can be (I guess) at least number of connections times