<?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>DFU fail with SDK15 bootloader</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/33899/dfu-fail-with-sdk15-bootloader</link><description>Hi 
 We are using a slightly modified (but fully compatible signed bootloader) in out product. On the application side we have a C# implementation of the DFU protocol that may work under iOS/Android with Xamarin or on a desktop PC with a BLE Dongle. With</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 30 Apr 2018 15:09:54 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/33899/dfu-fail-with-sdk15-bootloader" /><item><title>RE: DFU fail with SDK15 bootloader</title><link>https://devzone.nordicsemi.com/thread/130320?ContentTypeID=1</link><pubDate>Mon, 30 Apr 2018 15:09:54 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b8424dc2-d6c7-4ade-a0a0-035d88aab66c</guid><dc:creator>Adrian Eggenberger</dc:creator><description>&lt;p&gt;Thanks for the details and your thoughts concerning this issue. I think that I can decide what is the best configuration in our use case.&lt;/p&gt;
&lt;p&gt;I&amp;#39;ve checked the impact of using malloc/free instead of nrf_balloc and the code size is a few hundred bytes less than with nrf_balloc. The tests I&amp;#39;ve made were quite promising so far.&lt;/p&gt;
&lt;p&gt;I understand the mixed feelings when it comes to using heap in embedded projects. We also try to avoid the usage of heap as the case of fragmentation adds an unpredictable risk factor. In this case I think the risk is a bit smaller than in general. The allocated objects are freed completely after a block is executed. This should prevent the heap from get into fragmented state.&lt;/p&gt;
&lt;p&gt;Anyway I&amp;#39;m not sure which option I&amp;#39;ll choose, but I guess both ways would be an acceptable choice.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: DFU fail with SDK15 bootloader</title><link>https://devzone.nordicsemi.com/thread/130318?ContentTypeID=1</link><pubDate>Mon, 30 Apr 2018 14:54:55 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:863f2124-666e-419d-9299-1b9d80631c4c</guid><dc:creator>emdi</dc:creator><description>&lt;p&gt;I see.&amp;nbsp;Well, dynamic memory allocation is somewhat ...risky in embedded systems and we avoid it entirely in nRF5 SDK. This is cleary a scenario where it would have come in handy :) However, I don&amp;#39;t how it would impact the code size.&lt;/p&gt;
&lt;p&gt;It&amp;#39;s hard to predict how many buffers are needed, there are many variables in the equation. My suggestion is to log the buffer usage and try to tweak (increase) the number of buffers empirically. You can override the automatic configuration&amp;nbsp;of the number of buffers by&amp;nbsp;defining&amp;nbsp;NRF_DFU_BLE_BUFFERS_OVERRIDE and setting&amp;nbsp;NRF_DFU_BLE_BUFFERS to the desired amount of buffers (in sdk_config.h).&lt;/p&gt;
&lt;p&gt;&lt;span&gt;One thing that comes to mind is that, a&lt;/span&gt;s I understand, you are using a homebrewn library to perform DFU. Said library could retry to transfer an object in case of failure, if it doesn&amp;#39;t do that already. Although the bootloader guarantees that when starting to receive a new object all its buffers are available (they are flushed on &amp;quot;data execute&amp;quot; messages), the speed at which packets are received and written to flash is variable even though the connection settings are fixed (retransmissions, timings etc). It might so happen that with the same settings the transfer of an object goes through and another time it doesn&amp;#39;t. &lt;em&gt;Clearly this would only apply in case the RAM buffers don&amp;#39;t actually accomodate for an entire object, otherwise the transfer will succeed regardless of the speed.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;I hope I was clear enough :)&lt;/p&gt;
&lt;p&gt;Regards,&lt;/p&gt;
&lt;p&gt;emdi&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: DFU fail with SDK15 bootloader</title><link>https://devzone.nordicsemi.com/thread/130303?ContentTypeID=1</link><pubDate>Mon, 30 Apr 2018 13:42:03 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:4584e5f2-c52a-4cfa-8041-4919397527c6</guid><dc:creator>Adrian Eggenberger</dc:creator><description>&lt;p&gt;Hi emdi&lt;/p&gt;
&lt;p&gt;&lt;br /&gt;I agree that changing the NRF_SDH_BLE_GATT_MAX_MTU_SIZE would fix the issue, but this would mean that we sacrifice the benefit of high MTU in the new bootloader. In the future we plan to add support in our library for higher MTU to reach the max DFU speed, but compatibility is also an important point. Best case would be to have support for the higher MTU but be compatible with DFU clients that don&amp;#39;t set a higher ATT MTU.&lt;/p&gt;
&lt;p&gt;I tested with more buffers (50 buffers of 244 bytes) and the problems are gone and we still have support for higher MTU. But how many buffers would be enough? In theory we would need 205 buffers to be able to keep all packets for one 4k block, but that would cause a ram consumption of 50k only for the buffers.&lt;/p&gt;
&lt;p&gt;A better solution would be that the buffers used for storing the requests would have a dynamic length. Why did you use nrf_balloc and not a heap based solution with malloc and free? Would this cause a higher code size?&lt;/p&gt;
&lt;p&gt;Regards Adrian&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: DFU fail with SDK15 bootloader</title><link>https://devzone.nordicsemi.com/thread/130239?ContentTypeID=1</link><pubDate>Mon, 30 Apr 2018 08:38:08 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a62e1c09-1ccf-4843-b97d-ad4862ef06ab</guid><dc:creator>emdi</dc:creator><description>&lt;p&gt;Good morning Adrian,&lt;/p&gt;
&lt;p&gt;The size and number of DFU buffers are determined by&amp;nbsp;&lt;span&gt;MAX_DFU_PKT_LEN&amp;nbsp;and&amp;nbsp;MAX_DFU_BUFFERS respectively (in nrf_dfu_ble.c).&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;Taking a look at around line 73 you will see that MAX_DFU_PKT_LEN is set indirectly by specifying the ATT MTU value with NRF_SDH_BLE_GATT_MAX_MTU_SIZE in sdk_config.h.&lt;/p&gt;
&lt;p&gt;MAX_DFU_BUFFERS is adjusted automatically based on&lt;span&gt;&amp;nbsp;&lt;/span&gt;&lt;span&gt;MAX_DFU_PKT_LEN (around line 87) in order to accommodate for an entire DFU object in RAM.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;By adjusting&amp;nbsp;NRF_SDH_BLE_GATT_MAX_MTU_SIZE&amp;nbsp;to 23 in the bootloader&amp;#39;s sdk_config file the BLE transport will size its buffers&amp;nbsp;to be able to receive one entire DFU (4K) object in RAM .&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;I am confident that this will help you solve your issues. Let me know&lt;span&gt;&amp;nbsp;&lt;/span&gt;&lt;span class="emoticon" data-url="https://devzone.nordicsemi.com/cfs-file/__key/system/emoji/1f642.svg" title="Slight smile"&gt;&amp;#x1f642;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;emdi&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>