<?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>application can&amp;#39;t read bootloader code space</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/12220/application-can-t-read-bootloader-code-space</link><description>Hi all, 
 I have an interesting problem where I want to read my bootloaders version (based on the DFU), which I have located at 0x3C100, from my application. 
 I confirmed that my version word (uint32_t) is making its way to code space at the correct</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Wed, 02 Mar 2016 07:04:43 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/12220/application-can-t-read-bootloader-code-space" /><item><title>RE: application can't read bootloader code space</title><link>https://devzone.nordicsemi.com/thread/46232?ContentTypeID=1</link><pubDate>Wed, 02 Mar 2016 07:04:43 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:597ec316-fbe7-4bb6-9f33-8c7d9036aab8</guid><dc:creator>Susheel Nuguru</dc:creator><description>&lt;p&gt;you cannot directly write to the flash. The NVMC-&amp;gt;CONFIG register needs to be changed to enable write operation. After finishing writing to flash it has to be changed back to read mode.&lt;/p&gt;
&lt;p&gt;If you are writing from CPU without changing the NVMC to write mode then it wont be stopped but nothing will be changed on the flash. If you read this in debugger, the debugger might not be showing the right value if you set a breakpoint because it knew that the CPU just wrote to that memory. If you step one more instruction, then the debugger is forced to read the memory and then it will find out that operation did not succeed.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: application can't read bootloader code space</title><link>https://devzone.nordicsemi.com/thread/46231?ContentTypeID=1</link><pubDate>Tue, 01 Mar 2016 21:17:26 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:5c474b77-c0d9-47cb-a3eb-803f368fa70d</guid><dc:creator>Simon Third</dc:creator><description>&lt;p&gt;Hi Aryan,&lt;/p&gt;
&lt;p&gt;You make a good point.
Some more playing around and I got it to work.  the fix was to use nrfjprog.exe with the --dfu switch when programming the SD110.&lt;br /&gt;
I was initially programming the 3 hex files using nRFGo Studio.&lt;/p&gt;
&lt;p&gt;I&amp;#39;m at a loss to understand the difference this makes to the CPU reading memory, but its working at least.&lt;/p&gt;
&lt;p&gt;S3&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: application can't read bootloader code space</title><link>https://devzone.nordicsemi.com/thread/46230?ContentTypeID=1</link><pubDate>Tue, 01 Mar 2016 08:24:57 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:2d3353b4-02d3-4582-8356-543b7836bf05</guid><dc:creator>Susheel Nuguru</dc:creator><description>&lt;p&gt;This is definitely not the hardware memory protection because if memory protection is acting on it, it will either return 0 or hardfault. It will not return 0XFFFF. There must be something else in your code, most probably you are reading the wrong memory. How are you reading the memory?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>