No subject

orites are set in that code. I will check that at home.=20


Hope that the priorities are the caus as otherwise we still have another=
 bug in that stack.
On the other hand there also culd be a problem with the EIR application co=
de that normally should try to reconnect and if that fail it should try an=
other station.
Unfortunately the Shoutcast lists are not very long living and your prefer=
red station list can get out of date.


I will rework that code at the moment the STM3210C-EVAL kit runs EIR and=
 it is time to implement IR-Receiver, rotary encoder, and several displays=
. May be RF Remote control is an option too.


Best regards
Ulrich


-----Original Message-----
From: Marti Raudsepp <marti at voicecom.ee>
To: Ethernut User Chat (English) <en-nut-discussion at egnite.de>
Sent: Thu, Oct 21, 2010 12:32 pm
Subject: Re: [En-Nut-Discussion] tcpsm crash on socket timeouts


On Thu, Oct 21, 2010 at 12:35,  <uprinz2 at netscape.net> wrote:
> there are coming in broken packages at that moment that might cause this=
 race=20
condition you discovered.

Well that's easy to determine: is your socket thread priority higher than=
 tcpsm?

> What is a bit astonishing is the fact, that I expect the ARM7 to enter=
=20
bus-fault or hard-fault if adressing unsupported memory addresses.

In my case, most of the time it fails with undefined instruction
(__undef), sometimes data abort (__data_abort). It seems that there is
some randomness in the address it's trying to jump to. In some
unfortunate situations it jumps to real code. Maybe that's specific to
our application.

> But if I remember my last development on ARM7 this CPU is very tolerant.

Yeah, the Atmel AT91SAM7 series is pretty frustrating to debug. I hope
that other ARM vendors are better at raising bus errors in response to
erroneus memory accesses.

Regards,
Marti Raudsepp
Voicecom O=C3=9C
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

=20