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 appdrvtasksinit(void) { msemsampleseventready = xSemaphoreCreateBinary(); //static var already declared if (NULL == msemsampleseventready) { APPERRORHANDLER(NRFERRORNOMEM); }

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 saadccallback(nrfdrvsaadcevtt const * pevent) { if (pevent->type == NRFDRVSAADCEVTDONE) { retcodet errcode; errcode = nrfdrvsaadcbufferconvert(pevent->data.done.pbuffer, SAMPLECOUNT); APPERRORCHECK(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();
}

} uint32t saadcsampledoneeventsignal(void) { BaseTypet yieldreq = pdFALSE; xSemaphoreGiveFromISR(msemsampleseventready, &yieldreq); portYIELDFROMISR(yieldreq); return NRFSUCCESS; } void saadcsampledoneeventthread(void * arg) { uint8t i; uint8t result; adcinit(); // generates interrupts, but started after scheduler threepartycodeinit();

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);
}

} ~~~ I’m using the nRF52x with arm GCC/Makefile

Is configASSERT() defined? Is configCHECKFORSTACKOVERFLOW set to 2? Does threeparty_code() mess with the MCU interrupt registers? Is te nRF52x a Cortex-M0?

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).

I checked the Stack using the API, it appears to be ok. I also made it quite big with the same result. Its a Arm cortex m4, nRF52x

~~~ /* Define to trap errors during development. */

if defined(DEBUGNRF) || defined(DEBUGNRF_USER)

define configASSERT( x ) ASSERT(x)

endif

/* Hook function related definitions. */

define configUSEIDLEHOOK 1

define configUSETICKHOOK 0

define configCHECKFORSTACK_OVERFLOW 0

define configUSEMALLOCFAILED_HOOK 0

~~~

Here is my idle hook code: ~~~ static void loggerthread(void * arg) { while(1) { NRFLOG_FLUSH();

    vTaskSuspend(NULL); // Suspend myself
}

} void vApplicationIdleHook( void ) { vTaskResume(mloggerthread); } ~~~

The third party code should be only doing arm math functions.

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? ~~ _/) ~~~~ _/) ~~~~ _/) ~~~~ _/) ~~ Tom Lafleur

On Mar 18, 2017, at 9:12 AM, yvan pearson ypnklabs@users.sf.net wrote: /* Define to trap errors during development. */

if defined(DEBUGNRF) || defined(DEBUGNRF_USER)

define configASSERT( x ) ASSERT(x)

endif

/* Hook function related definitions. */

define configUSEIDLEHOOK 1

define configUSETICKHOOK 0

define configCHECKFORSTACK_OVERFLOW 0

define configUSEMALLOCFAILED_HOOK 0

xSemaphoreTake –> crash, xSemaphoreTakeFromISR–>no crash Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/freertos/discussion/382005/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

Nice catch, but same problem…Take doesn’t work =( ~~~ // 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)); ~~~

@Real Time Engineers ltd. I’ll setup the hook and report back.

Hello, 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(msemsampleseventready, &pxHigherPriorityTaskWoken)) to while (pdFALSE == xSemaphoreTake(msemsampleseventready, portMAX_DELAY)); Result The OS seems to have crash and the hook never gets called. Any other available options? BTW thanks for your responses this weekend =)

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.

The following is the makefile used to make the third-party library in question. ~~~ CROSS=arm-none-eabi- TEMPLATEPATH = ../../components/toolchain/gcc include $(TEMPLATEPATH)/Makefile.posix CC = ${CROSS}gcc STRIP= ${CROSS}strip LD = ${CROSS}ld AS = ${CROSS}as TARGET = balib.a SFLAGS = –strip-debug CFLAGS += -c -mcpu=cortex-m4 $(CPATH) CFLAGS += -mthumb -mabi=aapcs CFLAGS += -Wall -Werror -O1 CFLAGS += -mfloat-abi=hard -mfpu=fpv4-sp-d16 CFLAGS += -ffunction-sections -fdata-sections -fno-strict-aliasing CFLAGS += -fno-builtin –short-enums CFLAGS += -DARMMATH_CM4 CFLAGS += -DFPU_PRESENT=1 CFLAGS += -DMICROLIB LDFLAGS= SRCFOLDER=../

Source Files

CSRC = cdlib.c srpro.c demod.c COBJ=$(CSRC:.c=.o) CSRC:=$(addprefix $(SRCFOLDER)/, $(CSRC))

includes common to all targets

CPATH += -I$(abspath ../../components/toolchain/cmsis/include) CPATH += -I$(abspath ../../components/toolchain/gcc) CPATH += -I$(abspath ../../components/toolchain) all: clean $(TARGET) $(TARGET): $(COBJ) ar rc $@ $^ && ranlib $@ %.o: %.c $(CC) $(CFLAGS) $< -o $@ $(STRIP) $(SFLAGS) $@ clean: @rm -f $(SRCFOLDER)*.o ~~~

Recall that if I comment out the third party lib the xSemaphoreTake() seems to work ok

Test 1: Huh? while (pdFALSE == xSemaphoreTake(msemsampleseventready, 0)); This appears to stop the crash…more updates to come while (pdFALSE == xSemaphoreTake(msemsampleseventready, 1)); This seems to work too, but anything higher than 1 then the crash happens The 3rd party library (using math) is only used in the thread context, not in the ISR. I’m not familar with using the FPU which I’m sure the library uses. Would it use ISRs to do the calcs?