To be clear: You have two separate binaries. Service calls (SVC) are used for one binary to [effectively] call functions in the second binary. You want the second binary to be able to call blocking FreeRTOS functions, but can't because you are in an SVC handler. Is that correct?
xQueueOverwrite not compatible with QueueSets
This is actually something that came up again in the forums very recently. Although in the forum I said I would just add an assert in the code to catch this occurance, I did actually attempt a fix (I say attempt as the code has not been tested so I don't know if it is a fix yet). In any case it will be in the next version once it is tested so I will close this ticket now.
Unfortunately the host of the Interactive forums no longer allow attachements, so we are looking for an alternative. For now the code can be attached to a forum post here, or you can just post a link to the code in the Interactive site.
I really hope this isn't an inappropriate posting and apologies if it is. Now you have this working nicely, would you be kind enough to put it on the interactive forum please? I am taking delivery of the SAME70 dev kit today and would like to get this up and running with Crossworks. I've got a few Atmel Studio projects going on Crossworks, so it shouldn't be too onerous a task. I will, likewise, put the Crossworks one on the forum when it's going.
Are you talking about the FREERTOS_SO_RCVTIMEO and FREERTOS_SO_SNDTIMEO options? If so I don't think it matters, you can change those options whenever you want. That doesn't hold for all options, such as window sizes, etc.
I am trying to integrate FreeRTOS with some other libraries which is already using ARM Systick timer for its internal operation. The tick rate is different from FreeRTOS configTICK_RATE_HZ. Which means i have to configure another timer for Free RTOS to use as tick timer. The Systick was intended for use by an RTOS, so your other option would be to update the other libraries to use a different timer. From https://www.freertos.org/low-power-ARM-cortex-rtos.html , steps are given how to use another...
If the task being notified has already been created, but the scheduler has not been started (so the task cannot be in the Blocked state), then it is probably ok. However I have never tried it and this is not how the feature was ever intended to work - so has not been tested.