From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16420 invoked by alias); 26 Jan 2012 09:19:18 -0000 Received: (qmail 16410 invoked by uid 22791); 26 Jan 2012 09:19:17 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,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; Thu, 26 Jan 2012 09:19:02 +0000 Received: from pmq2.m5r2.onet (pmq2.m5r2.onet [10.174.32.68]) by smtp.poczta.onet.pl (Onet) with ESMTP id 75A3E20075B21; Thu, 26 Jan 2012 10:16:05 +0100 (CET) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [217.6.141.85] by pmq2.m5r2.onet via HTTP id 201201261016026797010001; Thu, 26 Jan 2012 10:16:05 +0100 From: qber_ Cc: " " To: =?utf-8?q?Bernard_Fouch=C3=A9?= Date: Thu, 26 Jan 2012 09:19:00 -0000 Message-Id: <2002712-23732bbee0e224b050aa379cfe8d2347@pmq2.m5r2.onet> Subject: RE: Re: ST STM32F2X Port X-Onet-PMQ: ;217.6.141.85;DE;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/msg00045.txt.bz2 Hello This issue I found in the drivers published in the CVS so I don't thinkthis= is my software fault. It's only occured after heavy load.=20 STM32 is on CVS but only STM32F1x familly. The STM32F2x have different arch= (register map, GPIO, RCC, DMA itp.). Best Regards Qber W dniu 2012-01-26 09:05:54 u=C5=BCytkownik Bernard Fouch=C3=A9 napisa=C5=82: > Maybe you're not masking the correct interrupt because once the=20 > interrupt is masked only the related DSR will run so dsr_count should be= =20 > 1. The bug I describe is repeated ISR-DSR sequences, however when the=20 > DSR runs, the count parameter is always 1. BTW there is a STM32 port in=20 > the CVS tree.. >=20 > Le 25/01/2012 20:29, qber_ a =C3=A9crit : > > Hello Bernard > > The ISR occures correctly (in debug mode you can get into ISR). Everyth= ing is ok but after some time problem occures. When you stop transmission o= n UART everything goes back to normal. I think the problem can be in that I= SR increses dsr_count quickly the DSR occures like you described in the bug. > > I made the masking and unmasking procedure (masking in ISR and unmaskin= g 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, > >> > >> what you describe looks like the ISR isn't masking its interrupt: it > >> should be masked to avoid multiple ISR before the DSR runs. At the end > >> of its processing, the DSR should unmask the interrupt. And then you > >> fall in the case I describe with the pending interrupt problem... > >> > >> Bernard > >> > >> > >> Le 25/01/2012 12:59, qber_ a =C3=A9crit : > >>> Hello Bernard > >>> > >>> I have very interesting think on my stm32F103 based board. When a hea= vy load occures on serial driver the DSR procedure was missing after some t= ime. The interesting thing is that ISR was launched correctly. I investigat= ed this and the dsr_count number was increasing and after some time this nu= mber was far abowe that interrupt calls (because of heavy load it couldn't = reach 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 loa= d 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 n= o port for STM32F2x platform. I wrote new hal for this platform and now I'm= perfoming first tests. > >>>>> For now I've got hal, usart and soon spi driver. If somebody is int= erested 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 , l= atest > >>>> 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= on. > >>>> If so, it would confirm the issue at the Cortex M HAL layer in eCos. > >>>> > >>>> Thanks, > >>>> > >>>> Bernard > >>>> > >>> > >>> > > > > > > >=20