<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/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/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Restricted regions in RAM</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/35115/restricted-regions-in-ram</link><description>Hello all, I&amp;#39;m working with construction like: 
 To pass some data between APP and BOOTLOADER. At first I tried to place this buffer to the end of RAM, but after restart content was broken. I&amp;#39;ve dumped this area and seen that last 3 words in RAM are always</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Wed, 06 Jun 2018 11:23:09 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/35115/restricted-regions-in-ram" /><item><title>RE: Restricted regions in RAM</title><link>https://devzone.nordicsemi.com/thread/134901?ContentTypeID=1</link><pubDate>Wed, 06 Jun 2018 11:23:09 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:d406d20d-b877-4f05-bf5c-aec24e24e7be</guid><dc:creator>H&amp;#229;kon Alseth</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;No issues with running it at 0x2000FFFC in my fw snippet.&lt;/p&gt;
&lt;p&gt;Are you word-aligning your BUFFER_SIZE? Do you see the same behavior on other devices?&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;What SDK version are you using?&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Kind regards,&lt;/p&gt;
&lt;p&gt;Håkon&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Restricted regions in RAM</title><link>https://devzone.nordicsemi.com/thread/134894?ContentTypeID=1</link><pubDate>Wed, 06 Jun 2018 11:04:34 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:0ab0b0f2-1aa5-4543-9440-e9e3946ca14f</guid><dc:creator>Valerii_Ie</dc:creator><description>&lt;p&gt;Thanks&amp;nbsp;&lt;span&gt; H&amp;aring;kon,&lt;br /&gt;&lt;/span&gt;Yes, I use IAR for compiling, it works even without&amp;nbsp;&lt;em&gt;volatile&amp;nbsp;&lt;/em&gt;&lt;span&gt;and&amp;nbsp;&amp;nbsp;&lt;/span&gt;&lt;em&gt;__root&lt;/em&gt;&lt;span&gt; keywords&amp;nbsp;&lt;/span&gt;for me. I aware about possible data corruption and use crc checking. I use same compiler for bootloader but for testing, flashed only SD + APP.&lt;br /&gt;Can you try with&amp;nbsp;&lt;pre class="ui-code" data-mode="c_cpp"&gt;__root __no_init static volatile uint32_t test @ 0x2000FFFC;&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;&lt;/p&gt;
&lt;p&gt;(for 64kB RAM version chip)?&lt;br /&gt; For my case the memory content is 0xFFFFFFFF permanently for this address. &amp;nbsp;&lt;br /&gt; My initial question was about such&amp;nbsp;regions.&amp;nbsp;&lt;br /&gt;&lt;br /&gt;&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Valerii&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Restricted regions in RAM</title><link>https://devzone.nordicsemi.com/thread/134861?ContentTypeID=1</link><pubDate>Wed, 06 Jun 2018 08:48:24 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b8fb9a06-e387-451b-97c8-53b54eadd04c</guid><dc:creator>H&amp;#229;kon Alseth</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Based on the syntax, it looks like you are using IAR. Is this correct?&lt;/p&gt;
&lt;p&gt;It is important that this declaration is present in both your application and dfu. I also recommend that you use the &lt;em&gt;volatile&lt;/em&gt; and&amp;nbsp;&amp;nbsp;&lt;em&gt;__root&lt;/em&gt; keyword, as IAR can look at this as a unused section.&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Some reset sources may reset your RAM, as &lt;a href="http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/power.html?cp=2_1_0_17_7#unique_832471788"&gt;seen in the POWER chapter of the PS&lt;/a&gt;. However, it is more normal that your application clears this in the startup routine rather than the nRF hardware doing it. Regardless, it is recommended to add a CRC to verify the validity of the data.&lt;/p&gt;
&lt;p&gt;Is both the DFU and application compiled with the same compiler? If the DFU is compiled with GCC for instance, then GCC places the .stack section at the top of RAM, thus your data will be overwritten.&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;I have done this exercise with Keil and GCC, which has a bit of a different syntax and handling of no_init sections, but I tested&amp;nbsp;the same small snippet&amp;nbsp;in IAR.&lt;/p&gt;
&lt;p&gt;The firmware increments a variable before performing a soft-reset, and on boot up it sets the LED state as (var % 4). Seems to work reliably in IAR as well, and it looks like you do not need to manually setup the .no_init section as you&amp;#39;ll need to do with Keil and GCC.&lt;/p&gt;
&lt;p&gt;.&lt;a href="https://devzone.nordicsemi.com/cfs-file/__key/support-attachments/beef5d1b77644c448dabff31668f3a47-599c03e2fd714e38ac6b1887792f38cc/main.c"&gt;devzone.nordicsemi.com/.../main.c&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Håkon&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>