<?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>File: (null), Line: 0, Error code: 4</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/8716/file-null-line-0-error-code-4</link><description>I&amp;#39;m using Python bindings 0.5.0 and the connectivity app. On one of our machines that is running tests with the satck/dongle we see it fail a lot with a scrolling of this message from the DLL (our registered handler in python gets it with a severity code</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 17 Aug 2015 11:38:18 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/8716/file-null-line-0-error-code-4" /><item><title>RE: File: (null), Line: 0, Error code: 4</title><link>https://devzone.nordicsemi.com/thread/31964?ContentTypeID=1</link><pubDate>Mon, 17 Aug 2015 11:38:18 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a452bf2b-2438-40d7-bff4-53e911b9dfc7</guid><dc:creator>Hung Bui</dc:creator><description>&lt;p&gt;Hi Jim,&lt;/p&gt;
&lt;p&gt;No, the DLL doesn&amp;#39;t have any flow control, so if you can&amp;#39;t process the packet as fast as the coming rate, you will receive the error code 4.
However, it&amp;#39;s possible to increase the buffer, which can remedy but not fix the issue. You can modify and build the ble_driver from its source.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: File: (null), Line: 0, Error code: 4</title><link>https://devzone.nordicsemi.com/thread/31966?ContentTypeID=1</link><pubDate>Fri, 14 Aug 2015 17:09:14 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:4670758f-7e07-48e5-9bea-3235ec8846fa</guid><dc:creator>Jim Dattolo</dc:creator><description>&lt;p&gt;so if I understand this correctly the DLL doesn&amp;#39;t have enough memory allocated for incoming message buffers, correct?  Why isn&amp;#39;t this configurable since on most PCs memory is a lot cheaper than on embedded systems.   Is there a spec on how long &lt;em&gt;python&lt;/em&gt; can take to get events out of the DLL?  I can move some code around on my python to queue events from the DLL and then on a separate python thread manage the data, however python is a single threaded system.  Only one real thread and the python interpreter schedules a slice of byte code from each python thread to execute.  At some point things are going to slow down enough for this fail spiral to hit.  I&amp;#39;m thinking that the one computer that this is happening to has slow down issues.  When that happens I start getting one of these messages every connection interval flooding my database.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: File: (null), Line: 0, Error code: 4</title><link>https://devzone.nordicsemi.com/thread/31965?ContentTypeID=1</link><pubDate>Fri, 14 Aug 2015 09:10:47 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:46eacaa2-3a35-43d3-9c36-280bcaa9f839</guid><dc:creator>Hung Bui</dc:creator><description>&lt;p&gt;Hi Jim,
Could you let me know more about the condition when you got the issue ?&lt;/p&gt;
&lt;p&gt;You got the same error message as &lt;a href="https://devzone.nordicsemi.com/question/37330/nrf51-ble-driver_win_040-question/"&gt;in this case&lt;/a&gt;, that was clarified as the issue with the buffer overflow when receiving data on the PC. Could you try to follow the suggestion in the case ?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: File: (null), Line: 0, Error code: 4</title><link>https://devzone.nordicsemi.com/thread/31963?ContentTypeID=1</link><pubDate>Thu, 13 Aug 2015 14:47:08 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:5810bbe3-e695-423e-86fe-b100ebe511be</guid><dc:creator>Jim Dattolo</dc:creator><description>&lt;p&gt;um, this is an official build from Nordic.  The C code that is running on the Dongle was compiled by Nordic and provided in the 0.5.0 bindings driver package.  Can a Nordic rep comment on why the driver can fail with no debug output on the released image?  If the bindings have a way to get called back with these errors then there should be information in them and a doc that describes how to decode it.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: File: (null), Line: 0, Error code: 4</title><link>https://devzone.nordicsemi.com/thread/31962?ContentTypeID=1</link><pubDate>Thu, 13 Aug 2015 14:43:23 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b4fe0db3-b608-405d-96b2-c307ae274beb</guid><dc:creator>syntroniks</dc:creator><description>&lt;p&gt;I am not familiar with running connectivity but I do know defining &amp;quot;DEBUG&amp;quot; in your preprocessor for firmware and including app_error.c allows me to inspect the p_file_name and line number variables. Often they get optimized away. The most common scenarios I see (if this is an NRF_ERROR_NO_MEM) are insufficient timer or pstorage allocations.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>