<?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>scary STM32F4 compiler issue?</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/35983/scary-stm32f4-compiler-issue</link><description> 
I am investigating what looks to be a memory corruption issue. I
am stepping through the assembler and I cannot explain what I see.
It&amp;#39;s as if the microcontroller is not correctly interpreting the
assembler code that was generated by the compiler. </description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: scary STM32F4 compiler issue?</title><link>https://community.arm.com/thread/129363?ContentTypeID=1</link><pubDate>Wed, 22 Feb 2017 02:03:47 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:0e9393ef-eb40-45ae-bfe5-4b8f5912c98f</guid><dc:creator>Richard E</dc:creator><description>&lt;p&gt;&lt;p&gt;
Yep those are exactly the markings that I see on this
STM3240G-EVAL board. I think we have concluded that its a STM32F407
Rev A, with the known pre-fetch issue.&lt;/p&gt;

&lt;p&gt;
Yesterday, it was my view that the code was not enabling the
prefetch buffer, since SystemClock_Config contains&lt;/p&gt;

&lt;pre&gt;
  /* STM32F405x/407x/415x/417x Revision Z devices: prefetch is supported  */
  if (HAL_GetREVID() == 0x1001)
  {
    /* Enable the Flash prefetch */
    __HAL_FLASH_PREFETCH_BUFFER_ENABLE();
  }
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
and we know that this STM32F457 reports RevId = 0x2000.&lt;/p&gt;

&lt;p&gt;
But further investigation reveals that HAL_Init contains&lt;/p&gt;

&lt;pre&gt;
#if (PREFETCH_ENABLE != 0U)
  __HAL_FLASH_PREFETCH_BUFFER_ENABLE();
#endif /* PREFETCH_ENABLE */
&lt;/pre&gt;

&lt;p&gt;
After setting PREFETCH_ENABLE to 0 and recompiling, I am not
observing the &amp;quot;unexpected behaviour&amp;quot; at that execution point.&lt;br /&gt;
Whilst I have previously seen changes in behaviour due to apparently
unrelated code changes, I have a good feeling that the problem was
due to the known issues with the pre-fetch buffer on STM32F4 Rev A
parts. I&amp;#39;ll want to find a cleaner solution that deals with this
properly at runtime. But at least I can move forward.&lt;/p&gt;

&lt;p&gt;
Clive, you were right that it was a MCU issue (i.e. ST) rather
than a compiler issue (i.e. Keil) and that my original post should
have been to the ST forums. That said, I remain immensely grateful
for your help in overcoming this problem.&lt;/p&gt;

&lt;p&gt;
Many thanks,&lt;br /&gt;
Richard&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: scary STM32F4 compiler issue?</title><link>https://community.arm.com/thread/121000?ContentTypeID=1</link><pubDate>Tue, 21 Feb 2017 13:45:14 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:d8ef937a-0ab4-40d0-a61d-be85a345f583</guid><dc:creator>Clive Unspecified</dc:creator><description>&lt;p&gt;&lt;p&gt;
The one here is a Rev A, and an Engineering Sample (ES)&lt;br /&gt;

&lt;a href="http://cache.amobbs.com/bbs_upload782111/files_51/ourdev_714153X481IF.JPG"&gt;cache.amobbs.com/.../ourdev_714153X481IF.JPG&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
Might want to disable the ART, the original STM32F2 had a critical
path on the prefetch where certain code sequences from GCC would
break the execution.&lt;/p&gt;

&lt;p&gt;
This is something you might have better results discussing with ST
FAE&amp;#39;s, or testing on a board with 2016/2017 silicon.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: scary STM32F4 compiler issue?</title><link>https://community.arm.com/thread/84984?ContentTypeID=1</link><pubDate>Tue, 21 Feb 2017 10:40:10 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:76015b87-0636-47b5-a372-2949e33605d3</guid><dc:creator>Richard E</dc:creator><description>&lt;p&gt;&lt;p&gt;
More info:&lt;/p&gt;

&lt;p&gt;
&amp;gt;dev=0x411, rev=0x2000&lt;br /&gt;
According to RM0033 section 32.6.1, this is the code for the
STM32F2xx rev B.&lt;br /&gt;
According to STM32F40x and STM32F41x Errata sheet section 2.1.2 the
&amp;quot;MCU device ID is incorrect&amp;quot; on STM32F40x and STM32F41x rev A
parts.&lt;br /&gt;
The STM32F457 package on the board appears to be marked as Rev A.&lt;/p&gt;

&lt;p&gt;
Combined with the previously obtained info about the Cortex-M4
core, I suspect the STM32F457 on this STM3240G-EVAL board is a
STM32F4xxx rev A.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: scary STM32F4 compiler issue?</title><link>https://community.arm.com/thread/83553?ContentTypeID=1</link><pubDate>Tue, 21 Feb 2017 09:09:51 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:3bba0e0f-36d7-4e52-9143-736d48fd9bba</guid><dc:creator>Richard E</dc:creator><description>&lt;p&gt;&lt;p&gt;
Clive,&lt;/p&gt;

&lt;p&gt;
Many thanks for responding.&lt;/p&gt;

&lt;p&gt;
&amp;gt;What if you breakpoint the call, and don&amp;#39;t single step this
specific piece of code?&lt;br /&gt;
I tried inserting a breakpoint in the assembler at the call, but the
code does not stop. That is curious in itself. But execution looks to
have continued in exactly the way that it did when I stepped across
it, i.e. the Hard Fault error is hit and the pointer appears to have
been corrupted.&lt;/p&gt;

&lt;p&gt;
&amp;gt;look at the CPUID at 0xE000ED00&lt;br /&gt;
I took a look at this and I am seeing 0x410FC241. According to the
PM0214 Programming manual, this corresponds to Cortex-M4, revision 0,
patch 1.&lt;/p&gt;

&lt;p&gt;
So I took a look at DBGMCU_IDCODE at 0xE0042000, which believe
contains the &amp;quot;MCU device ID code&amp;quot;. I see 0x20006411. I checked
section 38.6 of RM0090 Reference Manual for the STM32F4 and, whilst
the values for revision and device identifier seeem reasonable i.e.
dev=0x411, rev=0x2000, they are not described in that document.&lt;/p&gt;

&lt;p&gt;
It would seem that the startup code that I am using should be
suitable for all STM32F4 variants (with allowance for crystal
frequency). In the code, I see that Devices that report &amp;quot;rev=0x1001&amp;quot;
(STM32F405x/407x/415x/417x Revision Z) will have Flash Prefetch
Buffer enabled, but this would not be the case here.&lt;/p&gt;

&lt;p&gt;
It&amp;#39;s odd. The problem seems to be repeatable with the code build
that I currently have. However, if I make a small change to the code
in an completely unrelated area, the problem does not seem to occur.
That is an obstacle to stripping down the code to a bare failing
minimum. I&amp;#39;ve found a case that seems to fail repeatedly and I have
used it to obtain as much information as possible. I don&amp;#39;t seem to
have the luxury of changing the code in order to aid my
investigation.&lt;/p&gt;

&lt;p&gt;
Your suggestions were excellent. Do you have any more?&lt;br /&gt;
Thanks,&lt;br /&gt;
Richard&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: scary STM32F4 compiler issue?</title><link>https://community.arm.com/thread/65348?ContentTypeID=1</link><pubDate>Tue, 21 Feb 2017 07:30:03 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:25dfa2ac-f8c1-44cf-9770-32a452238d3c</guid><dc:creator>Clive Unspecified</dc:creator><description>&lt;p&gt;&lt;p&gt;
What if you breakpoint the call, and don&amp;#39;t single step this
specific piece of code?&lt;/p&gt;

&lt;p&gt;
The F457 is the part sampled on the board in 2011Q4, the
production parts may well have different numbers.&lt;/p&gt;

&lt;p&gt;
You might want to review the core stepping, I&amp;#39;d perhaps look at
the CPUID at 0xE000ED00, and review that in the light of any ARM
Errata. And look at the DBGMCU-&amp;gt;IDCODE&lt;/p&gt;

&lt;p&gt;
You could also double check the flash and prefetch settings.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>