<?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>STM32F4 GPIO-&amp;gt;BSRRH does not always work</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/34593/stm32f4-gpio--bsrrh-does-not-always-work</link><description> 
The issue that I am having is with two lines of code that uses
GPIO_-&amp;gt;BSRRH to control the output pins of an STM32F407. This
works very well for thousands to 100K+ consecutive cycles, then
misses once at an apparent random interval. This controls some</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: STM32F4 GPIO-&gt;BSRRH does not always work</title><link>https://community.arm.com/thread/109228?ContentTypeID=1</link><pubDate>Fri, 30 Jun 2017 06:49:13 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:aad3a6ab-d25e-4d1c-8982-e7429c651b7e</guid><dc:creator>Jon Koenig</dc:creator><description>&lt;p&gt;&lt;p&gt;
So the penultimate root cause was turning on in one process and
turning off in another. I should remember learning this lesson 100
years ago. Although this did all the right things, it occasionally
did not do them in the right order. Your comments about clocking the
outputs and the pipelining were helpful and got me on the right path.
In hindsight, it is all so simple.&lt;/p&gt;

&lt;p&gt;
The ultimate root case, as always, was trying to rush stuff out as
quickly as possible.&lt;/p&gt;

&lt;p&gt;
Once again, my thanks!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: STM32F4 GPIO-&gt;BSRRH does not always work</title><link>https://community.arm.com/thread/94109?ContentTypeID=1</link><pubDate>Thu, 29 Jun 2017 11:32:54 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6b7b7dcb-729a-4320-97b4-4070655c887f</guid><dc:creator>Jon Koenig</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks for your reply - especially about the pipelining! If I get
an occasional &amp;quot;turn-on&amp;quot; command delayed and delivered after the TIM2
had finished its &amp;quot;turn-off&amp;quot;, that would explain the symptoms.&lt;/p&gt;

&lt;p&gt;
I had previously determined that the TIM2 interrupt and the BSRRH
were working. ODR was always okay when I left the ISR, but was
mysteriously coming on again afterwards.&lt;/p&gt;

&lt;p&gt;
I&amp;#39;ve thrown some ugly brute force at it, and will see if I collect
any faults overnight.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: STM32F4 GPIO-&gt;BSRRH does not always work</title><link>https://community.arm.com/thread/86159?ContentTypeID=1</link><pubDate>Thu, 29 Jun 2017 10:07:19 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:730b1dd1-4702-4545-b250-25be5369fa77</guid><dc:creator>Westonsupermare Pier</dc:creator><description>&lt;p&gt;&lt;p&gt;
Your IRQ Handler should qualify the source before acting. The
Cortex-M3/M4 will reenter interrupts if the NVIC still signals a
source because the write buffers to the peripheral have not cleared
the source yet. Clearing the interrupt as the last thing you do is
thus ill advised.&lt;/p&gt;

&lt;p&gt;
Remember the core is pipelined, writes are deferred, and might be
on significantly slower buses.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>