ST STM32F2X Port

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

ST STM32F2X Port

qber_
Hello
I read on the ecoscentric page that there is a port for STM3210E-EVAL Platform HAL. I don't see this port on the CVS so my question is if this port will be available (maybe I'm doing something wrong?).
 Best Regards
 Qber
Reply | Threaded
Open this post in threaded view
|

RE: ST STM32F2X Port

qber_
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.

Best Regards
Qber

W dniu 2012-01-24 09:27:56 użytkownik qber_ <[hidden email]> napisał:
> Hello
> I read on the ecoscentric page that there is a port for STM3210E-EVAL Platform HAL. I don't see this port on the CVS so my question is if this port will be available (maybe I'm doing something wrong?).
>  Best Regards
>  Qber
>



Reply | Threaded
Open this post in threaded view
|

Re: ST STM32F2X Port

Bernard Fouché

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
Reply | Threaded
Open this post in threaded view
|

RE: Re: ST STM32F2X Port

qber_
In reply to this post by qber_
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é <[hidden email]> 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é<[hidden email]>  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
> >>
> >
> >
> >
>



Reply | Threaded
Open this post in threaded view
|

Re: ST STM32F2X Port

Bernard Fouché
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é<[hidden email]>  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é<[hidden email]>   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
>>>>
>>>
>>>
>
>
>
Reply | Threaded
Open this post in threaded view
|

RE: Re: ST STM32F2X Port

qber_
In reply to this post by qber_
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é <[hidden email]> 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é<[hidden email]>  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é<[hidden email]>   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
> >>>>
> >>>
> >>>
> >
> >
> >
>