I have a ADC interrupt that occurs every 17ms and which copies the samples into a global static array, after which GivesFromISR to a binary semaphore so that the samples may be processed with a thread in the foreground. However, if I use xSemaphoreTake instead of xSemaphoreTakeFromISR in the thread the scheduler seems to stop. The strange part is that this only started happening after incorporating a 3rd party function call that uses the global static array modified by the ISR (closed source binary that was linked in the final binary…it does some CMSIS-DSP arm math calcs). Also, the ISR I mentioned is actually a function that gets called from the actual ISR and it is not the ISR it self.
Some code to better illustrate:
void app_drv_tasks_init(void)
{
m_sem_samples_event_ready = xSemaphoreCreateBinary(); //static var already declared
if (NULL == m_sem_samples_event_ready)
{
APP_ERROR_HANDLER(NRF_ERROR_NO_MEM);
}
if (pdPASS != xTaskCreate(saadc_sample_done_event_thread,
"SAMPLES", 256, NULL, 1,
&m_saadc_sample_done_thread))
{
APP_ERROR_HANDLER(NRF_ERROR_NO_MEM);
}
/** SAADC Interrupt handler */
void saadc_callback(nrf_drv_saadc_evt_t const * p_event)
{
if (p_event->type == NRF_DRV_SAADC_EVT_DONE)
{
ret_code_t err_code;
err_code = nrf_drv_saadc_buffer_convert(p_event->data.done.p_buffer, SAMPLE_COUNT);
APP_ERROR_CHECK(err_code);
for (int i = 0; i < SAMPLE_COUNT; i++)
{
m_app_buffer[i] = p_event->data.done.p_buffer[i];
}
saadc_sample_done_event_signal();
}
}
uint32_t saadc_sample_done_event_signal(void)
{
BaseType_t yield_req = pdFALSE;
xSemaphoreGiveFromISR(m_sem_samples_event_ready, &yield_req);
portYIELD_FROM_ISR(yield_req);
return NRF_SUCCESS;
}
void saadc_sample_done_event_thread(void * arg)
{
uint8_t i;
uint8_t result;
adc_init(); // generates interrupts, but started after scheduler
three_party_code_init();
for(;;)
{
// Need to figure out why *FromISR fixes the crash
while (pdFALSE == xSemaphoreTakeFromISR(m_sem_samples_event_ready, portMAX_DELAY))
{
}
// If this line is removed xSemaphoreTake works fine
three_party_code(m_app_buffer, &result);
}
}
int main(void)
{
app_drv_tasks_init();
SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;
vTaskStartScheduler();
while (true)
{
APP_ERROR_HANDLER(NRF_ERROR_FORBIDDEN);
}
}
One big thing to note is that the TakeFromISR will NOT block, and that last parameter is supposed to be a pointer to a flag variable to mark if a task was woken from the Take. That means that by switching to the FromISR version, you are starving all tasks of lower priority (like Idle). Perhaps you have a bug there (like an idle hook that blocks).
You should have all of these hook functions on for debugging… it will save you lots of headache…
Also, math function in general are stack hogs… so make sure your 3rd party task has lots of stack… do you know if it’s rtos safe?
// Need to figure out why *FromISR fixes the crash
// while (pdFALSE == xSemaphoreTakeFromISR(m_sem_samples_event_ready, &pxHigherPriorityTaskWoken))
while (pdFALSE == xSemaphoreTake(m_sem_samples_event_ready, portMAX_DELAY));
Step1
I tried the stackoverflow hook. Wow, I love it =) I tested it to make sure it would be called when I took the code that was working and reduced the stack size of the thread in question and saw the hook got called. Then I returned the stack size to the original size.
Step2
I changed the “working code” Take() from (this is the consumer foreground thread doing the math on the ADC samples once the ISR copied the data to the static global buffer)
while (pdFALSE == xSemaphoreTakeFromISR(m_sem_samples_event_ready, &pxHigherPriorityTaskWoken))
to
while (pdFALSE == xSemaphoreTake(m_sem_samples_event_ready, portMAX_DELAY));
Result
The OS seems to have crash and the hook never gets called. Any other available options?
Your code still has the fundamental problem that when you call the FromISR in the task, NONE of your lower priority tasks, like Idle, and thus also your logger, never will get called.This says that the crash could easily be in one of those instead.
If you changet the xSemaphoreTake to use a delay of 0 and the same sort of busy spin loop while it is, do you get a similar result? If so then the problem could well be in any of the tasks held off by the busy spin loop.
You could also check this by adding a vTaskDelay(1) inside the spin loop of the TakeFromISR loop. (This will delay processing of the give, but will let the other tasks run),
There is also a possible issue that if the code being called in the ISR uses the floating point processor, in some ports these are not saved in the interrupt context (to save time as they are rarely used in ISRs) and thus breaking some non-interrupt code that is using floating point.