This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

What is the best place to update characteristics from?

I am developing a real-time system which triggers an interrupt every few milliseconds. That data is collected in the interrupt. When a memory buffer is full, the data is then processed.

Currently they are 512 byte buffers. I eliminated the heap to free room. This is called on every interrupt to store the data. After the buffer is full, processing occurs (I know -- still in interrupt context)

	array_y[array_counter] = y_sample;
	array_x[array_counter] = x_sample;
	array_counter++;
	array_counter &= array_bitmask; // wrap around @ 10 bit boundary
	
	if (array_counter == 0)
	{
		// Disable collecting of samples
		process_samples();
		// Enable collecting of samples
	}

One thing leads to another

void process_samples()
{
...
			on_processing_complete();
...
}

and another


void on_processing_complete()
{
...
	if (m_callback != NULL)
		m_callback(...);
}

void hrCallbackFn(...)
{
...
	ble_hrs_heart_rate_measurement_send(&m_hrs, ...);
...
}

And finally we work our way down to a call to the softdevice to do handle value notification, sd_ble_gatts_hvx. This hangs at a hard fault. I suspect the issue is calling this from within an interrupt context (bad pracice).

My question is: How/Where do I offload the signal processing to be in a 'main thread' priority as opposed to the interrupt context. I am used to having freeRTOS or ucos to give me an event system. Please advise (operating systems are not a requirement for this project).

Is it sufficient to have a 'volatile' variable flag and process before the power_manage(); call in main()?

Parents
  • I do like the suggestion from Jarek on this, but just to chip in with another option: Have you considered using the scheduler? Doing so would allow you to put an event in the queue from your interrupt handler, which will then be handled in the main queue, i.e. from the main context.

    Just for future reference: It's correct that you're not allowed to call softdevice API functions from interrupts with HIGH priority. The reason is that all softdevice API function calls are implemented as SVCs, which runs on interrupt level 2, and triggering a lower-level interrupt from a higher-level interrupt obviously doesn't work nicely. This is described in the appendix to the Reference Manual.

  • I would like to call a sd_ble_gatts_hvx in my custom thread. but i have hardfault.

    my code base is ble_app_hrs_freertos_s132.

    i inserted my custom task.

    if(pdPASS != xTaskCreate(main_thread, "MAIN", 32, NULL , 1, &m_main_thread))
    {
       APP_ERROR_HANDLER(NRF_ERROR_NO_MEM);
    }
    

    and called a sd_ble_gatts_hvxn hardfault!!!

    i only have to call a sd_ble_gatts_hvx in app_timer or interrupt service routine.

    why? , i can't understand.

    can i call in my custom thread?

Reply
  • I would like to call a sd_ble_gatts_hvx in my custom thread. but i have hardfault.

    my code base is ble_app_hrs_freertos_s132.

    i inserted my custom task.

    if(pdPASS != xTaskCreate(main_thread, "MAIN", 32, NULL , 1, &m_main_thread))
    {
       APP_ERROR_HANDLER(NRF_ERROR_NO_MEM);
    }
    

    and called a sd_ble_gatts_hvxn hardfault!!!

    i only have to call a sd_ble_gatts_hvx in app_timer or interrupt service routine.

    why? , i can't understand.

    can i call in my custom thread?

Children
No Data
Related