Issue reading SD card from within a Gatt connection

RE: Issue reading SD card from within a Gatt connection

Thomas — Wed, 18 Mar 2020 11:28:29 GMT

Thanks for the response. I am now trying to implement your solution but, I am having an issue with passing over the boolean command from the gatt connection. My code looks like below.

From me passing in a Gatt command from my mobile application I change a boolean main_test to 1. I tried with an int and bool and both failed to print out to the RTT terminal. What could I be doing wrong? I decalre the variable in another file I am using as an extern int main_test; and define it in the c file as int main_test = 0;

My code is below:

void Process_data(void)
{
    if(GATT_CONNECTED == false)
    {
        //Non gatt connected functions here
    }
    else if (GATT_CONNECTED == true)// GATT_CONNECTED = true
    {
        NRF_LOG_INFO("Test1 passed");//Testing variable.
        if(main_test == 1)
        {
            NRF_LOG_INFO("Test2 passed");//Testing variable.
            main_test = 0;//False
        }
        if(main_read_sd_card == true)//Not used at the moment by the idea of how I will read the CSV
        {
            NRF_LOG_INFO("Go to reading CSV file in main code");
            main_read_sd_card = false;
            SEND_CSV();//Run the function to send the CSV file
        }
        sd_app_evt_wait();//Processing for SD CARD
        idle_state_handle();
    }
}

RE: Issue reading SD card from within a Gatt connection

Vidar Berg — Fri, 06 Mar 2020 10:13:04 GMT

Yes, program execution returns to the main loop once event processing is complete. So you could add some global state flags that are updated in your event handlers and polled in your main loop.

static bool m_rcvd_data_request;

main()

{

...

for(;;)

{

if (m_rcvd_data_request) // Always checked after application interrupts

{

m_rcvd_data_request = false;

//TODO: add calls to load data from SD and send over BLE

}

else if( <flag>)

{}

idle_state_handle(); // sleep while waiting for new events

}

RE: Issue reading SD card from within a Gatt connection

Thomas — Fri, 06 Mar 2020 10:01:18 GMT

Ok but does the main loop run whilst a connection is made? If so I can just test for a connection(I am using a Boolean at the moment and just running idle state handle in it). If so I could poll a value to see if a command for reading the SD card has been called.

RE: Issue reading SD card from within a Gatt connection

Vidar Berg — Fri, 06 Mar 2020 09:24:59 GMT

Hi Thomas, glad to hear that it worked. Would it make sense to just perform the read and write from your main loop instead of doing it inside the Softdevice interrupt? I think that's probably the easiest solution to this. Another option is to implement the app scheduler library so Softdevice events are not reported in the interrupt context. There is a tutorial for it here: https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/scheduler-tutorial

RE: Issue reading SD card from within a Gatt connection

Thomas — Thu, 05 Mar 2020 14:40:23 GMT

Hi Vidar,

That fix worked thanks very much!

However, how else would you recommend me handling this?

Basically I have the need to read a CSV file stored on my SD card and then I need to transfer it over my bluetooth Gatt connection to my phone.

Thanks,

Thomas

RE: Issue reading SD card from within a Gatt connection

Vidar Berg — Thu, 05 Mar 2020 12:32:45 GMT

Hi,

The block_dev_handler() callback must get invoked to clear the "m_drives[n].busy" flag that keeps the program spinning inside the wait loop. The problem is that the callback won't get invoked if the wait loop is already run in an interrupt context with the same interrupt priority (ie if SPI IRQ pri == Softdevice). At least I think this is the problem. Please increase the interrupt priority for the SPI to SPI_DEFAULT_CONFIG_IRQ_PRIORITY==5 in sdk_config.h and see if you get the same result. Both SPI and Softdevice use priority '6' by default. That said, I think the best solution is to not do these operations from an interrupt context to keep your interrupt service routines short.

Best regards,

Vidar