Ilija Kocho | 2 Jun 20:59 2012
Picon

Re: ecos_and_redboot for freescale's kwikstik

Hi tangwei

Generally you need only to connect an RS232 terminal with following
settings: 38400 8N1. You can use any terminal emulator such as minicom,
Tera Term, etc.

Of course you need some hardware to adapt Kinetis signals to RS232. What
is your hardware configuration?

I invite you in future to send your questions regarding eCos to eCos
discuss mailing list. You have better chances for answer from Kwikstik
users, and community will benefit from your questions.
Here you can subscribe to eCos discuss mailing list:
http://ecos.sourceware.org/intouch.html

Ilija

On 31.05.2012 10:59, xfce <at> sina.com wrote:
> Dear sir,
> I am a freshman to ecos, I have a kwikstik board,and want to study the
> ecos and redboot
> when i download the redboot into kwikstik how can i know it works,
> form the UART(PTE8/UART_TX,PTE9/UART_RX)?
> waiting for your reply
> thanks
> -----------------
> tangwei

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
(Continue reading)

Elad Yosef | 12 Jun 22:40 2012
Picon

pbuf_alloc failures with LwIP

Hi all,
I'm using LwIP stack on my target and experiencing crashes under stress.

function eth_drv_recv) from ../io/eth/v3_0/ser/lwip/eth_drv.c
calls pbuf_alloc() and this allocation fails.

Is this result of some bad configuration?

Thanks
Elad

--

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

Michael O'Dowd | 13 Jun 17:47 2012

Re: pbuf_alloc failures with LwIP

Hi Elad,

I ran into a similar problem recently. I'm using a recent CVS checkout 
rather than 3.0. Also, I'm probably not using the same ethernet HW, so I 
don't know how well my reply corresponds to your case.

The eth_drv.c file is the glue between lwIP and the underlying ethernet 
driver, so the issue that you are encountering may be specific to the 
driver. In my case, when under stress, eth_drv.c generates the error 
message: "cannot allocate pbuf to receive packet". Soon after that, the 
ethernet driver stops receiving traffic permanently, but does not crash. 
In your case, if I understand correctly, your system crashes.

The issue is that when eth_drv_recv() fails to allocate a pbuf, it 
returns without calling the ethernet driver recv() function: 
(sc->funs->recv)(). In my case, the driver requires that it's recv() 
function be called, in order to complete the processing of the packet 
reception and to free up the receive buffer(s). Failing to call it, 
apparently causes the receive path to cease functioning (I'm still 
investigating the details). In your case, I gather that it crashes the 
system.

Note: I'm running on an NXP 1788 (Cortex-M3), using the 
"devs/arm/lpc2xxx/current/src/if_lpc2xxx.c" ethernet driver.

There are two aspects to this problem:

1) In my opinion, there is a bug in eth_drv_recv(). If there are no 
pbufs available, then it should at least cause the received packet to be 
discarded. Otherwise, the system may fail whenever there is a minor 
(Continue reading)

Elad Yosef | 14 Jun 06:43 2012
Picon

Re: pbuf_alloc failures with LwIP

Hi Michael,
Thanks for the detailed reply.

I think I have exactly the same problem that you have - the networking
stops working.

I got the LwIP stats after the networking stopped working, see

LINK
        xmit: 0
        rexmit: 0
        recv: 0
        fw: 0
        drop: 0
        chkerr: 0
        lenerr: 0
        memerr: 0
        rterr: 0
        proterr: 0
        opterr: 0
        err: 0
        cachehit: 0

IP_FRAG
        xmit: 0
        rexmit: 0
        recv: 0
        fw: 0
        drop: 0
        chkerr: 0
(Continue reading)

Michael O'Dowd | 14 Jun 16:38 2012

Re: pbuf_alloc failures with LwIP

Hi Elad,

Hmm, I've had a quick look at the pbuf management in eCos 3.0. It's 
quite different from the CVS version, so I'm not that familiar with it.

Nonetheless, I'm surprised by the PBUF statistics:

   PBUF - "each pbuf is 1024 bytes"
           avail: 30
           used: 1
           max: 11
           err: 2
           alloc_locked: 0
           refresh_locked: 0

There's something wrong here. Considering that "alloc_locked = 0", the 
only way for "err" to be incremented is if you run out of pbufs. 
However, the sign that you have run out of pbufs is that "max" equals 
"avail". Yet, in your case, max = 11, while avail = 30. So you didn't 
run out of pbufs, you only used 11 out of 30.

Digging a bit more, it appears that "err" in increased when 
pbuf_pool_alloc() returns NULL. This happens when the linked-list of 
available pbufs is empty.

So, how come the linked-list of available pbufs is empty when max = 11? 
In my opinion, the linked-list of available pbufs is corrupt or truncated.

Are you sure that you're respecting the thread-safe requirements of 
lwIP? Are you using multiple threads? If so, make sure that the 
(Continue reading)

Elad Yosef | 17 Jun 08:28 2012
Picon

Re: pbuf_alloc failures with LwIP

Hi,
I'm using multiple threads in my application.
The SYS_ARCH_PROTECT is not enabled at all.
How do I  enable it?
Is it enabled in the current CVS version?
Does the current LwIP in CVS is compatible with ecos-3.0? In yes I
would consider upgrading LwIP package only.

Thanks
Elad

On Thu, Jun 14, 2012 at 5:38 PM, Michael O'Dowd
<michael.odowd <at> kuantic.com> wrote:
> Hi Elad,
>
> Hmm, I've had a quick look at the pbuf management in eCos 3.0. It's quite
> different from the CVS version, so I'm not that familiar with it.
>
> Nonetheless, I'm surprised by the PBUF statistics:
>
>  PBUF - "each pbuf is 1024 bytes"
>          avail: 30
>          used: 1
>          max: 11
>          err: 2
>          alloc_locked: 0
>          refresh_locked: 0
>
> There's something wrong here. Considering that "alloc_locked = 0", the only
> way for "err" to be incremented is if you run out of pbufs. However, the
(Continue reading)

John Dallaway | 17 Jun 11:12 2012
Picon

Re: pbuf_alloc failures with LwIP

Hi Elad

On 17/06/12 07:28, Elad Yosef wrote:

> I'm using multiple threads in my application.
> The SYS_ARCH_PROTECT is not enabled at all.
> How do I  enable it?
> Is it enabled in the current CVS version?
> Does the current LwIP in CVS is compatible with ecos-3.0? In yes I
> would consider upgrading LwIP package only.

You should be able to use lwIP 1.3.2 from eCos CVS with your eCos 3.0
release repository just by copying packages/io/eth/current/ and
packages/net/lwip_tcpip/current/ into your eCos 3.0 repository. Any
_new_ eCos configurations will then use the "current" versions of these
packages rather than the "v3_0" versions. Any _previous_ eCos
configurations will continue to use the "v3_0" packages.

I hope this helps...

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

--

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

Elad Yosef | 17 Jun 15:36 2012
Picon

Re: pbuf_alloc failures with LwIP

Hi all,
The good news:
I have managed to build new image with the new packages specified.
The bad news:
I can't see the TCP + ETH threads in the threads list and fails to ping.

Can anyone guide me how to bring-up the LwIP properly?

Elad

On Sun, Jun 17, 2012 at 12:12 PM, John Dallaway <john <at> dallaway.org.uk> wrote:
> Hi Elad
>
> On 17/06/12 07:28, Elad Yosef wrote:
>
>> I'm using multiple threads in my application.
>> The SYS_ARCH_PROTECT is not enabled at all.
>> How do I  enable it?
>> Is it enabled in the current CVS version?
>> Does the current LwIP in CVS is compatible with ecos-3.0? In yes I
>> would consider upgrading LwIP package only
>
> You should be able to use lwIP 1.3.2 from eCos CVS with your eCos 3.0
> release repository just by copying packages/io/eth/current/ and
> packages/net/lwip_tcpip/current/ into your eCos 3.0 repository. Any
> _new_ eCos configurations will then use the "current" versions of these
> packages rather than the "v3_0" versions. Any _previous_ eCos
> configurations will continue to use the "v3_0" packages.
>
> I hope this helps...
(Continue reading)

Elad Yosef | 17 Jun 16:25 2012
Picon

Re: pbuf_alloc failures with LwIP

Hi,
How can I enable the thread-safety in ecos-3.0 ?
I think it would be easier for me

Thanks

Elad

On Sun, Jun 17, 2012 at 12:12 PM, John Dallaway <john <at> dallaway.org.uk> wrote:
> Hi Elad
>
> On 17/06/12 07:28, Elad Yosef wrote:
>
>> I'm using multiple threads in my application.
>> The SYS_ARCH_PROTECT is not enabled at all.
>> How do I  enable it?
>> Is it enabled in the current CVS version?
>> Does the current LwIP in CVS is compatible with ecos-3.0? In yes I
>> would consider upgrading LwIP package only.
>
> You should be able to use lwIP 1.3.2 from eCos CVS with your eCos 3.0
> release repository just by copying packages/io/eth/current/ and
> packages/net/lwip_tcpip/current/ into your eCos 3.0 repository. Any
> _new_ eCos configurations will then use the "current" versions of these
> packages rather than the "v3_0" versions. Any _previous_ eCos
> configurations will continue to use the "v3_0" packages.
>
> I hope this helps...
>
> John Dallaway
(Continue reading)

Jesper K. Pedersen | 17 Jun 16:43 2012
Picon

AT91SAM7S256 problem with test/example twothreads

I am at my wits end getting the twothreads example working on my Olimex
P256 board (AT91SAM7S256 based).

Calling the cyg_mutex_init does not return. Also I notice that the call
to the printf line before the call to cyg_mutex_init prints extremely
slow on my terminal.

I have set the default console up to tty0 going to ser0. This part
works fine with my other software running on the board (normal expected
transmission speed).

Are there any "gotcha'" involving threading on the AT91 series
microcontrollers?

Best regards
JesperKP

Extra info (note I have added a couple of debugging lines):

void cyg_user_start(void)
{
  printf("Entering twothreads' cyg_user_start() function\n\r");

  cyg_mutex_init(&cliblock);

  printf("cyg_mutex_init() done\n\r"); // <--- Never gets sent 

  cyg_thread_create(4, simple_program, (cyg_addrword_t) 0,
		    "Thread A", (void *) stack[0], 4096,
		    &simple_threadA, &thread_s[0]);
(Continue reading)


Gmane