[En-Nut-Discussion] tcpsm crash on socket timeouts

uprinz2 at netscape.net uprinz2 at netscape.net
Thu Oct 21 15:02:10 CEST 2010


Hi!


I don't know about other ARMs but I can tell you that CortxM3 is very strict with this and throws Hard-Faults at you that you're getting dizzy. 
But the time comes when you really like this strict behaviour as you are sure that the code is really working now and you can be relatively sure that there is no hidden bug, compared to other architectures.

I am waiting for the STM32F-2 series chips as all of them will inherit a memory management unit. Will get interesting to implement this on Nut/OS :)


In the meantime I started some investigations on the ethernet stack in total as I now start implementing the EMAC of the STM32F series. Would be kind if you can continue your investigations and probably present some solutions. I put that all together and submit it to the trunk and my branch. 


>From here I have no access to the EIR project so I cannot tell how the priorites are set in that code. I will check that at home. 


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 code that normally should try to reconnect and if that fail it should try another station.
Unfortunately the Shoutcast lists are not very long living and your preferred 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 
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 
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Ü
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

 



More information about the En-Nut-Discussion mailing list