FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [March 2017 Threads] xSemaphoreTake --> crash, xSemaphoreTakeFromISR-->no crashPosted by ypnklabs on March 18, 2017 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
xSemaphoreTake --> crash, xSemaphoreTakeFromISR-->no crashPosted by davedoors on March 18, 2017 Is configASSERT() defined? Is configCHECKFORSTACKOVERFLOW set to 2? Does threeparty_code() mess with the MCU interrupt registers?
Is te nRF52x a Cortex-M0?
xSemaphoreTake --> crash, xSemaphoreTakeFromISR-->no crashPosted by richard_damon on March 18, 2017 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).
xSemaphoreTake --> crash, xSemaphoreTakeFromISR-->no crashPosted by ypnklabs on March 18, 2017 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
xSemaphoreTake --> crash, xSemaphoreTakeFromISR-->no crashPosted by ypnklabs on March 18, 2017 ~~~
/* 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 crashPosted by ypnklabs on March 18, 2017 Here is my idle hook code:
~~~
static void loggerthread(void * arg)
{
while(1)
{
NRFLOG_FLUSH();
vTaskSuspend(NULL); // Suspend myself
}
}
void vApplicationIdleHook( void )
{
vTaskResume(mloggerthread);
}
~~~
xSemaphoreTake --> crash, xSemaphoreTakeFromISR-->no crashPosted by ypnklabs on March 18, 2017 The third party code should be only doing arm math functions.
xSemaphoreTake --> crash, xSemaphoreTakeFromISR-->no crashPosted by rtel on March 18, 2017 You are not using a stack overflow hook.
xSemaphoreTake --> crash, xSemaphoreTakeFromISR-->no crashPosted by tlafleur on March 18, 2017 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/
xSemaphoreTake --> crash, xSemaphoreTakeFromISR-->no crashPosted by ypnklabs on March 18, 2017 Nice catch, but same problem...Take doesn't work =(
~~~
// Need to figure out why *FromISR fixes the crash
// while (pdFALSE == xSemaphoreTakeFromISR(msemsampleseventready, &pxHigherPriorityTaskWoken))
while (pdFALSE == xSemaphoreTake(msemsampleseventready, portMAX_DELAY));
~~~
xSemaphoreTake --> crash, xSemaphoreTakeFromISR-->no crashPosted by ypnklabs on March 18, 2017 @Real Time Engineers ltd.
I'll setup the hook and report back.
xSemaphoreTake --> crash, xSemaphoreTakeFromISR-->no crashPosted by ypnklabs on March 19, 2017 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 =)
xSemaphoreTake --> crash, xSemaphoreTakeFromISR-->no crashPosted by richard_damon on March 19, 2017 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.
xSemaphoreTake --> crash, xSemaphoreTakeFromISR-->no crashPosted by ypnklabs on March 19, 2017 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 += -DARMMATHCM4
CFLAGS += -D__FPUPRESENT=1
CFLAGS += -D__MICROLIB
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
~~~
xSemaphoreTake --> crash, xSemaphoreTakeFromISR-->no crashPosted by ypnklabs on March 19, 2017 Recall that if I comment out the third party lib the xSemaphoreTake() seems to work ok
xSemaphoreTake --> crash, xSemaphoreTakeFromISR-->no crashPosted by ypnklabs on March 19, 2017 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?
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|