This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Re: ST STM32F2X Port


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. 
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Åytkownik Bernard Fouchà <bernard.fouche@kuantic.com> napisaÅ:
> Maybe you're not masking the correct interrupt because once the 
> interrupt is masked only the related DSR will run so dsr_count should be 
> 1. The bug I describe is repeated ISR-DSR sequences, however when the 
> DSR runs, the count parameter is always 1. BTW there is a STM32 port in 
> the CVS tree..
> 
> Le 25/01/2012 20:29, qber_ a Ãcrit :
> > 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 UART everything goes back to normal. I think the problem can be in that ISR increses 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Åytkownik Bernard FouchÃ<bernard.fouche@kuantic.com>  napisaÅ:
> >> 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 Ãcrit :
> >>> 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 time. The interesting thing is that ISR was launched correctly. I investigated this and the dsr_count number was increasing and after some time this number 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 load problem.
> >>>
> >>> Best Regards
> >>> Qber
> >>>
> >>> W dniu 2012-01-25 12:25:02 uÅytkownik Bernard FouchÃ<bernard.fouche@kuantic.com>   napisaÅ:
> >>>> Le 25/01/2012 12:09, qber_ a Ãcrit :
> >>>>> 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 perfoming first tests.
> >>>>> For now I've got hal, usart and soon spi driver. If somebody is interested 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=1001456 , latest
> >>>> 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
> >>>>
> >>>
> >>>
> >
> >
> >
> 




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]