From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9004 invoked by alias); 25 Jan 2012 19:30:02 -0000 Received: (qmail 8912 invoked by uid 22791); 25 Jan 2012 19:30:01 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtpo21.poczta.onet.pl (HELO smtpo21.poczta.onet.pl) (213.180.142.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Jan 2012 19:29:46 +0000 Received: from pmq3.m5r2.onet (pmq3.m5r2.onet [10.174.32.69]) by smtp.poczta.onet.pl (Onet) with ESMTP id D199F20076806; Wed, 25 Jan 2012 20:29:44 +0100 (CET) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [62.141.196.155] by pmq3.m5r2.onet via HTTP id 201201252029385474010001; Wed, 25 Jan 2012 20:29:44 +0100 From: qber_ To: =?utf-8?q?Bernard_Fouch=C3=A9?= , " " Date: Wed, 25 Jan 2012 19:30:00 -0000 Message-Id: <1963487-20aaafa5957a2aede2efdc9fc7ac059c@pmq3.m5r2.onet> Subject: RE: Re: ST STM32F2X Port X-Onet-PMQ: ;62.141.196.155;PL;2 X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2012-01/txt/msg00042.txt.bz2 Hello Bernard The ISR occures correctly (in debug mode you can get into ISR). Everything = is ok but after some time problem occures. When you stop transmission on UA= RT everything goes back to normal. I think the problem can be in that ISR i= ncreses dsr_count quickly the DSR occures like you described in the bug. I made the masking and unmasking procedure (masking in ISR and unmasking in= DSR) but it didn't help in all :( W dniu 2012-01-25 14:52:11 u=C5=BCytkownik Bernard Fouch=C3=A9 napisa=C5=82: > Hello Qber, >=20 > what you describe looks like the ISR isn't masking its interrupt: it=20 > should be masked to avoid multiple ISR before the DSR runs. At the end=20 > of its processing, the DSR should unmask the interrupt. And then you=20 > fall in the case I describe with the pending interrupt problem... >=20 > Bernard >=20 >=20 > Le 25/01/2012 12:59, qber_ a =C3=A9crit : > > Hello Bernard > > > > I have very interesting think on my stm32F103 based board. When a heavy= load occures on serial driver the DSR procedure was missing after some tim= e. The interesting thing is that ISR was launched correctly. I investigated= this and the dsr_count number was increasing and after some time this numb= er was far abowe that interrupt calls (because of heavy load it couldn't re= ach zero again). The solution for me was to handle the queue in the ISR. I = will check your solution on STM32F103 maybe it can help for the heavy load = problem. > > > > Best Regards > > Qber > > > > W dniu 2012-01-25 12:25:02 u=C5=BCytkownik Bernard Fouch=C3=A9 napisa=C5=82: > >> Le 25/01/2012 12:09, qber_ a =C3=A9crit : > >>> Hello again > >>> > >>> According to previuos post (and no answer) I assume that there is no = port for STM32F2x platform. I wrote new hal for this platform and now I'm p= erfoming first tests. > >>> For now I've got hal, usart and soon spi driver. If somebody is inter= ested in this port please let me know. > >> Hello Qber, > >> > >> I do not have a direct interest in the STM32 port, however I met an > >> issue related to the Cortex-M3 NVIC with the LPC17XX port (described > >> here : http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001456 , lat= est > >> comment should be clear enough to show the problem) and I'm curious to > >> know if there is a similar issue on the STM32FX port you are working o= n. > >> If so, it would confirm the issue at the Cortex M HAL layer in eCos. > >> > >> Thanks, > >> > >> Bernard > >> > > > > > > >=20