<?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>Confused about persisting characteristic values written by a central</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/3305/confused-about-persisting-characteristic-values-written-by-a-central</link><description>I have an nRF51822-based device, which is a peripheral running the Soft Device s110. It has some vendor specific (custom) characteristics that are read/write. A mobile app (central) reads and writes them. 
 I&amp;#39;m confused about how I should be persisting</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 23 Feb 2016 16:30:47 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/3305/confused-about-persisting-characteristic-values-written-by-a-central" /><item><title>RE: Confused about persisting characteristic values written by a central</title><link>https://devzone.nordicsemi.com/thread/12052?ContentTypeID=1</link><pubDate>Tue, 23 Feb 2016 16:30:47 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:d06112ee-fb51-4117-8d34-e795bb491a95</guid><dc:creator>Arjun</dc:creator><description>&lt;p&gt;Hi Krishna. In this example m_bonded_dev_handle is an input parameter for dm_application_context_set API. Should we store p_handle data into m_bonded_dev_handle for bonded device?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Confused about persisting characteristic values written by a central</title><link>https://devzone.nordicsemi.com/thread/12053?ContentTypeID=1</link><pubDate>Mon, 10 Aug 2015 19:20:19 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:904fca7e-8af6-43d1-ba01-7f2a02700a65</guid><dc:creator>Farhad Razavian</dc:creator><description>&lt;p&gt;What is the flash read endurance for the nRF51822 device? Can you execute code from the flash indefinitely?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Confused about persisting characteristic values written by a central</title><link>https://devzone.nordicsemi.com/thread/12051?ContentTypeID=1</link><pubDate>Fri, 01 Aug 2014 14:48:49 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:64d2ed29-7ca7-4727-839f-65aa417e7059</guid><dc:creator>Eliot Stock</dc:creator><description>&lt;p&gt;Thanks. You&amp;#39;re right DM_DISABLE_LOGS is defined by default in device_manager_peripheral.c so there&amp;#39;s no memory saving there. I can&amp;#39;t use the UART for debugging sadly, it&amp;#39;s in use for my board&amp;#39;s peripherals. I&amp;#39;ll have to spend more time diffing the map files before and after including the application context and see if I can spot where the memory&amp;#39;s being used.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Confused about persisting characteristic values written by a central</title><link>https://devzone.nordicsemi.com/thread/12050?ContentTypeID=1</link><pubDate>Fri, 01 Aug 2014 14:42:00 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:872927f7-69e1-4fa6-8468-d86f7f9f9947</guid><dc:creator>Krishna Shingala</dc:creator><description>&lt;p&gt;3932 bytes is  way too high for application context APIs in device manager. As I mention, it does result in an increase, but of 700 bytes without any optimizations.&lt;/p&gt;
&lt;p&gt;DM_DISABLE_LOGS is the define used to disable logs. I think they are disabled by default, hence this will not result in any saving.&lt;/p&gt;
&lt;p&gt;In case you want to view them, you will have to have DM_DISABLE_LOGS undefined. Additionally ENABLE_DEBUG_LOG_SUPPORT should be defined and app_trace and simple_uart modules included in the workspace. You will then be able to get the trace on the UART terminal. Buadrate is 38400 and hard flow control is enabled for EV kit and disabled for dev kit.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Confused about persisting characteristic values written by a central</title><link>https://devzone.nordicsemi.com/thread/12049?ContentTypeID=1</link><pubDate>Fri, 01 Aug 2014 14:32:05 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:0d3f81a1-363f-4f38-a37e-67ed12a8e436</guid><dc:creator>Eliot Stock</dc:creator><description>&lt;p&gt;Yeah I&amp;#39;m using an extra 0xF5C (3932) bytes the minute I start setting and getting the application context, which seems like way too much. How do I disable the device manager logs? For that matter, how do I read them if I leave them enabled? I didn&amp;#39;t know they existed.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Confused about persisting characteristic values written by a central</title><link>https://devzone.nordicsemi.com/thread/12048?ContentTypeID=1</link><pubDate>Fri, 01 Aug 2014 08:34:45 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:9c4a1118-d986-42e4-996e-019da3b437bf</guid><dc:creator>Krishna Shingala</dc:creator><description>&lt;p&gt;Hi Eliot,&lt;/p&gt;
&lt;p&gt;It appears to me that the application image exceeds the flash size. Is it possible for you to disable device manager logs? That will give some saving. I am not able to give specific recommendations on how to reduce the image size without knowing your requirements, if you can use optimization or not etc.&lt;/p&gt;
&lt;p&gt;I should also mention that enabling application context in device manager results in an increase of ~700 bytes without any optimization and not more. Hence it will be worth investigating 2388 bytes increase in image keeping the one used earlier as reference.&lt;/p&gt;
&lt;p&gt;Regards,
Krishna&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Confused about persisting characteristic values written by a central</title><link>https://devzone.nordicsemi.com/thread/12047?ContentTypeID=1</link><pubDate>Thu, 31 Jul 2014 16:57:01 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:f0088fe0-6174-4814-a175-31a29c063f2e</guid><dc:creator>Eliot Stock</dc:creator><description>&lt;p&gt;OK this compiles but won&amp;#39;t link. It&amp;#39;s the first time I&amp;#39;ve used pstorage. I&amp;#39;m overflowing the FLASH region. How to I make room for what I&amp;#39;m writing?&lt;/p&gt;
&lt;p&gt;/Users/Eliot/dev/gcc-arm-none-eabi-4_8-2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld: _build/device-nordic_s110.elf section &lt;code&gt;.text&amp;#39; will not fit in region&lt;/code&gt;FLASH&amp;#39;
/Users/Eliot/dev/gcc-arm-none-eabi-4_8-2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld: region `FLASH&amp;#39; overflowed by 2388 bytes
collect2: error: ld returned 1 exit status&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Confused about persisting characteristic values written by a central</title><link>https://devzone.nordicsemi.com/thread/12046?ContentTypeID=1</link><pubDate>Thu, 31 Jul 2014 16:29:08 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:c0469fc5-86e6-4c11-a746-c5d95711fca4</guid><dc:creator>Eliot Stock</dc:creator><description>&lt;p&gt;Thanks Krishna, will give this a shot.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Confused about persisting characteristic values written by a central</title><link>https://devzone.nordicsemi.com/thread/12045?ContentTypeID=1</link><pubDate>Thu, 31 Jul 2014 08:34:18 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:d034e5f8-7686-4328-8156-52f5c338039b</guid><dc:creator>Krishna Shingala</dc:creator><description>&lt;p&gt;Hi Eliot,&lt;/p&gt;
&lt;p&gt;The application context in Device Manager has been added to address use cases you mention above. Hence 3, is suitable. However, note that you will be to use application context store and load functionality &lt;em&gt;only&lt;/em&gt; for a &lt;em&gt;bonded device&lt;/em&gt;.&lt;/p&gt;
&lt;p&gt;You are right, there is no SDK example that shows how to use the application context.&lt;/p&gt;
&lt;p&gt;Below are some code snippets that may be of useful to you.&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;typedef struct
{
    uint32_t value;
}my_char_t;

static dm_handle_t m_bonded_dev_handle;
static my_char_t   m_my_char;


// Code for storing.
static void on_ble_evt(ble_evt_t * p_evt)
{
   api_result_t               retval;
   dm_application_context_t   app_context;
   
   switch (p_evt-&amp;gt;header.evt_id)
   {
        .
	    .
	    case BLE_GAP_EVT_DISCONNECTED:
	    {
		    app_context.len    = sizeof(my_char_t);
			app_context.p_data = ((uint8_t *)&amp;amp;m_my_char); 
			
	        // Want to store the last updated value of the characteristic persistently.
		    retval = dm_application_context_set(&amp;amp;m_bonded_dev_handle,
		                                       &amp;amp;app_context);
            if (retval == NRF_SUCCESS)
			{
			    // Wait for DM_EVT_APPL_CONTEXT_STORED event.
				// Note do not reuse or change m_my_char.
			}
			else
			{
			    // Failed to store application context.
			}
	        break;
       }
	   .
	   .
   }
}


// Code for loading.
static uint32_t device_manager_evt_handler(dm_handle_t const    * p_handle,
                                           dm_event_t const     * p_event,
                                           api_result_t           event_result)
{
    APP_ERROR_CHECK(event_result);
	
	
    api_result_t               retval;
    dm_application_context_t   app_context;
	
	switch(p_event-&amp;gt;event_id)
	{
	    .
		.
		case DM_EVT_DEVICE_CONTEXT_LOADED:
		{		
		    // This event is generated as soon as a bonded device reconnects and its bond and 
			// service information have been loaded. This may be most appropriate to load application
			// context. 			
			app_context.len    = sizeof(my_char_t);
			app_context.p_data = ((uint8_t *)&amp;amp;m_my_char);
			
			retval = dm_application_context_get(p_handle,&amp;amp;app_context);
			if (retval == NRF_SUCCESS)
			{
                // DM_EVT_APPL_CONTEXT_LOADED event generated to indicate load complete.
				// Note do not reuse or change m_my_char.
			}
		    break;
		}
		case DM_EVT_APPL_CONTEXT_LOADED:		
		{
		    // Set char value using sd_ble_gatts_value_set
		    break;
		}
		.
		.
	}
    return NRF_SUCCESS;
}
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Please ensure that DEVICE_MANAGER_APP_CONTEXT_SIZE is set to a value &lt;em&gt;suitable&lt;/em&gt; for storing your application context size. By default DEVICE_MANAGER_APP_CONTEXT_SIZE is set to 0 in examples to disable these APIs for applications that do not need it. Also, note that I mention suitable here and not maximum because the DEVICE_MANAGER_APP_CONTEXT_SIZE is expected to be a multiple of 4. Therefore in case your application context size if 30, you will need to set this to 32.&lt;/p&gt;
&lt;p&gt;Hope this helps!&lt;/p&gt;
&lt;p&gt;Regards,
Krishna&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Confused about persisting characteristic values written by a central</title><link>https://devzone.nordicsemi.com/thread/12044?ContentTypeID=1</link><pubDate>Wed, 30 Jul 2014 12:47:14 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:d95fb979-75fb-495e-b28c-8c9c80e1c2f2</guid><dc:creator>John</dc:creator><description>&lt;p&gt;Hi Eliot,&lt;/p&gt;
&lt;p&gt;You are responsible for persisting the values written to the characteristics over resets and system off modes. If you do not need to have them survive power reset then RAM retention is a viable option. If they do need to survive power reset then I would be using NVRAM and pstorage. I&amp;#39;m not familiar with the Device Manager so I can&amp;#39;t help with addressing it&amp;#39;s usage.&lt;/p&gt;
&lt;p&gt;There are power considerations for RAM vs. NVRAM. According to the nRF51822 product specification NVRAM erase/write operations typically take 21-22 mS so you will be burning more power than a RAM write. I suspect NVRAM erase/write operations also consume additional current but I didn&amp;#39;t see any mention of it in the product spec. The product specification also indicates that the endurance of the flash is 20,000 write/erase cycles.&lt;/p&gt;
&lt;p&gt;Regards,
John&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>