<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>ISR FIFO Overflow</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/30727/isr-fifo-overflow</link><description> 
Hi 

 
I am using a STM32F103ZG and Keil uVision + RTX. I have a
multi-threaded application using interrupts and DMA. The problem I
have is an intermittent ISR FIFO overflow and, upon inspection, some
odd interrupts / SVC / PendSV / SysTick behaviour</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: ISR FIFO Overflow</title><link>https://community.arm.com/thread/106160?ContentTypeID=1</link><pubDate>Mon, 09 Jul 2012 14:02:40 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:64c260b7-ed3d-4e76-ba3e-b9071f00b0fa</guid><dc:creator>Andy Atkinson</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hi All,&lt;/p&gt;

&lt;p&gt;
Further debug of the problem suggests that we are in the SVC
handler when an interrupt occurs (UART) and preempts the handler.
Once the interrupt handling is complete and SVC handler also
complete, we see no more PendSV activity.&lt;/p&gt;

&lt;p&gt;
We have been using RTX 4.12 for some time, but as a result of this
issue, we have looked at the change set between 4.12 and latest
(4.53). It looks like a significant bug was fixed between these two
releases to address an issue with task / scheduler locking and
interrupt preemption.&lt;/p&gt;

&lt;p&gt;
We have migrated this fix across and the application is stable now
and the problem cannot be reproduced.&lt;/p&gt;

&lt;p&gt;
A support case is open with ARM so this thread can be closed
(unless anyone has pertinent info to share of course).&lt;/p&gt;

&lt;p&gt;
Regards&lt;/p&gt;

&lt;p&gt;
Andy&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: ISR FIFO Overflow</title><link>https://community.arm.com/thread/91616?ContentTypeID=1</link><pubDate>Mon, 09 Jul 2012 07:36:50 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:29847f77-45dd-4607-8009-3789419fe6ac</guid><dc:creator>F F</dc:creator><description>&lt;p&gt;&lt;p&gt;
Actually, this is a really big hit to the processor design as, at
least with the F2xx family, there are no peripheral FIFOs. By using
DMA you can bypass the need to service each peripheral interrupt on a
data-type basis. IF DMA is defective, then you are forced to use this
method or jump through many hoops to ensure that no more than 2 DMAs
are in use at a time. Not a pretty solution. Thus this is probably
the reason why ST is mum on providing a workaround/chip revision
other than problem acknowledgement. As the F1xx, F2xx and F4xx are
wihin the same &amp;#39;family line&amp;#39; of processors, they probably ALL have
this issue would be a reasonable assumption to make.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: ISR FIFO Overflow</title><link>https://community.arm.com/thread/60901?ContentTypeID=1</link><pubDate>Mon, 09 Jul 2012 05:21:41 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ad856bc4-1879-4ed2-a038-36742657af10</guid><dc:creator>F F</dc:creator><description>&lt;p&gt;&lt;p&gt;
Sounds like the behavior described here:&lt;/p&gt;

&lt;p&gt;

&lt;a href="http://blog.frankvh.com/2012/01/13/stm32f2xx-stm32f4xx-dma-maximum-transactions/"&gt;blog.frankvh.com/.../&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
Best to contact the Mfg directly and confirm.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>