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é<[email protected]> 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é<[email protected]> 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
