<?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>some problems about Integrating 2 application firmwares on 51822</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/1827/some-problems-about-integrating-2-application-firmwares-on-51822</link><description>Hi,
For providing OTA function , I add dfu service into my own application APP1. and create another application App2 to copy the new firmware(named APP3) and cover the flash area, where APP1 is burned. the new firmware is received, saved and verified</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Sat, 26 Apr 2014 03:34:05 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/1827/some-problems-about-integrating-2-application-firmwares-on-51822" /><item><title>RE: some problems about Integrating 2 application firmwares on 51822</title><link>https://devzone.nordicsemi.com/thread/7916?ContentTypeID=1</link><pubDate>Sat, 26 Apr 2014 03:34:05 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:f2ad83bf-4843-49a7-bdb3-e14a4af77eff</guid><dc:creator>ziv</dc:creator><description>&lt;p&gt;newest test results shows that it&amp;#39;s faults of the flash ease/write operations.    The bootloader and the startup procedure represented above work both without problems. For reference if someone else need this information.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: some problems about Integrating 2 application firmwares on 51822</title><link>https://devzone.nordicsemi.com/thread/7915?ContentTypeID=1</link><pubDate>Tue, 11 Mar 2014 07:04:53 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:842d64c6-d168-4acd-bb35-7f9ac48dea58</guid><dc:creator>ziv</dc:creator><description>&lt;p&gt;Thanks!  I will study the code on github to get ideas.
Maybe it&amp;#39;s better to change the procedure of OTA to make it easy.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: some problems about Integrating 2 application firmwares on 51822</title><link>https://devzone.nordicsemi.com/thread/7914?ContentTypeID=1</link><pubDate>Mon, 10 Mar 2014 13:48:44 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:d5f1d595-9ccf-4904-a131-795c6becc661</guid><dc:creator>Ole Morten</dc:creator><description>&lt;p&gt;What you want is not easy to do, and is not directly supported by the softdevice. Getting this to work requires that you fully understand how the softdevice works, and how interrupts are forwarded. I&amp;#39;d therefore recommend you to read the appendix of the nRF51 Reference Manual very thoroughly, as well as the S110 SoftDevice specification.&lt;/p&gt;
&lt;p&gt;Currently, the softdevice supports having one application and one bootloader. If a bootloader address is written to the address 0x10001014 in UICR, the softdevice will jump to the reset handler at this address when power is applied to the chip, and the softdevice has finished its own initialization. All interrupts will also be forwarded to the bootloader at this address. The bootloader can then determine whether there is a valid application in the flash, and if there is, call the sd_softdevice_forward_to_application() function, and then jump to the application&amp;#39;s reset handler. After having called sd_softdevice_forward_to_application(), all interrupts will be forwarded to whatever handler is located at address 0x14000, and hence the application at this address will receive all interrupts, no matter which application&amp;#39;s main function was called.&lt;/p&gt;
&lt;p&gt;Therefore, I can&amp;#39;t see any other way of achieving what you want than to locate your own bootloader at 0x14000, not use the softdevice bootloader API and instead do interrupt forwarding on your own. This should be perfectly possible technically, but it is not trivial to get right, and it will also introduce some additional interrupt latency. The bootloader that is public &lt;a href="https://github.com/hlnd/nrf51-ble-bootloader"&gt;here&lt;/a&gt; does this, but it&amp;#39;s written for gcc, and it also has &lt;a href="https://github.com/hlnd/nrf51-ble-bootloader/issues/2"&gt;a pretty significant bug&lt;/a&gt; that you need to work around or fix if you&amp;#39;re considering using it.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>