<?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>Unable to write to specific area of flash shared by custom bootloader and BLE application</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/95963/unable-to-write-to-specific-area-of-flash-shared-by-custom-bootloader-and-ble-application</link><description>Hello Nordic Team, 
 I am working on an application which has custom bootloader and BLE application firmware. The bootloader code resides in flash area 0xE0000 - 0xEDFFF, application firmware code resides in 0x27000 - 0xDFFFF. There is some data that</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Thu, 26 Jan 2023 07:25:58 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/95963/unable-to-write-to-specific-area-of-flash-shared-by-custom-bootloader-and-ble-application" /><item><title>RE: Unable to write to specific area of flash shared by custom bootloader and BLE application</title><link>https://devzone.nordicsemi.com/thread/406575?ContentTypeID=1</link><pubDate>Thu, 26 Jan 2023 07:25:58 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:8adac2ed-fc99-4fbc-81eb-5f53baa4d38b</guid><dc:creator>anusha_14</dc:creator><description>&lt;p&gt;Hi Einar,&lt;br /&gt;&lt;br /&gt;I have solved this problem. The issue was in my application code as writing to flash area 0xEE000 was being done in an interrupt handler. On modifying this to write to flash outside the interrupt handler, the issue was resolved.&lt;/p&gt;
&lt;p&gt;Regards,&lt;/p&gt;
&lt;p&gt;Anusha&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unable to write to specific area of flash shared by custom bootloader and BLE application</title><link>https://devzone.nordicsemi.com/thread/406399?ContentTypeID=1</link><pubDate>Wed, 25 Jan 2023 08:53:41 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:fc56c42d-1d51-4524-97f8-7bb525a89d1d</guid><dc:creator>anusha_14</dc:creator><description>&lt;p&gt;Hi Einar,&lt;/p&gt;
&lt;p&gt;Thanks for your response.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;Could it be that the flash operation is blocked by same or higher priority interrupts so that the flash write operation(s) never happen or that prevents you from getting the events about it&amp;#39;s completion?&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;I don&amp;#39;t think this is the case because I am able to write successfully to memory area that starts at 0xF0000. &lt;br /&gt;The issue happens when I write some bytes of data to another flash area that starts at 0xEE000. I can see that it is able to write the bytes in the area 0xEE000 but after writing, nrf_fstorage_is_busy() is busy forever.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;Do you have a lot of&amp;nbsp;Bluetooth activity and tight connection parameters? If so, it could happen that the SoftDevice never gets a chance to process flash write operations (see&amp;nbsp;&lt;a href="https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/multilink_scheduling/priorities_and_events_intro.html"&gt;SoftDevice timing-activities and priorities&lt;/a&gt;).&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;I am performing the flash write operation after enabling BLE SoftDevice (i.e much later after nrf_sdh_ble_enable()). So, there is no BLE activity such as scanning or connections.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;It is also worth checking that the way you write to flash when using a SoftDevice via fstorage is sensible, for instance by looking at the&amp;nbsp;&lt;a href="https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/fstorage_example.html"&gt;fstorage sample&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;My code for performing the flash write is based on the flash_fstorage example. One difference is that I have not defined the function nrf5_flash_end_addr_get(). This is okay, right?&lt;/p&gt;
&lt;p&gt;Here is some information , that could help in understanding my application:&lt;/p&gt;
&lt;p&gt;This is the memory layout of my application:&lt;/p&gt;
&lt;p&gt;&lt;img style="max-height:240px;max-width:320px;" alt=" " src="https://devzone.nordicsemi.com/resized-image/__size/640x480/__key/communityserver-discussions-components-files/4/MemLayout.png" /&gt;&lt;/p&gt;
&lt;p&gt;Note that 0xF6000 onwards is reserved for Zigbee data as specified here: &lt;a href="https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_tz_v4.2.0%2Fthread_zigbee__intro.html"&gt;infocenter.nordicsemi.com/index.jsp&lt;/a&gt; and my application can use either BLE or Zigbee.&lt;/p&gt;
&lt;p&gt;For writing to flash, this is the code used:&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;#include &amp;lt;string.h&amp;gt;
#include &amp;quot;nrf.h&amp;quot;
#include &amp;quot;nrf_fstorage_sd.h&amp;quot;

nrf_fstorage_api_t * p_fs_api;

static void fstorage_evt_handler(nrf_fstorage_evt_t * p_evt);
static void wait_for_flash_ready(nrf_fstorage_t const * p_fstorage);

NRF_FSTORAGE_DEF(nrf_fstorage_t fstorage) =
{
    /* Set a handler for fstorage events. */
    .evt_handler = fstorage_evt_handler,

    /* These below are the boundaries of the flash space assigned to this instance of fstorage.
     * You must set these manually, even at runtime, before nrf_fstorage_init() is called.
     * The function nrf5_flash_end_addr_get() can be used to retrieve the last address on the
     * last page of flash available to write data. */
    .start_addr = 0xEE000,
    .end_addr   = 0xF5FFF,
};

void flash_init(void)
{
  p_fs_api = &amp;amp;nrf_fstorage_sd;
  nrf_fstorage_init(&amp;amp;fstorage, p_fs_api, NULL);
}

void writeToFlash(uint32_t *address, uint32_t *data, uint32_t length)
{
  uint32_t add;
  add = (uint32_t) address;
  uint32_t len = length;

  if (length % sizeof(uint32_t))
  {
     len = (length + sizeof(uint32_t)) - (length % sizeof(uint32_t));
  }
  nrf_fstorage_write(&amp;amp;fstorage, add, data, len, NULL);
  wait_for_flash_ready(&amp;amp;fstorage);
}

void eraseFlash(uint32_t *address)
{
  uint32_t pageSize = NRF_FICR-&amp;gt;CODEPAGESIZE;
  uint32_t pageAddress = (uint32_t) address;

  pageAddress /= pageSize;
  pageAddress *= pageSize;
  nrf_fstorage_erase(&amp;amp;fstorage, pageAddress, 1, NULL);
}

static void fstorage_evt_handler(nrf_fstorage_evt_t * p_evt)
{
    if (p_evt-&amp;gt;result != NRF_SUCCESS)
    {
        PRINT( &amp;quot;ERROR while executing an fstorage operation.\r\n&amp;quot;);
        return;
    }

    switch (p_evt-&amp;gt;id)
    {
        case NRF_FSTORAGE_EVT_WRITE_RESULT:
        {
            PRINT(&amp;quot;Wrote %d bytes at address 0x%x.\r\n&amp;quot;, p_evt-&amp;gt;len, p_evt-&amp;gt;addr);
        } break;

        case NRF_FSTORAGE_EVT_ERASE_RESULT:
        {
            PRINT(&amp;quot;Erased %d page from address 0x%x.\r\n&amp;quot;, p_evt-&amp;gt;len, p_evt-&amp;gt;addr);
        } break;

        default:
            break;
    }
}

static void wait_for_flash_ready(nrf_fstorage_t const * p_fstorage)
{
    /* While fstorage is busy, sleep and wait for an event. */
    while (nrf_fstorage_is_busy(p_fstorage))
    {
     
    }
}&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;I tried to use only application with softdevice (without bootloader) to see if I&amp;#39;m able to write to flash 0xEE000 but in this case also, I was facing the issue that nrf_fstorage_is_busy() is busy forever after writing first set of bytes. So, having the bootloader sharing the flash area 0xEE000 does seem to be the issue.&lt;/p&gt;
&lt;p&gt;Regards,&lt;/p&gt;
&lt;p&gt;Anusha&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unable to write to specific area of flash shared by custom bootloader and BLE application</title><link>https://devzone.nordicsemi.com/thread/406305?ContentTypeID=1</link><pubDate>Tue, 24 Jan 2023 15:00:41 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:37a4c896-7d92-4b6f-80a9-8d530dfe3c6d</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi&amp;nbsp;Anusha,&lt;/p&gt;
&lt;p&gt;Without knowing much about your application there are&amp;nbsp;a few potential issues that come to mind:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Could it be that the flash operation is blocked by same or higher priority interrupts so that the flash write operation(s) never happen or that prevents you from getting the events about it&amp;#39;s completion?&lt;/li&gt;
&lt;li&gt;Do you have a lot of&amp;nbsp;Bluetooth activity and tight connection parameters? If so, it could happen that the SoftDevice never gets a chance to process flash write operations (see &lt;a href="https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/multilink_scheduling/priorities_and_events_intro.html"&gt;SoftDevice timing-activities and priorities&lt;/a&gt;).&lt;/li&gt;
&lt;li&gt;It is also worth checking that the way you write to flash when using a SoftDevice via fstorage is sensible, for instance by looking at the &lt;a href="https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/fstorage_example.html"&gt;fstorage sample&lt;/a&gt;.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;If you don&amp;#39;t make progress, then&amp;nbsp;perhaps you can share more information about your application, how you write to flash, and what else is happening at the same time? Also, what have you learned when debugging?&lt;/p&gt;
&lt;p&gt;Regards,&lt;/p&gt;
&lt;p&gt;Einar&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>