I moved your question to our support forum - https://forums.freertos.org/t/crash-in-windows-port/15687 Going forward please use FreeRTOS support forums - https://forums.freertos.org/ Thanks.
Please note that this crash was not immediate. It occurred after one hour of FreeRTOS app run. I have investigated this problem and it might be a side effect of calling xSemaphoreGiveFromISR() from non FreeRTOS thread. I needed to simulate IRQ from something that cannot belong to FreeRTOS thread chunk.
Please note that this crash was not immediate. It occurred after one hour of FreeRTOS app run.
Crash in prvProcessSimulatedInterrupts() in Windows port
* de26f7f2f - (tag: 202011.00) [AUTO][RELEASE]: Bump kernel pointer "V10.4.2" (5 weeks ago) <David Chalco>
Sync with Github repository.
commit 2aa7fbeaff8daedf96719e3b725a1bce83d286b2
renamed from /trunk
Removed lingering demo directory.
Removed leftover files and folders.
commit 20842a58fa9fcc860cb5d489a81bfc5d250043fc
We have moved to GitHub
We have moved to GitHub
commit 70dcbe4527a45ab4fea6d58c016e7d3032f31e8c
There is a sign up button and a sign in button on the top right of the forum page. You can sign in with a github account if you don't want to create a forum account.
Okay, I'll create a request there. Though, I can't figure out how to create a topic at the new forum. Pressing 'c' doesnt open the composer.
endless loops on vPortRaiseBASEPRI on disassembly
The assembly code bares no resemblance to the source code, especially as the source function is written in assembly. For that reason I am confident this is not a FreeRTOS bug. Please create a support request on https://forums.freertos.org and we can help diagnose for you. Additionally, SourceForge is no longer our primary repository. Please see https://github.com/freertos
I forgot to add, I'm using arm-none-eabi toolchain and here's the compile options -mcpu=cortex-m7 -march=armv7e-m -mthumb -mfpu=fpv5-sp-d16 -mfloat-abi=hard -0g -g -O3 -fdata-sections -ffunction-sections
endless loops on vPortRaiseBASEPRI on disassembly
Hi, We will be closing the issue as no reponse for 12 days I will post some clarifications about the issue. The timer commands are reciegved in a queue which are processed one after the other in addition to the timer list and executing the timer callbacks , using a single thread. if a thread is going through the list of timers and about to execute "Timer A" , and a higher priority task queues a command in the queue (say a stop and delete commands for "timer A") "Timer A" will still be executed. When...
Hi Chris, Thanks for reporting and the interest in FreeRTOS! I am currently investigating the issue and I do have a few questions. 1- Are you ovserving access to freed memory? 2- Did the timer execute after the delete and stop have been executed or just inserted in the queue? 3- Is the task inserting in the queue higher priority than the task processing the timer queue? 4- Any other tasks are running at the same time with higher priority than the timer queue ? Thanks, Alfred
Compiler Warnings Generated with Keil C166 EC++ Compiler
Hi Victor - sorry for the inconvenience as I didn't realise people could still open tickets here. I would be grateful if you could open the tick here instead: https://github.com/FreeRTOS/FreeRTOS-Kernel thanks.
Appologies for the incorrect title, that was for a seperate issue I submitted on GitHub. It would be nice if this FR could be renamed: "portTICK_TYPE Critical Section Control"
Compiler Warnings Generated with Keil C166 EC++ Compiler
commit 9f316c246baafa15c542a5aea81a94f26e3d6507
Handle variable-length queue items
This can now be done with a message buffer, rather than a queue.
Include Task handler information in vTaskList()
See uxTaskGetSystemState() https://www.freertos.org/uxTaskGetSystemState.html
Provide a method of getting a task handle by its task name
Although this is a very old proposal, I'd like to respond to it. The biggest problem with the proposed solution is that the function pointed to by pCallback will be called ( executed ) from either a different task or worse, from the idle task. Note that no guarantees can be given about the available stack space, the current task priority, or task specific privileges. When task-A terminates, its termination code should be better executed from the task-A context. This means that also vTaskDelete()...
I didn't realize that repo had been created. Is it going to replace the FreeRTOS-Labs folder in the main FreeRTOS repository for the upcoming releases? Yes.
For those who get here, looking for the latestxCheckLoopback(), please find it attached. It has two modifications, one for FreeRTOS_ARP.c and one for FreeRTOS_ARP.h. It must be called from the xNetworkInterfaceOutput() function: BaseType_t xNetworkInterfaceOutput( NetworkBufferDescriptor_t * const pxBuffer, BaseType_t bReleaseAfterSend ) { if( xCheckLoopback( pxBuffer, bReleaseAfterSend ) != 0 ) { /* The packet has been sent back to the IP-task. The IP-task will further handle it. Do not release...
#include "Zynq/x_emacpsif.h" Needs -I $(TCP)/source/portable/NetworkInterface/ Whereas #include "x_emacpsif.h" Needs -I $(TCP)/source/portable/NetworkInterface/Zynq/ Maybe you have both -I directories already? I am afraid to break other projects when we change this. In earlier versions we had xemacpsif.h, but it led to confusion. But you are right, Zynq/x_emacpsif.h is a bit double.
Quick update, it looks like the latest FreeRTOS+TCP Network Interface code in 10.3.0 removed the xCheckLoopback function. I can't speak to the need to put it back, but this at least resolves this issue since it no longer depends on an undefined function.
Thanks, I didn't realize that repo had been created. Is it going to replace the FreeRTOS-Labs folder in the main FreeRTOS repository for the upcoming releases?
The file names are already different from the Xilinx BSP though (Xilinx doesn't have the underscore in the name after the 'x'), so including the "Zynq/" is redundant. As I noted, this is the only place in the codebase I have seen a path as part of a #include, and it makes for an awkward special case for buid scripts.
Clang/LLVM support for Cortex M0
Now captured by a separate more generic 'ARM Clang' backlog item.
GCC port.c: turn off lto before assembly sections + patch
We are testing with LTO now too.
AVR : Change makefile MCU tag to mega32
The port was tested with the ATMega32 too.
heap_3.c not really thread safe
xQueueReceive needs to indicate more messages waiting
There is already a workaround, and changing the API would be a big breaking change.
Remove Path From #include For Zynq EMAC Driver
It is added to enable you to bring in the versions of those files used (and/or modified) for use with the provided network interface. Otherwise they would need updating each time Xilinx updated their BSP.
Translation Source File cmsis_os.c
ARM and ST both provide a CMSIS RTOS implementation for FreeRTOS.
Provide a method of getting a list of all task handles
https://www.freertos.org/uxTaskGetSystemState.html
STM8 port