<?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>Application times out after a while</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/67172/application-times-out-after-a-while</link><description>I have an application where the nrf52840 dongle is hooked to a sensor. The sensor drives a pin high, the mcu grabs data from the FIFO (SPI) and puts it in a buffer. So far it works great, I see the interrupt pin go high, the device reads the entire sensor</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 19 Oct 2020 14:38:06 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/67172/application-times-out-after-a-while" /><item><title>RE: Application times out after a while</title><link>https://devzone.nordicsemi.com/thread/275682?ContentTypeID=1</link><pubDate>Mon, 19 Oct 2020 14:38:06 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:04bbfdb0-1b3a-4ed6-800e-76d6798cea86</guid><dc:creator>helsing</dc:creator><description>&lt;p&gt;Thank you for the details.&lt;/p&gt;
&lt;p&gt;I had a brief chat with a colleague on this case and he asked why you were accessing the NRF_SPI0 register directly when using the SPI driver? He said this is not recommended and that one should either do everything by using hardware registers, or, one should let the driver take care of things. Using the driver is highly recommended. The driver could be detecting that the IC is in an unexpected state and could cause things to happen.&lt;/p&gt;
&lt;p&gt;Adding the debug-connector to your dongle could be a useful tool for you. Then you might see what state your code is in when things stop working.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Application times out after a while</title><link>https://devzone.nordicsemi.com/thread/274946?ContentTypeID=1</link><pubDate>Wed, 14 Oct 2020 16:23:03 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:d86b6b63-e321-4b29-93c2-d9b259519b0e</guid><dc:creator>SmallerPond</dc:creator><description>&lt;p&gt;In this case, I am using the ble_app_template example (SDK 17.0.2) and&amp;nbsp;in order&amp;nbsp;to test the SPI (SPIM) functionality, I&amp;#39;m not using the BLE functionality at all yet.&amp;nbsp; I can debug the&amp;nbsp;pins on a scope, but the dongle doesn&amp;#39;t have a debugger.&amp;nbsp; I do have a nRF52840-Preview-DK that I can try to debug with when I get a shot.&amp;nbsp; My main() is pretty much from the example, but with some init calls for the GPIO/SPI/sensor:&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;int main(void)
{
    bool erase_bonds;

    // Initialize.
    log_init();
    timers_init();
    power_management_init();
    ble_stack_init();
    gap_params_init();
    gatt_init();
    advertising_init();
    services_init();
    conn_params_init();

    advertising_start();

    gpio_init();
    spi_init();
    lsm_init();

    // Enter main loop.
    for (;;)
    {
        idle_state_handle();
    }
}&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;I added code from the pin_change_int example to handle the pin sense of the interrupt pin from the sensor:&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;void in_pin_handler(nrfx_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
    if (m_notification_enabled)
    {
        //NRF_SPI0-&amp;gt;ENABLE = 1;
        lsm_get_data(fifo_data_read_mode);
    }
}&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;I also have a pretty gnarly spi handler, but it works great while it works - and this is building out a prototype so we can work on making it pretty later.&amp;nbsp; I can dump the data from my FIFO buffer in a small fraction of what it took using only the interrupt-based processing.&amp;nbsp; I do nothing with the buffer for now, just overwrite it next time I get an interrupt:&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;static void spi_event_handler(nrfx_spim_evt_t const * p_event, void * p_context)
{
    nrf_gpio_pin_set(SPIM_CS);
    spi_xfer_done = true;
    nrf_gpio_pin_clear(SPIM_CS);
    
    if (ns_lsm_fn == READ &amp;amp;&amp;amp; ns_lsm_reg != WHO_AM_I)
    {
        // Get buffer cardinality from FIFO_STATUS1 and 2
        fifo_buffer_size = (((rx_buff[2] &amp;amp; 0x0F) &amp;lt;&amp;lt; 8 ) | rx_buff[1]);

        // put data in ble_buffer (H then L)
        ble_buff[ble_idx++] = rx_buff[6];
        ble_buff[ble_idx++] = rx_buff[5];
        
        while (ble_idx &amp;lt; (fifo_buffer_size * 2))
        {
            //NRF_SPI0-&amp;gt;EVENTS_READY = 0;
            NRF_SPI0-&amp;gt;TXD = FIFO_DATA_OUT_L | 0x80;
            rx_buff[7] = NRF_SPI0-&amp;gt;RXD;
            NRF_SPI0-&amp;gt;TXD = 0xFF;
            ble_buff[ble_idx++] = NRF_SPI0-&amp;gt;RXD;
            NRF_SPI0-&amp;gt;TXD = 0xFF;
            ble_buff[ble_idx++] = NRF_SPI0-&amp;gt;RXD;
            nrf_delay_us(3);
            NRF_GPIO-&amp;gt;OUTSET = 1 &amp;lt;&amp;lt; SPIM_CS;
            __NOP();
            __NOP();
            __NOP();
            __NOP();
            NRF_GPIO-&amp;gt;OUTCLR = 1 &amp;lt;&amp;lt; SPIM_CS;
            __NOP();
            __NOP();
            __NOP();
            __NOP();
        }
        // reset fifo read variables
        fifo_buffer_size = 0;
        ble_idx = 0;
        nrf_gpio_pin_clear(SPIM_CS);
        //NRF_SPI0-&amp;gt;ENABLE = 0; // TODO: Breaks functionality, why?
    }
}&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;From the scope, I see things working great while they work.&amp;nbsp; When it breaks, I see the MOSI line change high to low well before the interrupt pin goes high.&amp;nbsp; This seems to indicate that I&amp;#39;m in the&amp;nbsp;idle_state_handle() process, but the pin changes anyway.&amp;nbsp; Then nothing when the sensor drives the interrupt pin high.&amp;nbsp; Then I see a reset after a few hundred ms:&lt;/p&gt;
&lt;p&gt;&lt;img alt="Scope capture" src="https://devzone.nordicsemi.com/cfs-file/__key/communityserver-discussions-components-files/4/2620.SDS00001.BMP" /&gt;&lt;/p&gt;
&lt;p&gt;Like I said, I have measured this at anywhere from 3 to 5 minutes, but it always happens.&amp;nbsp; Clearly, the expected behavior from my end is that this should work forever.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Application times out after a while</title><link>https://devzone.nordicsemi.com/thread/274910?ContentTypeID=1</link><pubDate>Wed, 14 Oct 2020 13:18:52 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:42793a16-2c19-493c-89d2-fff3ffaef74d</guid><dc:creator>helsing</dc:creator><description>&lt;p&gt;Thank you for your question, I will be looking into this tomorrow. In the mean time, would you be able to share some more background to your project? &lt;/p&gt;
[quote user=""]Is this ever expected behavior?&amp;nbsp;[/quote]
&lt;p&gt;This of course depends on what you want to achieve. Here are a few questions: Is your application based on an example? Which SDK are you using? What happens when your buffer is full? Have you tried any debugging so far? &lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>